Der AI-SDLC und die Context Engine

In den ersten sechs Monaten, in denen wir Agents auf Produktionscode laufen ließen, war der Failure-Modus nicht Halluzination. Es war Amnesie. Dasselbe Modell schlug in Woche acht denselben bereits abgelehnten Ansatz vor, den es in Woche drei vorgeschlagen hatte. Es griff zu einer Deprecated-API, von der das Team im vorigen Quartal weggemigriert war. Es erfand eine interne Style-Konvention, die nie existiert hatte, weil der Prompt die echte nicht mitführte. Keines davon war ein Modellqualitätsproblem. Es waren Context-Probleme.

Die Context Engine ist SprintLoops Antwort: ein fünfdimensionales, geschichtetes Context-Bundle, das mit jedem Agent-Dispatch reist, sich weigert auszuliefern, wenn Policy versagt, und aus jeder geschlossenen Lane lernt.

Die fünf Dimensionen

Ein SprintLoop-Dispatch trägt ein BMAD-Bundle (Brief, Memory, Architecture, Decisions — in der Praxis fünf Dimensionen, aber das Akronym ist älter als die Hinzunahme von Style und wurde grandfathered). Die Dimensionen:

Dimension	Was sie erfasst	Wo sie lebt
Product	User-facing Feature-Spec, Akzeptanzkriterien, Edge Cases	Verlinktes Issue, Lane-Brief, Produkt-Wiki
System	Architekturdiagramme, Repo-Map, Service-Grenzen, Ownership	Auto-extrahiert aus dem Repo + manuelle Edits
Style	Coding-Konventionen, Namensgebung, Error-Handling, Log-Formate	Repo-`.sprintloop/style.md` + Linter-Configs
Policy	Harte Regeln — Sicherheit, Compliance, deprecated APIs, gebannte Dependencies	Workspace-Policy-File, vom Owner signiert
Memory	Vergangene Lane-Outcomes, abgelehnte Ansätze, akzeptierte Patterns	Auto-abgeleitet aus geschlossenen Lanes + Sign-off-Notes

Jede Dimension füttert den dispatchten Agent über einen anderen Mechanismus. Product und System gehen meistens in den System-Prompt. Style wird als Tool angeboten, das der Agent abfragen kann (style.lookup("error handling for HTTP clients")). Policy wird vor dem Dispatch und bei jedem Tool-Invocation enforced. Memory wird on-demand per Vector-Search retrieved.

Wie ein Dispatch das Bundle zusammenstellt

Wenn du Dispatch klickst, läuft im Workspace ein Context-Build:

