03 Kontext und vertikale Slices

Ein Agent braucht den Kontext, der seine aktuelle Aufgabe lösbar macht. Zu viele fremde Themen, alte Entscheidungen und ungefilterte Tool-Ausgaben können relevante Informationen verdrängen.

Das Diagramm zeigt zwei Arten, den Arbeitskontext zusammenzustellen. Es beschreibt ein Risiko, keine feste Leistungsgrenze.

%%{init: {"look":"handDrawn","theme":"neutral","themeVariables":{"fontFamily":"Excalifont, Virgil, Chalkboard SE, Comic Neue, cursive","fontSize":"14px"}}}%%
flowchart LR
    accTitle: Überladener und fokussierter Arbeitskontext
    accDescr: Vermischte Themen erhöhen das Risiko übersehener Details. Ein begrenzter Auftrag mit passendem Kontext lässt sich gezielt bearbeiten und prüfen.
    A("Alles im Prompt<br/>Historie, Logs, fremde Themen") ==> B("Agent<br/>Vermischte Aufgaben") ==> C("Risiko<br/>Details übersehen")
    D("Passender Kontext<br/>Ziel, Regeln, relevante Quellen") ==> E("Agent<br/>Ein begrenztes Thema") ==> F("Ergebnis<br/>Gezielt prüfen")
    class A,D storage
    class B,E,F service
    class C external
    classDef ingress fill:#eff6ff,stroke:#2563eb,stroke-width:1.5px,color:#0f172a
    classDef service fill:#f0fdf4,stroke:#15803d,stroke-width:1.5px,color:#0f172a
    classDef storage fill:#f1f5f9,stroke:#64748b,stroke-width:1.5px,color:#0f172a
    classDef external fill:#fef3c7,stroke:#b45309,stroke-width:1.5px,color:#0f172a
    classDef boundary fill:none,stroke:#cbd5e1,stroke-width:1px,color:#475569

Warum der Agent plötzlich „dümmer“ wirkt¶

Kontext umfasst Auftrag, Regeln, gelesene Dateien, Gesprächsverlauf und Tool-Ergebnisse. Das Kontextfenster begrenzt, wie viel hineinpasst. Es garantiert nicht, dass der Agent alles gleich zuverlässig nutzt.

Lost in the Middle zeigt für die untersuchten Modelle und Suchaufgaben: Relevante Informationen wurden in der Mitte langer Eingaben schlechter genutzt. Daraus folgt keine universelle Token-Grenze für heutige Coding-Agents.

Im Alltag sind Warnzeichen: Der Agent übersieht vereinbarte Regeln, greift verworfene Ansätze wieder auf oder vermischt Aufgaben. Das kann an überladenem Kontext liegen; auch unklare Anforderungen oder fehlende Fakten kommen infrage.

Kontext gezielt pflegen¶

• Auftrag begrenzen: Ein Ziel, klare Grenzen und beobachtbare Akzeptanzkriterien.
• Quellen nachladen: Relevante Dateien und Abhängigkeiten lesen, sobald sie gebraucht werden. Pfade statt vollständiger Archive weitergeben.
• Stand verdichten: Entscheidungen, offene Fragen und Prüfergebnisse festhalten. Wiederholte Logs und verworfene Versuche weglassen.
• Sauber übergeben: Beim Themenwechsel einen frischen Arbeitskontext mit kurzem Übergabestand nutzen. Wichtige Regeln und Quellen mitgeben.

Diese Maßnahmen folgen dem Ansatz des Context Engineering bei Anthropic: Kontext auswählen, bei Bedarf laden und über längere Arbeit hinweg pflegen. Notwendige Informationen dürfen beim Kürzen nicht verloren gehen. Quellen geprüft am 3. November 2026.

Second Brain: Projektwissen statt Chat-Gedächtnis¶

Ein Second Brain ist hier ein gepflegtes Projektgedächtnis außerhalb des Chats. Es macht Wissen über Sessions hinweg auffindbar. Der Agent wird dadurch nicht neu trainiert: Er kann auf relevante Regeln, Entscheidungen und Erfahrungen zugreifen, statt sie jedes Mal neu herzuleiten.

Unser minimaler Ansatz nutzt Dateien und Issues, die das Team lesen und korrigieren kann:

Der Kreislauf: passendes Wissen laden, ein Thema bearbeiten, Ergebnis prüfen, haltbare Erkenntnisse zurückschreiben. Jeder Eintrag braucht Geltungsbereich und Beleg, etwa einen Test oder eine bestätigte Entscheidung. Hypothesen bleiben als offen markiert; überholte Aussagen werden ersetzt. Pro Aussage gibt es eine maßgebliche Stelle, andere Dokumente verlinken darauf.

Beispiel: Ein Agent übersieht beim CSV-Export die Zugriffsrechte. Nach der bestätigten Korrektur hält das Issue den Befund fest; ein Regressionstest sichert ihn ab. Beim nächsten Export-Auftrag findet der Agent den Test über die verlinkten Quellen. So wird aus einem Fehler nutzbares Projektwissen.

