ki-buch/teil-01-grundlagen/kapitel-03-faehigkeiten-grenzen-kontext.md

Kapitel 3: Fähigkeiten, Grenzen und Kontext-Management von LLMs

Teil I · Grundlagen – Large Language Models und Kontext verstehen

---

Teams schalten Frontier-Modelle ein und wundern sich über halluzinierte APIs, überzeugte Falsch-Fixes und „Memory“, das nur das Chat-Log ist. Die teure Fehlannahme lautet: Mehr Parameter lösen Architektur. In der Softwarearbeit diktieren aber Grenzen des Modells – Halluzination, Wissensstichtag, Non-Determinismus, fehlende Verantwortung – wie du Agenten bauen musst. Der zentrale Hebel ist selten die nächste Generation, sondern Kontextqualität: Relevanz, Aktualität, Repräsentation, Autorisierung und Provenance.

These: Context Engineering ist eine eigene Disziplin mit Hebeln und Policies – kein schöneres Prompting. MCP transportiert und entdeckt Capabilities; es ersetzt keine Policy, die entscheidet, was das Modell wann sieht.

Leitfrage: Welche Grenzen diktieren die Architektur von Agenten – und wie steuerst du, was das Modell wann sieht?

Nach Geschichte (Kap. 1) und Mechanik (Kap. 2) schließt dieses Kapitel Teil I mit realistischen Stärken, harten Grenzen, Memory-Typen und Context Engineering als Betriebslogik. Es verhindert Fehlannahmen (Wahrheit ohne Grounding, unbegrenztes Reasoning, Chat-Log als Memory) und setzt den roten Faden: Teil II baut darauf Agenten, Harness und MCP-Infrastruktur.

Lernziele

Nach diesem Kapitel kannst du:

• realistische Stärken und Grenzen moderner LLMs für Softwarearbeit benennen,
• Halluzinationen, Wissensstichtage und Reasoning-Fallen im Agenten-Kontext einordnen,
• Memory-Typen (kurz, lang, episodisch, prozedural) und ihre Rolle in Agenten unterscheiden,
• erklären, warum Kontextqualität oft den Bottleneck bildet – nicht die Modellgeneration,
• Context Engineering als Disziplin mit klaren Hebeln, Patterns und Qualitätskriterien anwenden,
• Policies entwerfen, die Agenten den richtigen Kontext zur richtigen Zeit liefern (inkl. MCP-Resources).

---

3.1 Was LLMs in der Softwareentwicklung wirklich gut können

Moderne Frontier- und starke Open-Weight-Modelle (Stand 2026) sind in vielen Entwicklungsaufgaben erstaunlich produktiv – wenn der Kontext stimmt. Typische Stärken:

Fähigkeit	Praxisbeispiel	Warum es funktioniert
Musterübertragung	API-Client analog zu bestehendem Service	In-Context Learning + Code-Korpora
Transformation	JSON → Typed Models, OpenAPI → Stubs	Struktur + klare Spec im Prompt
Erklären & Onboarding	„Was macht dieser Legacy-Flow?“	Verdichtung langer Texte
Diff- und Review-Assistenz	Security- und Style-Findings	Checklisten + fokussierter Diff
Test-Ideen	Edge Cases, Property-Ideen	Kombinatorik und „was könnte schiefgehen“
Boilerplate & Glue	Config, CI-Snippets, Mapper	Hochfrequente Trainingsmuster
Mehrsprachigkeit	Docs DE/EN, Commit Messages	Starke Sprachabdeckung

Analogie: Ein LLM ist ein extrem belesener Pair-Programmer mit fotografischem Kurzzeitgedächtnis für das, was im Fenster liegt – und ohne verlässliches Langzeitgedächtnis für dein internes System, solange du es nicht lieferst.

Wichtig: Stärke heißt nicht Autonomie. Dieselben Modelle brauchen Guardrails, Tests und oft menschliche Freigabe, sobald Schreibzugriffe oder Produktion im Spiel sind.

---

3.2 Grenzen, die Agenten-Architekturen diktieren

Halluzinationen und überzeugte Fiktion

Das Modell optimiert auf plausible Fortsetzung, nicht auf Wahrheit. In Code äußert sich das als:

• erfundene Methoden, Flags, Env-Vars,
• veraltete Library-APIs,
• „Tests grün“ ohne sie ausgeführt zu haben,
• erfundene Ticket-IDs oder Commit-Hashes.

