KI-Coding-Agenten ertrinken im Kontext: wie Sie Tool-Output um 98% reduzieren, ohne Sitzungswissen zu verlieren

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Ich entwickle bei DennisCraft AI Studio produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres. Der teuerste Fehler in KI-Coding-Agenten ist aus meiner Sicht selten das Modell selbst, sondern der Moment, in dem der Agent sein Kontextfenster mit Tool-Output füllt und danach nicht mehr sauber begründen kann, warum er eine Datei überhaupt geändert hat.

In regulierten Umgebungen ist das mehr als nur ein Kostenproblem. Wenn der Agent sein Sitzungswissen zwischen zwei Läufen nicht sauber verdichtet, verlieren Sie Nachvollziehbarkeit, Wiederanlaufbarkeit und im schlimmsten Fall die Konsistenz Ihrer Änderungen. Genau dort beginnen in Produktivsystemen die stillen Defekte, nicht in der Demo.

Das Kernproblem: ungefilterter Rückkanal aus den Werkzeugen

Viele Teams sprechen zuerst über die Werkzeuge selbst: grep, semgrep, bandit, gitleaks, Tests, diff, Datenbankabfragen. Das ist nicht der schwierige Teil. Entscheidend ist, was nach dem Werkzeugaufruf zurück in den Modellkontext gelangt.

Die Dokumentation von Anthropic zu Tool-Nutzung und Prompt-Gestaltung weist seit 2024 klar in diese Richtung: begrenzter, strukturierter Kontext statt unkontrollierter Wiederholung von Protokollen. Auch das OpenAI Cookbook argumentiert bei langen Kontexten und Retrieval ähnlich: Das Modell sollte kompakten Zustandskontext erhalten und Details nur bei Bedarf nachladen. Quellen: Anthropic Docs, 2024–2025, https://docs.anthropic.com/ ; OpenAI Cookbook, 2024, https://cookbook.openai.com/.

In meinen letzten produktiven Agentensystemen ließ sich der Anteil des Tool-Outputs, der tatsächlich wieder in den Modellkontext gelangt, um rund 98% senken. Nicht durch weniger Werkzeuge, sondern durch bessere Zustandsverdichtung.

Was in den Prompt gehört und was nicht

Im Prompt bleibt nur der Entscheidungszustand

Das Modell braucht nicht in jedem Schritt den vollständigen Bericht von bandit oder eine lange Testausgabe. Es braucht den kompakten Arbeitszustand: Ziel, betroffene Dateien, erkannte Probleme, bereits umgesetzte Entscheidungen und den nächsten sinnvollen Schritt.

Rohartefakte gehören in Postgres oder Supabase

Ich speichere vollständige Werkzeugausgaben mit run_id, Werkzeugname, Pfad, Schweregrad und Rohdaten außerhalb des Modellkontexts. In den Prompt gelangt nur eine normalisierte Zusammenfassung. Wenn das Modell Details benötigt, fordert es gezielt genau dieses Artefakt an.

Sitzungswissen ist nicht gleich Chat-Verlauf

Ein vollständiger Verlauf ist meist teuer und wenig präzise. Besser ist ein eigenes Zustandsobjekt mit Ziel, Randbedingungen, Architekturentscheidungen, veränderten Dateien, offenen Risiken und nächster Aktion. Dieses Objekt lässt sich über mehrere Sitzungen hinweg stabil weitergeben.

from dataclasses import dataclass, asdict
import json

@dataclass
class SessionMemory:
    goal: str
    constraints: list[str]
    decisions: list[str]
    touched_files: list[str]
    open_risks: list[str]
    next_action: str

def serialize_memory(memory: SessionMemory) -> str:
    return json.dumps(asdict(memory), separators=(",", ":"))

memory = SessionMemory(
    goal="SQL-Interpolation durch Parameter ersetzen",
    constraints=["Öffentliche Repository-API unverändert lassen"],
    decisions=["Parametrisierte Abfragen verwenden", "Tests zuerst anpassen"],
    touched_files=["app/repo.py", "tests/test_repo.py"],
    open_risks=["Alte Hilfsfunktion erzeugt noch rohes SQL"],
    next_action="Hilfsfunktion prüfen und Tests nachziehen"
)

Ein Muster, das im Produktivbetrieb trägt

Ich verwende dafür einen einfachen Zyklus aus 4 Phasen: ausführen, verdichten, speichern, wiederabrufen.

Ausführen

Das Werkzeug läuft wie vorgesehen: semgrep, bandit, gitleaks, Unit-Tests, git diff oder Datenbankprüfung.

Verdichten

Die Rohdaten werden in ein festes Schema überführt. Zum Beispiel: Werkzeug, Status, Anzahl der Befunde, betroffene Dateien, wichtigstes Risiko, empfohlene nächste Aktion. Genau dieses feste Schema hält den Rückkanal für das Modell kontrollierbar.

Speichern

Sowohl Rohartefakte als auch verdichtete Zusammenfassungen werden in Postgres abgelegt. Das ist nicht nur effizient, sondern hilft auch bei Nachweis- und Prüfpflichten, etwa im Rahmen von ISO 27001, BSI Grundschutz oder NIS2-orientierten internen Kontrollen.