Product pullen. Der Lane-Brief, plus die Akzeptanzkriterien jedes verlinkten Issues, plus explizit vom Dispatcher angehängte Referenzdokumente.
System pullen. Bei jedem Push wird eine Repo-Map extrahiert; der Dispatch greift sich den für den Scope-Claim der Lane relevanten Slice. Wenn der Agent apps/api/auth/** anfasst, bekommt er den Directory-Tree des Auth-Service, Ownership-Tags und unmittelbare Dependencies — nicht das ganze Monorepo.
Style pullen. Was in .sprintloop/style.md steht, plus extrahierte Configs aus .eslintrc, .prettierrc, pyproject.toml usw.
Policy pullen. Immer. Es gibt keinen Opt-out. Policy-Verstöße brechen den Dispatch ab, bevor ein einziger Token verbraucht wird.
Memory pullen. Eine Vector-Search über geschlossene Lanes, die überlappende Pfade angefasst oder überlappende Sprache verwendet haben. Default auf die letzten 90 Tage limitiert; pro Workspace tunbar.

Das Bundle wird signiert und an den Start-Eintrag der Lane angehängt. Wenn die Lane schließt, kannst du das Bundle öffnen und exakt sehen, womit der Agent arbeiten konnte.

Policy: der Hard-Fail

Die meisten Dimensionen sind advisory. Policy ist es nicht.

Ein Policy-File sieht so aus — ein echtes Fragment von einem Healthcare-Kunden:

forbid:
  - paths: ["src/lib/legacyAuth/**"]
    reason: "Legacy auth path; rewrite blocked until migration finishes 2026-Q2"
  - dependencies: ["moment", "request"]
    reason: "Banned: replace with date-fns / native fetch"
require:
  - test_coverage_delta: ">= 0"
  - reviewer: "security"
    on_paths: ["**/auth/**", "**/billing/**"]

Wenn ein Bundle-Build eines Dispatch eine Policy-Klausel trifft, passieren je nach Klausel-Typ zwei Dinge:

Pre-dispatch Hard-Fail. forbid.paths- oder forbid.dependencies-Klauseln, die offensichtlich vom Brief getriggert würden, brechen den Dispatch sofort ab. Der Dispatcher sieht ein Banner, das die Regel und den Grund nennt; es werden keine Tokens verbraucht.
Runtime Hard-Fail. Die Harness kann trotzdem versuchen — sie weiß vielleicht nicht, dass Policy auf eine spezifische Datei zutrifft, bis sie sie liest. Wenn sie versucht, einen verbotenen Pfad zu schreiben, returned die Storage-Schicht POLICY_DENIED mit dem Regelnamen. Der Agent sieht das Denial in seinem Tool-Log und redirected oder bleibt hängen.
Sign-off Hard-Fail. require.reviewer: "security" enforced, dass ein Security-Reviewer (Mensch oder Agent) abgenommen hat, bevor die Lane schließen kann. Kein Exception-Pfad. Der Merge-Button bleibt deaktiviert.

Der Grund, warum Policy die einzige Hard-Fail-Dimension ist, ist regulatorisch: Ein Workspace im SOC-2-/HIPAA-/PCI-Scope kann keine „advisory” Regel haben, an der sich ein Agent vorbeireden kann. Wenn deine Policy sagt „fass Billing nicht ohne Security-Reviewer an”, enforced das System das mechanisch.

Memory: wie sich Lernen verzinst

Die interessante Dimension über die Zeit ist Memory. Jede geschlossene Lane schreibt ein paar Signale zurück in den Memory-Store des Workspaces:

Approved Patterns. Code, den die Lane ausgeliefert hat und den der Reviewer abgenommen hat, embedded fürs Retrieval.
Rejected Approaches. Sign-off-Notes, die sagen „funktioniert, aber so machen wir das hier nicht”, werden zu Negativ-Beispielen.
Failed Assumptions. Wenn der Agent falsch über die Codebase geraten hat und der Mensch ihn korrigiert hat, wird die Korrektur als Q&A-Paar gespeichert.
Domain-Vokabular. Namen, Abkürzungen, Akronyme spezifisch zur Domain des Teams, die in keinem öffentlichen Trainingsset auftauchen.

Memory-Retrieval ist auf den Workspace gescoped. Es leakt nicht zwischen Kunden. Es ist at-rest verschlüsselt mit dem eigenen Key des Workspaces.

Der Compounding-Effekt ist echt, aber langsam — drei bis vier Wochen aktive Nutzung, bevor du siehst, dass der Agent denselben Fehler nicht zweimal macht. Die Signale, die du direkt sehen kannst: der Memory-Tab auf jeder geschlossenen Lane zeigt, welche vergangenen Lanes der Dispatch retrieved hat, und die Diff-Seite zeigt, welche Memory-Einträge in der Commit-Message des Agents zitiert wurden.

Das Bundle bearbeiten

Du kannst das Bundle direkt aus dem Dispatch-Dialog bearbeiten: Klick Inspect bundle, sieh den zusammengestellten Prompt und Tool-Spec, edite jede Dimension inline, speichere und dispatch. Edits sind auf einen einzelnen Dispatch gescoped — sie mutieren die zugrundeliegende Source nicht. Wenn du eine permanente Änderung willst, ändere .sprintloop/style.md, die Policy-File, die System-Map etc. und re-extrahier.

Die Inspect-Bundle-View ist auch der schnellste Weg, einen Dispatch zu debuggen, der sich seltsam verhält. Wenn der Agent zu einer Deprecated-API greift, hat das Bundle wahrscheinlich nicht die Policy mitgeführt, die das bannt. Wenn der Agent eine Style-Konvention erfindet, war die Style-Dimension des Bundle dünn. Das Bundle ist die Wahrheit; das Verhalten des Agents ist Downstream.

Was als Nächstes kommt

Die Context Engine ist die eine Hälfte davon, wie ein SprintLoop-Dispatch gute Entscheidungen trifft. Die andere Hälfte ist das Review Committee — das Panel aus Reviewer-Agents, das den Diff bewertet, bevor er je einen Menschen erreicht.