Je autoritärer der Ton, desto gefährlicher im Review. Grounding (Tools, Resources, Zitation, Ausführung) ist die Gegenstrategie – nicht „höflich nachfragen“ allein.

Wissensstichtag und Trainingslücke

Alles, was nach dem Training oder außerhalb der Daten liegt – interne Services, frische CVE, gestrige Architekturentscheidung – ist nicht im Gewicht. Runtime-Kontext (Repo, Docs, MCP, Web-Tool mit Vorsicht) ist Pflicht.

Mathematik, Zählen, exakte Mengen

Token-Modelle sind schwach im exakten Zählen langer Listen, in Buchhaltungslogik und in manchen Algorithmik-Fällen. Für Agenten: rechnen lassen durch Code/Tools, nicht „im Kopf“ des LLMs.

Long-Context-Degradation

Große Windows lösen das Retrieval-Problem nicht magisch. Bekannte Effekte:

• Lost in the Middle – Mitte riesiger Kontexte wird schlechter genutzt,
• Aufmerksamkeit auf laute, aber irrelevante Blöcke,
• höhere Kosten ohne proportionale Qualität.

Non-Determinismus und Regression

Andere Seeds, Provider-Updates, leicht geänderte Tool-Texte → anderes Verhalten. Agenten brauchen Eval-Suiten und versionierte Prompts/Policies (siehe Kap. 6 und 11).

Keine echten Ziele, keine echte Verantwortung

Ein Agent „will“ nichts. Er maximiert lokale nächste-Token- und Instruction-Folgen. Ziele, Stopp-Kriterien, Eskalation und Ownership liegen in Runtime und Organisation.

{ width=100% }

---

3.3 Reasoning, Planung und die Illusion der Gedankenkette

Chain-of-Thought und „Thinking“-Modi

Viele Modelle profitieren von schrittweisem Nachdenken – sichtbar (Chain-of-Thought) oder als internes Inference-Time-Compute (je nach Produkt). Für Softwareaufgaben hilft das bei:

• mehrstufigen Refactors,
• Debugging-Hypothesen,
• Abwägung von Design-Optionen.

Es hilft nicht zuverlässig bei:

• Fakten, die fehlen (stattdessen: erfundene Zwischenschritte),
• Security-kritischen Entscheidungen ohne Policy,
• „Beweisen“, dass Code korrekt ist, ohne Tests.

Plan-and-Execute vs. reines Reagieren

Reine ReAct-Schleifen (Thought → Action → Observation) können in lokalen Optima stecken. Explizite Pläne (To-do-Listen, Graph-States) verbessern Steuerung – behandeln wir in Kapitel 4 und 5.

Pitfall: Lange CoT-Traces ins Context Window zu kippen, ohne Zusammenfassung. Du zahlst Tokens für Gedankenmüll und verwirrst nachfolgende Steps.

Besser: kompakte Pläne persistieren (Memory/MCP-Resource), detaillierte Traces nur in Observability-Backends.

---

3.4 Memory: Was „sich erinnern“ für Agenten bedeutet

LLMs haben kein eingebautes zuverlässiges Langzeitgedächtnis über Sessions. „Memory“ ist Systemdesign.

Memory-Typ	Inhalt	Typische Implementierung
Working Memory	aktueller Turn, offene Tool-Results	Context Window
Session Memory	Gespräch/Agent-Lauf	Message-Store, Summaries
Episodic Memory	„Was haben wir gestern entschieden?“	Logs, Decision Records, MCP Memory-Server
Semantic Memory	Fakten, Docs, Code-Bedeutung	RAG, Knowledge Graph
Procedural Memory	„So deployen / so reviewen wir“	Prompts, Runbooks, MCP Prompts, Playbooks
Entity / Project Memory	Services, Owner, SLAs, ADRs	Structured Store, Graph, memory://… Resources

Konzept-Plate: Memory-Schichten und MCP

{ width=100% }

Regel: Persistenz gehört nicht ins Modellgewicht, sondern in versionierbare Stores – ideal über standardisierte MCP-Server (Vertiefung Kap. 5 und 10).

---

3.5 Safety, Alignment und die Lücke zur Produktionsrealität

Alignment (RLHF/RLAIF, Policy-Modelle) reduziert grobe Schadensklassen, ersetzt aber nicht:

• Least Privilege auf Tools,
• Secret-Scanning,
• Netzwerk-Egress-Kontrolle,
• Human-in-the-loop für destruktive Ops,
• Auswertung von Indirect Prompt Injection über Tool-Outputs und Web-Inhalte.