Wiederabrufen

Eine neue Sitzung startet aus dem kompakten Zustandsobjekt. Ein Rohartefakt wird nur nachgeladen, wenn es für die aktuelle Entscheidung wirklich nötig ist.

type ToolSummary = {
  tool: string
  status: "ok" | "fail"
  findings: number
  files: string[]
  nextAction: string
}

function summarizeSemgrep(json: any): ToolSummary {
  const results = json.results ?? []
  const files = [...new Set(results.map((r: any) => r.path))]
  return {
    tool: "semgrep",
    status: results.length ? "fail" : "ok",
    findings: results.length,
    files: files.slice(0, 10),
    nextAction: results.length ? "markierte Pfade korrigieren" : "fortfahren"
  }
}

Warum das für Sicherheit und Regulierung relevant ist

Wenn ein Coding-Agent mit Protokollen überladen ist, sinkt die Wahrscheinlichkeit, dass er sicherheitsrelevante Signale richtig priorisiert. Das ist besonders kritisch, wenn derselbe Agent Code erzeugt, ändert und seine Ergebnisse teilweise selbst bestätigt. Die bekannten Risikoklassen aus dem OWASP Top 10 verschwinden dadurch nicht: Injection, fehlerhafte Zugriffskontrolle und versehentlich übergebene Geheimnisse bleiben reale Probleme. Quelle: OWASP Top 10, 2021, https://owasp.org/www-project-top-ten/.

Für DACH-Unternehmen kommt hinzu: Unter DSGVO, EU AI Act und internen Vorgaben aus ISO 27001 oder BSI Grundschutz ist Nachvollziehbarkeit kein Nebenthema. Sie müssen nicht jeden Token archivieren, aber Sie sollten belegen können, welche Werkzeuge gelaufen sind, welche Befunde vorlagen und auf welcher verdichteten Grundlage der nächste Schritt erfolgte.

#!/usr/bin/env bash
set -euo pipefail

semgrep --config auto --json > /tmp/semgrep.json || true
bandit -r . -f json -o /tmp/bandit.json || true
gitleaks detect --report-format json --report-path /tmp/gitleaks.json || true

python scripts/store_results.py \
  --run-id "$RUN_ID" \
  --semgrep /tmp/semgrep.json \
  --bandit /tmp/bandit.json \
  --gitleaks /tmp/gitleaks.json

Die kleinste sinnvolle Umsetzung

Sie brauchen dafür keine neue Plattform. Wenn Sie bereits Claude Code, das Anthropic SDK, n8n oder einen eigenen Orchestrator nutzen, ergänzen Sie 3 Bausteine:

In n8n genügt dafür oft ein Knoten zum Ausführen der Prüfungen, ein Knoten zur JSON-Verdichtung, ein Knoten zum Speichern und ein Knoten zum Zusammenstellen des nächsten Prompts. Tool-Output ist ein Protokollstrom. Er sollte nicht Ihr Arbeitsspeicher werden.

FAQ

Sollten Sie vollständige Chat-Verläufe speichern?

In der Regel nein. Für Coding-Agenten sind vollständige Verläufe teuer und oft unpräzise. Speichern Sie besser Entscheidungen, Randbedingungen, Artefakte und Verweise auf Rohprotokolle.

Ist das einfach nur RAG?

Nein. RAG eignet sich für die Suche in Code, Dokumentation oder früheren Läufen. Sitzungswissen ist dagegen ein eigener strukturierter Zustandsdatensatz für die aktuelle Aufgabe.

Geht das ohne Supabase?

Ja. Ein normales Postgres reicht aus. Supabase ist vor allem dann praktisch, wenn Sie bereits API- und Zugriffsbausteine dort betreiben.

Warum nicht einfach ein größeres Kontextfenster verwenden?

Weil nicht nur die Größe zählt, sondern die Signalqualität. Ein größeres Fenster hilft wenig, wenn entscheidende Informationen zwischen Protokollzeilen verschwinden.

Wie messen Sie den Effekt?

Ich beobachte Token pro erfolgreich erledigter Aufgabe, wiederholte Dateilesungen pro Lauf, Erfolgsquote nach Sitzungsunterbrechungen und die Zeit bis zur Korrektur nach einem Neustart. Diese Kennzahlen zeigen schnell, ob das Sitzungswissen tatsächlich trägt.

Wenn Sie Coding-Agenten bereits produktiv einsetzen: An welcher Stelle verliert Ihr System nach längeren Werkzeugketten zuerst an Qualität — bei Roh-Tool-Outputs, bei wiederholtem Dateilesen oder beim Sitzungswissen über Neustarts hinweg? Diese Erfahrung aus dem Feld interessiert mich wirklich.

Ich biete einen kostenfreien 30-Minuten-Stack-Audit für DACH-Gründer und CTOs an, die KI in regulierten Märkten aufbauen. Schreiben Sie mir auf LinkedIn oder an @ger_dennis_ai.