Das Diagramm zeigt das Projektgedächtnis als Kreislauf. In den Arbeitskontext kommt nur das Wissen für das aktuelle Thema.

%%{init: {"look":"handDrawn","theme":"neutral","themeVariables":{"fontFamily":"Excalifont, Virgil, Chalkboard SE, Comic Neue, cursive","fontSize":"14px"}}}%%
flowchart LR
    accTitle: Second Brain für fokussierte Agents
    accDescr: Der Agent lädt relevantes Projektwissen, bearbeitet und prüft einen Slice und schreibt belegte Erkenntnisse in das Projektgedächtnis zurück.
    M("Projektgedächtnis<br/>Regeln, Quellen, Entscheidungen") ==> K("Kontext laden<br/>Passend zum Thema") ==> A("Slice bearbeiten<br/>Ergebnis prüfen") ==> W("Erkenntnis sichern<br/>Mit Geltungsbereich und Beleg")
    W ==> M
    class M,W storage
    class K,A service
    classDef ingress fill:#eff6ff,stroke:#2563eb,stroke-width:1.5px,color:#0f172a
    classDef service fill:#f0fdf4,stroke:#15803d,stroke-width:1.5px,color:#0f172a
    classDef storage fill:#f1f5f9,stroke:#64748b,stroke-width:1.5px,color:#0f172a
    classDef external fill:#fef3c7,stroke:#b45309,stroke-width:1.5px,color:#0f172a
    classDef boundary fill:none,stroke:#cbd5e1,stroke-width:1px,color:#475569

Ein Agent pro Thema: der vertikale Slice¶

Ein vertikaler Slice ist eine kleine, vollständig prüfbare Verhaltensänderung über alle nötigen Schichten hinweg. Beispiel: Ein Nutzer kann sein Passwort über einen einmaligen Link zurücksetzen. Dazu gehören Oberfläche, API, Token-Verarbeitung und Tests, soweit die Aufgabe sie betrifft.

Unser Zuschnitt: Ein Agent verantwortet dieses Thema vom Verständnis bis zum Nachweis. Eine Aufteilung in Frontend-, Backend- und Datenbank-Spezialisten würde dieselbe Anforderung über mehrere Übergaben verteilen. Der Slice hält die zusammengehörigen Entscheidungen in einem Arbeitskontext.

Der Auftrag enthält Ziel, betroffene Grenzen, relevante Quellen und Prüfungen. Wird das Thema zu groß, schneiden wir kleinere, jeweils prüfbare Verhaltensänderungen. Weitere Agents übernehmen andere Themen. Gemeinsame Schnittstellen vorher klären; parallel arbeiten nur, wenn die Änderungen ausreichend unabhängig sind. Ein unabhängiger Review kann die Prüfung ergänzen.

Das Diagramm zeigt zwei Themen mit jeweils eigener Verantwortung über die betroffenen Schichten. Es legt keine parallele Ausführung fest.

%%{init: {"look":"handDrawn","theme":"neutral","themeVariables":{"fontFamily":"Excalifont, Virgil, Chalkboard SE, Comic Neue, cursive","fontSize":"14px"}}}%%
flowchart TB
    accTitle: Ein Agent pro vertikalem Slice
    accDescr: Agent A verantwortet das Zurücksetzen eines Passworts, Agent B einen CSV-Export. Jeder bearbeitet die nötige Oberfläche, Logik und Datenverarbeitung bis zum geprüften Verhalten.
    subgraph RESET["Thema: Passwort zurücksetzen"]
        direction TB
        A("Agent A<br/>Verantwortung für den Slice")
        AU("Oberfläche<br/>Reset anfordern")
        AD("API und Daten<br/>Einmaligen Token verarbeiten")
        AT("Verhalten prüfen<br/>Reset und Fehlerfälle")
        A ==> AU ==> AD ==> AT
    end
    subgraph EXPORT["Thema: CSV-Export"]
        direction TB
        B("Agent B<br/>Verantwortung für den Slice")
        BU("Oberfläche<br/>Export anfordern")
        BD("API und Daten<br/>Berechtigte Datensätze exportieren")
        BT("Verhalten prüfen<br/>Inhalt und Zugriffsrechte")
        B ==> BU ==> BD ==> BT
    end
    class A,B ingress
    class AU,AD,BU,BD service
    class AT,BT storage
    class RESET,EXPORT boundary
    classDef ingress fill:#eff6ff,stroke:#2563eb,stroke-width:1.5px,color:#0f172a
    classDef service fill:#f0fdf4,stroke:#15803d,stroke-width:1.5px,color:#0f172a
    classDef storage fill:#f1f5f9,stroke:#64748b,stroke-width:1.5px,color:#0f172a
    classDef external fill:#fef3c7,stroke:#b45309,stroke-width:1.5px,color:#0f172a
    classDef boundary fill:none,stroke:#cbd5e1,stroke-width:1px,color:#475569