Ein „hilfreiches“ Modell mit shell und Cloud-Credentials ist ein Security-Produkt – oder ein Vorfall. Kapitel 11 vertieft MCP-Security; hier die Kernaussage:

Leitsatz: Fähigkeiten des Modells multiplizieren die Wirkung deiner Tool-Oberfläche. Begrenze die Oberfläche zuerst.

---

3.6 Kontext als Qualitätshebel: Signal, Rauschen, Aktualität

Die drei Dimensionen guter Kontextqualität

1. Relevanz (Signal) – hilft dieser Chunk für den aktuellen Schritt?
2. Aktualität – entspricht er HEAD, dem richtigen Branch, dem echten CI-Lauf?
3. Form – Diff vs. Ganzdatei, JSON vs. Prosa, Zusammenfassung vs. Roh-Log

Zusätzlich: Autorisierung (darf das Modell das sehen?) und Provenance (woher stammt es?).

Failure Modes im Coding-Alltag

Symptom	Typische Kontextursache
Fix am falschen Module	Retrieval/Path-Kontext falsch
Import-Halluzination	fehlende lokalen Types/Interfaces
Endlos-Refactor	kein Stopp-Kriterium / keine Test-Observation
Security-Leak im Prompt	Secrets in Dateien ohne Filter
„Funktioniert bei mir“	Agent sieht nicht CI-Image/Env

Messbare Proxies (pragmatisch)

• Human Edit Rate nach Agent-PR
• Task Success @k (Eval-Set)
• Tokens pro erfolgreichem Task
• Anteil Tool-Failures / Retries
• Context Hit Rate (wurde die eigentlich nötige Datei geladen?)

Was du nicht misst, optimierst du mit Bauchgefühl – und Bauchgefühl liebt große Windows.

Empirischer Anker (kurz)

Kontrollierte Arbeiten zu langen Kontexten zeigen Positionseffekte: relevante Fakten in der Mitte langer Eingaben werden systematisch schlechter genutzt als am Anfang oder Ende („Lost in the Middle“, Liu et al., 2023 und Nachfolgearbeiten) [E1]. Das stützt Working Sets, Reihenfolge und Verdichtung – nicht den Window-Maximalismus.

Für MCP- und AGENTS.md-Strategien fehlen große öffentliche Feld-RCTs (Stand 2026-07). Die Proxies oben und die Suite in Anhang C sind deshalb die belastbare Steuerbasis; Studien, MCP-Benches und Stufen [E1]–[E5]: Anhang F.

Die Companion-Demo (TRACE-DEMO-1 / Anhang C.12) misst Prozess- und Kontextqualität unter Mock-LLM – didaktisch wertvoll, nicht generalisierbar auf Team-ROI [E3]*.

Faustregel: Budget-Splits und Context Policies in diesem Kapitel sind Engineering-Orientierung, keine gemessenen Branchenmittelwerte. [E4]

Was für Teams offen bleibt – und warum du trotzdem steuern kannst:

Was wir (noch) nicht wissen: Ob Working Set + AGENTS.md + Progressive Disclosure in realen Teams systematisch bessere Delivery-Outcomes liefern als „großes Window + RAG“.

• Offene Fragen: 1) Effektgröße auf Task Success, Human Edit Rate und Tokens/Success bei n Teams? 2) Half-Life und Drift von AGENTS.md/Skills ohne Owner?
• Widersprüchliche Evidenz: Lost-in-the-Middle robust [E1] (gegen Window-Maximalismus); Feld-RCTs zu Policies fehlen (Stand 2026-07); Buch-Demo = Prozessqualität unter Mock-LLM [E3]*, kein Team-ROI.
• Was die Aussage widerlegen würde: Preregistrierter Vergleich — Policy „Full-Repo“ ≥ Policy „Working Set“ bei Success@Suite und niedrigerer Edit/Revert-Rate über ≥8 Wochen.
• Überprüfung: 90-Tage-Scorecard (Kap. 7.9); nach Modell-Upgrade Full coding sample + Context-Hit-Subset (Anhang F.7).
• Was wir trotzdem tun [E4]: Context Hit Rate, Waste, Tokens/Success und Edit Rate steuern (Anhang C/F.1) — Policies als Hypothesen versionieren, nicht als Glaubenssätze.

---

3.7 Context Engineering als neue Disziplin

Hier wird aus der Diagnose „Kontext ist der Engpass“ eine handhabbare Disziplin: Policies und Pipelines, die dem Modell zur richtigen Zeit den richtigen Kontext in der richtigen Form und mit dem richtigen Budget liefern. Prompt- und RAG-Engineering bleiben Teilmengen; Context Engineering steuert Selektion, Beschaffung, Repräsentation, Aktualität, Schutz und Feedback – oft über MCP als Transport, aber nie ohne Policy. Für Teams ist das der Übergang vom Prompt-Basteln zur Systemverantwortung.

Definition

Context Engineering – die Primärform dieses Buchs für systematisches Kontext-Management – ist das systematische Entwerfen, Implementieren und Betreiben von Pipelines und Policies, die einem Modell oder Agenten zur richtigen Zeit den richtigen Kontext in der richtigen Repräsentation und mit dem richtigen Budget bereitstellen – inklusive Feedback-Schleifen und Qualitätskontrolle. Spätere Kapitel verweisen auf diese Stelle, statt die Definition neu aufzubauen.

Es ist verwandt mit, aber breiter als:

Disziplin	Fokus	Verhältnis
Prompt Engineering	Formulierung von Instructions	Teilmenge / UI-Schicht
RAG Engineering	Retrieval-Pipelines	eine Beschaffungsstrategie
MLOps / LLMOps	Deploy, Monitor, Eval von Modellen	Betriebsrahmen
Context Engineering	Was das Modell wann sieht und warum	Querschnittsdisziplin

Analogie: Prompt Engineering wählt die Worte im Brief. Context Engineering baut die Aktenmappe, entscheidet welche Dokumente beigelegt werden, stapelt sie in der richtigen Reihenfolge und holt fehlende Akten nach – über standardisierte Boten (MCP), nicht über Copy-Paste.

Die sieben Hebel

{ width=100% }

Die sieben Hebel sind keine sieben getrennten Tools, sondern Stellen in einer Pipeline, an denen Teams bewusst entscheiden müssen – sonst entscheidet der Zufall des Host-Defaults. In der Praxis merkst du fehlende Hebel oft erst spät: an teuren Loops, an „das Modell hat die falsche Datei angefasst“ oder an einem Diff, der Secrets streift.

Lies die Hebel deshalb als Checkliste beim Entwurf einer Context Policy: Wenn du einen Coding-Agenten für Issue → PR baust, gehst du sie der Reihe nach durch – von „was brauche ich?“ bis „was lerne ich für den nächsten Lauf?“. Die Reihenfolge ist absichtlich: Erst Relevanz und Beschaffung, dann Form und Budget, dann Vertrauen und Lernen.

1) Selektion

Welche Entitäten braucht dieser Step? Datei X, Test Y, ADR Z – nicht „alles Billing“.

Pattern: Task → Entity Extract → Candidate Set → Rank → Top-n.

2) Beschaffung

Quellen: Git working tree, Blob-Store, Vector DB, Issue-API, CI-API, Memory-Server – möglichst über MCP Tools/Resources, damit Hosts austauschbar bleiben.

3) Repräsentation

Situation	Bessere Form
Bugfix	Stacktrace + failing test + minimale repro-Datei
API-Änderung	Interface + Aufrufer-Liste, nicht ganzes Package
Review	Diff + Acceptance Criteria
Architektur	ADR-Abstract + betroffene Diagramme/Module
Logs	tail + filter + correlation id, nicht 50k Zeilen

4) Budgetierung

Selbst mit guter Selektion und sauberer Repräsentation endet jedes Window irgendwann. Budgetierung ist der Moment, in dem du explizit priorisierst – nicht der Moment, in dem du hoffst, das Modell „finde schon das Wichtige“.

Harte Kontingente z. B.:

• System/Policies ≤ 10 %
• Task + Spec ≤ 15 %
• Code/Diffs ≤ 40 %
• Docs/Memory ≤ 20 %
• Tools-Schemas + Results ≤ 15 %

Overflow-Strategien: summarize, spill to Memory-Resource, drop lowest rank.

5) Aktualität & Provenance

Jeder geladene Block sollte idealerweise tragen:

• Quelle (URI/path),
• Revision (commit, etag, timestamp),
• optional Vertrauensstufe (user, tool, web, repo).

6) Schutz & Redaction

Vor dem Window: Secret-Scanner, .env-Blocklisten, PII-Filter, Pfad-Allowlists. Was nie geladen wird, kann nicht leaken.

7) Feedback & Persistenz

• User-Korrekturen und Architekturentscheidungen → Project Memory
• Erfolgreiche Strategien → Prompt-Templates (MCP Prompts)
• Fehlschläge → Eval-Cases

Zusammen bilden die Hebel den Betriebsrahmen von Context Engineering: Du wählst und holst Kontext, formst und dosierst ihn, kennzeichnest Herkunft, schützt sensible Daten und speicherst nur das, was später wieder nützt. Die folgende Pattern-Tabelle übersetzt diese Hebel in wiederkehrende Arbeitsmuster – die du in Hosts, MCP-Servern und Policies wiederfinden wirst.

Context Engineering Patterns (Cheat Sheet)

Die folgende Übersicht ist als Arbeitsgedächtnis gedacht, nicht als Pflichtprogramm. Du brauchst nicht alle Patterns in jedem Projekt. Typischer Einstieg in Coding-Teams: Working Set + On-Demand Loading + Pinned Policies; der Rest kommt, wenn die Failure Modes es erzwingen (zu teuer, zu unsicher, zu viele Agenten).

Pattern	Idee	Wann
On-Demand Loading	erst Metadaten, dann Inhalt	große Repos
Selective Resource Exposure	Host zeigt nur erlaubte URIs	Multi-Tenant, Secrets
Working Set	stabile Kernmenge pro Task	längere Agent-Läufe
Progressive Disclosure	Zusammenfassung → Detail auf Tool-Call	Docs, Logs
Diff-First	Änderungen vor Volltext	Reviews, Fixes
Observation Compression	Tool-Output kürzen/strukturieren	Shell, CI-Logs
Memory Upsert	Entscheidung speichern, nicht erneut raten	Multi-Session
Dual Context	Planner sieht Plan-State, Worker sieht lokale Dateien	Multi-Agent (Kap. 5/8)
Just-in-Time Tools	nur relevante Tool-Schemas injizieren	viele MCP-Server
Pinned Policies	kurze, stabile Regeln immer laden	Compliance

Mini-Policy in Code (illustrativ)

from dataclasses import dataclass
from typing import Iterable


@dataclass
class ContextItem:
    kind: str          # "diff" | "file" | "doc" | "memory" | "tool_result"
    uri: str
    tokens: int
    score: float       # Relevanz 0..1
    trusted: bool
    content: str


@dataclass
class Budget:
    max_tokens: int
    reserved_system: int = 800


def select_context(
    items: Iterable[ContextItem],
    budget: Budget,
    min_score: float = 0.35,
) -> list[ContextItem]:
    """Wählt Kontext nach Score und Budget – Kern einer Context Policy."""
    remaining = budget.max_tokens - budget.reserved_system
    chosen: list[ContextItem] = []

    for item in sorted(items, key=lambda x: x.score, reverse=True):
        if item.score < min_score:
            continue
        if not item.trusted and item.kind == "tool_result":
            # untrusted: nur stark gekürzt (hier: skip als harte Demo-Policy)
            continue
        if item.tokens > remaining:
            continue
        chosen.append(item)
        remaining -= item.tokens

    return chosen

def compress_tool_result(raw: str, max_chars: int = 4000) -> str:
    """Observation vor dem Window komprimieren (Host-Sprache egal; hier Python)."""
    if len(raw) <= max_chars:
        return raw
    head = raw[: max_chars // 2]
    tail = raw[-max_chars // 2 :]
    snipped = len(raw) - max_chars
    return f"{head}\n\n/* … snip {snipped} chars … */\n\n{tail}"

Context Engineering und MCP – Arbeitsteilung

{ width=100% }

Merke dir die Arbeitsteilung so:

• MCP standardisiert Anschluss und Austausch – welche Capabilities es gibt und wie man sie aufruft.
• Context Engineering entscheidet Steuerung und Qualität – was wann ins Window darf und warum.
• Ohne Policy wird MCP zum teuren Kabelsalat: viele Server, alles rein, nichts hilft.

In der Softwareentwicklung heißt das konkret: Ein guter Git-MCP-Server macht Diffs und Logs verfügbar. Ob der Agent vor einem Fix den failing Test, die drei relevanten Dateien und die Acceptance Criteria sieht – oder die halbe Historie plus drei veraltete Wikis – ist keine MCP-Frage, sondern Context Engineering.

Rollen im Team (Ausblick Kap. 13)

• Context Engineer – Policies, Budgets, Eval der Kontextqualität
• MCP Server Engineer – saubere Tools/Resources, Versionierung, Security
• Agent Infrastructure – Host, Orchestration, Observability

Schon jetzt lohnt die Aufteilung der Verantwortung: Wer „Prompt-Text“ besitzt, ist nicht automatisch Owner der Kontext-Pipeline.

Anti-Patterns der Disziplin

1. Window-Maximalismus – „1M Tokens, also alles rein“
2. Ein Prompt für alle Tasks – ohne Selektion
3. Memory als Append-only Chat-Müll – ohne Struktur und Decay
4. Tools als stiller Kontext-Dump – cat statt gezielter Resource
5. Keine Provenance – niemand weiß, welche Version der Agent sah
6. Optimierung nur auf Demo-Happy-Path – ohne Eval-Set und Failure Replay

---

Best Practices

1. Formuliere pro Agenten-Task ein explizites Working Set (Dateien, Tests, Constraints).
2. Bevorzuge Ausführung vor Behauptung: Tests, Typechecker, Linter als Tools.
3. Speichere Entscheidungen als strukturierte Memory-Items, nicht nur in Chat-Historie.
4. Kürze Tool-Outputs aggressiv; behalte Fehlerzeilen und Exit-Codes.
5. Trenne vertrauenswürdige Repo-Inhalte von untrusted Web/Tool-Text.
6. Führe ein leichtgewichtiges Context Review in Postmortems: Was fehlte im Window?
7. Versioniere Policies und Prompt-Templates wie Code.

---

Pitfalls

Pitfall	Folge	Gegenmaßnahme	Kapitel-Querverweis
Halluzinierte „grüne Tests“	Scheinqualität	echtes run_tests-Tool	Kap. 3
CoT als Wahrheit	falsche Sicherheit	Verifikation, nicht Rhetorik	Kap. 3
Secrets im Kontext	Leak / Compliance	Redaction-Pipeline	Kap. 3
Session = Wahrheit	Drift über Tage	episodic Memory + ADRs	Kap. 3
Zu viele MCP-Server ohne Policy	Tool-Confusion	Just-in-Time Tools, Routing	Kap. 3
Nur Prompt-Tuning bei Systemfehlern	Symptombekämpfung	Context Engineering + Evals	Kap. 3

---

Key Takeaways

• LLMs sind stark in Transformation, Erklärung und Musterübertragung – schwach in Wahrheit ohne Grounding.
• Grenzen (Halluzination, Stichtag, Budget, Non-Determinismus) diktieren Agenten-Architektur.
• Memory ist Systemdesign; nutze Working-, Session-, Episodic-, Semantic- und Procedural-Schichten.
• Kontextqualität hat die Dimensionen Relevanz, Aktualität, Form, AuthZ und Provenance.
• Context Engineering steuert Selektion, Beschaffung, Repräsentation, Budget, Schutz und Feedback.
• MCP liefert standardisierte Hebel; ohne Policy bleibt der Nutzen begrenzt.
• Miss Task Success, Edit Rate und Tokens/Task – nicht nur Modell-Benchmarks.

---

Was als Nächstes kommt

Kapitel 4 führt KI-Agenten formal ein (Perceive–Reason–Act, ReAct, Plan-and-Execute) und vertieft das Model Context Protocol als universelle Sprache für Tool- und Kontext-Interaktion: Architektur, Primitives, Vergleich zu Function Calling und Nutzen für Softwareentwicklungs-Agenten.

---

Übungsanregungen

1. Aufgabe: Nimm den letzten fehlgeschlagenen Agent- oder Copilot-Lauf und klassifiziere den Fehler: Modell, Kontext, Tool, Policy? Bezug: Kap. 3.2 · Zeit: ~20 Min Definition of Done: ☐ eine Ursache primär markiert ☐ eine Gegenmaßnahme notiert

2. Aufgabe: Definiere eine Budget-Tabelle für euren häufigsten Bugfix-Flow. Bezug: Kap. 3.7 · Zeit: ~25 Min Definition of Done: ☐ max_steps und max_tokens gesetzt ☐ Verify-Tool benannt

3. Aufgabe: Liste 10 Dinge für Project Memory als memory://…-URIs. Bezug: Kap. 3 · Demo-Konventionen in code/05-coding-agent · Zeit: ~20 Min Definition of Done: ☐ 10 URIs ☐ Owner pro URI skizziert

4. Aufgabe: Schreibe eine Redaction-Regel für Pfade und Env-Patterns. Bezug: Kap. 3 / 11 · Zeit: ~15 Min Definition of Done: ☐ mind. 3 Globs ☐ Beispiel „vor/nach“

TRACE-DEMO-1 (Ausblick): Im Companion-Demo siehst du, wie selektive Resources Context Waste senken – Kap. 10.8.6, Anhang C.12.