Die Session ist die Commit-Nachricht

Ein Entwickler übernimmt eine Codebasis. git blame zeigt 47 geänderte Dateien in einem Commit. Die Nachricht lautet: „refactor auth module.” Als Commit-Autor ist ein menschlicher Entwickler angegeben. Der tatsächliche Autor war ein Coding-Agent, der 90 Minuten lang lief, 200 Dateien las, drei alternative Ansätze evaluierte, zwei davon aus konkreten Gründen verwarf und ein Änderungspaket produzierte, das jeden Authentifizierungs-Endpunkt betrifft. Die 90-minütige Session mit Design-Entscheidungen, verworfenen Alternativen und diskutierten Grenzfällen ist verschwunden. Git hat festgehalten, was sich geändert hat. Nichts hat festgehalten, warum.

Mein Beitrag über Cognitive Debt benannte die Kluft zwischen der Ausgabegeschwindigkeit von Agents und der Verständnisgeschwindigkeit von Entwicklern als „Cognitive Debt” — eine Verbindlichkeit, die sich mit jedem ungeprüften Commit aufbaut.¹ Das Memento-Projekt, das 100 HN-Punkte und 124 Kommentare sammelte, stellt die nächste Frage: Wenn die Session die Begründung enthält, sollte die Session dann Teil des Commits sein?²

TL;DR

Git erfasst, WAS sich geändert hat. Agent-Sessions erfassen, WARUM. Wenn Agents Code schreiben, ist das Session-Transkript das eigentliche Design-Dokument, und jeder Workflow, der das Transkript verwirft, verwirft die Herkunftsdokumentation. Memento (eine Open-Source-Git-Erweiterung) hängt KI-Session-Transkripte als Git Notes an Commits an und erzeugt so eine Herkunftskette vom Commit zur Begründung. Claude Codes neue LSP-Integration fügt strukturelles Code-Verständnis hinzu, das Session-Transkripte präziser macht: Go-to-Definition ersetzt grep, und Typsignaturen ersetzen Vermutungen. Im Folgenden: die Herkunftslücke, vier Ebenen von Session-Metadaten, was Memento aufbaut, wie LSP die Qualität von Session-Daten verändert, und minimale Herkunftspraktiken, die Sie heute umsetzen können.

Die Herkunftslücke

Git verfolgt fünf Dinge bei jeder Änderung: wer sie gemacht hat, wann, welche Dateien sich geändert haben, den Diff und eine Commit-Nachricht. Bei menschlich verfasstem Code überbrückt die Commit-Nachricht die Lücke zwischen dem Diff und der Absicht. Eine gute Nachricht erklärt, warum die Änderung existiert. Eine schlechte Nachricht („fix stuff”) überlässt es dem Reviewer, die Absicht aus dem Code zu rekonstruieren.

Agent-verfasster Code hat eine andere Herkunftsstruktur. Die Absicht lebt nicht im Kopf des Entwicklers. Die Absicht lebt in der Session: der Prompt, der die Aufgabe startete, die Dateien, die der Agent las, die Alternativen, die er evaluierte, die Tools, die er aufrief, und die Belege, die er bei der Fertigmeldung anführte. Eine Commit-Nachricht, die 90 Minuten Agent-Reasoning in einer Zeile zusammenfasst, verwirft 99,9 % des Entscheidungskontexts.

Der Verlust ist nicht theoretisch. Mein Orchestrierungssystem generiert Session-Zustandsdateien (jiro.state.json, jiro.progress.json), die jede Story-Fertigstellung, jedes Reviewer-Urteil und jedes Evidence-Gate-Ergebnis aufzeichnen.³ Wenn ein Reviewer fragt „Warum hat der Agent exponentielles Backoff statt Circuit Breaker verwendet?”, enthält die Session-Zustandsdatei die Antwort: Der Agent evaluierte beide Muster, stellte fest, dass der Upstream-Service wiederholbare 503er mit einem Retry-After-Header zurückgibt, und wählte exponentielles Backoff, um den Header-Wert zu berücksichtigen. Die Commit-Nachricht sagt „refactor: standardize retry patterns.” Die Session-Zustandsdatei sagt, warum.

Ohne Session-Herkunft wird Code-Review von Agent-verfassten Änderungen zur Archäologie. Der Reviewer liest den Diff, rekonstruiert die Begründung rückwärts und bildet eine Theorie darüber, warum die Änderung existiert. Die Theorie kann falsch sein. Die tatsächliche Begründung des Agents ist verfügbar, aufgezeichnet im Session-Transkript. Der branchenübliche Workflow (Commit, Push, Diff prüfen) wirft die Begründung weg.

Das Problem multipliziert sich mit Agent-Komposition. Mein Orchestrierungssystem startet spezialisierte Subagents für Code-Review: einen Korrektheitsprüfer, einen Sicherheitsprüfer, einen Konventionsprüfer.⁵ Jeder Subagent führt seine eigene Session, liest seine eigenen Dateien, zieht seine eigenen Schlüsse. Der übergeordnete Agent aggregiert die Urteile. Die finale Commit-Nachricht sagt „3 reviewers: approve.” Die drei einzelnen Review-Sessions — jede mit spezifischen Befunden, Grenzfallanalysen und Genehmigungsbegründungen — leben in separaten Transkripten, die der Commit niemals referenziert. Jede Ebene der Agent-Delegation fügt eine weitere Schicht unsichtbaren Reasonings hinzu.

Das Herkunftsproblem verbindet sich mit drei bestehenden Fehlermustern. Die Fabrication Firewall identifizierte, wie Agents ungeprüfte Behauptungen veröffentlichen, wenn kein Output-Gate existiert.⁶ Session-Herkunft hätte die Fälschung früher erkannt: Das Session-Transkript zeigte, dass der Agent eine Token-Zählmethodik erfand, die kein Mensch überprüfte. The Invisible Agent dokumentierte, wie Agent-Aktionen ohne explizite Instrumentierung unüberwacht bleiben.⁷ Session-Herkunft ist der Audit-Trail, den der Sichtbarkeitsstack erzeugt. Der NIST-Kommentar empfahl standardisiertes Audit-Logging für Agent-Aktionen.⁹ Git Notes, die Session-Transkripte speichern, sind eine Umsetzung dieser Empfehlung.

Das Evidence Gate in meinem Qualitätssystem verlangt vom Agent, für jedes Qualitätskriterium konkrete Belege zu benennen: das Muster benennen, Alternativen erklären, Grenzfälle auflisten, Testausgabe einfügen.¹⁰ Das Evidence Gate zwingt den Agent, Daten der Reasoning- und Verification-Ebene zu generieren, die sonst nicht existieren würden. Ohne das Gate meldet der Agent „fertig” und die Session enthält nur Process-Daten (Tool-Aufrufe). Mit dem Gate enthält die Session explizite Begründungen, die ein Reviewer gegen den Code verifizieren kann.

Git allein kann nicht zwischen einem 47-Dateien-Commit, der 90 Minuten sorgfältiges Reasoning repräsentiert, und einem 47-Dateien-Commit, der einen 90 Minuten lang unkontrolliert laufenden Agent ohne Review repräsentiert, unterscheiden. Die Git-Dokumentation beschreibt Notes als „zusätzliche Informationen über ein Objekt, die angehängt werden können, ohne das Objekt selbst zu verändern.”⁸ Session-Transkripte passen exakt auf diese Definition: zusätzliche Informationen über die Herkunft eines Commits, die weder den Commit-Hash noch den Diff noch die Historie verändern.

Die Memento-Frage

Das Memento-Projekt beantwortet die Herkunftslücke mit einer Git-Erweiterung.² Das Tool erfasst KI-Coding-Session-Transkripte und hängt sie als Git Notes an Commits an, gespeichert in refs/notes/commits und refs/notes/memento-full-audit.

Der Workflow: git memento init konfiguriert das Repository. git memento commit <session-id> ersetzt git commit, ruft automatisch das Session-Transkript vom konfigurierten KI-Anbieter (Codex oder Claude Code) ab und speichert es als strukturierte Metadaten am Commit.

Die HN-Diskussion mit 124 Kommentaren brachte vier Positionen hervor:

Position 1: Sessions sind essenzieller Kontext. Agent-Sessions enthalten die Begründung, die Commit-Nachrichten nicht liefern können. Das Anhängen von Sessions an Commits bewahrt die Herkunftskette. Reviewer können jede Codezeile über den Commit, die Session und den ursprünglichen Prompt zurückverfolgen.

Position 2: Sessions sind Rauschen. Ein 90-minütiges Session-Transkript umfasst Tausende Zeilen Konversation. Das meiste davon ist irrelevant für das finale Änderungspaket. Das Anhängen des vollständigen Transkripts vergräbt das Signal im Rauschen und macht Reviews schwieriger, nicht einfacher.

Position 3: Zusammenfassungen statt Transkripte. Die Session sollte in eine strukturierte Zusammenfassung destilliert werden: Aufgabenbeschreibung, betrachtete Alternativen, Entscheidungsbegründung, angeführte Belege. Die Zusammenfassung bewahrt die Herkunft ohne das Rauschen. Memento generiert Markdown-Zusammenfassungen, die mit Benutzer- und Assistenten-Turns gekennzeichnet sind.

Position 4: Datenschutz- und Sicherheitsbedenken. Session-Transkripte können API-Schlüssel, interne URLs, proprietären Code aus anderen Dateien oder Gesprächsinhalte enthalten, die der Entwickler nicht in einem permanenten Git-Eintrag haben möchte. Sessions erfordern Bereinigung vor dem Anhängen.

Alle vier Positionen haben Berechtigung. Der Herkunftswert von Sessions ist unbestreitbar. Das Rauschproblem ist real. Die Datenschutzbedenken sind strukturell. Memento adressiert Position 1 und 3 (Transkriptspeicherung mit Markdown-Konvertierung) und Position 4 (Transkripte als nicht vertrauenswürdige Daten für die Zusammenfassungsgenerierung behandeln). Position 2 bleibt eine offene Designfrage: Wie viel Session-Kontext ist genug?

Ein komplementäres Tool verfolgt einen anderen Ansatz für dasselbe Problem. claude-replay konvertiert Claude Code-Session-Transkripte in videoartige Wiedergabe, sodass Reviewer die Arbeit des Agents Schritt für Schritt verfolgen können, anstatt ein statisches Transkript zu lesen.¹² Wo Memento die Frage „Was sollten wir speichern?” beantwortet, beantwortet claude-replay „Wie sollten wir es prüfen?” Die beiden Tools adressieren verschiedene Teile des Herkunfts-Workflows: Memento bewahrt die Daten (Speicherung), claude-replay macht die Daten verständlich (Präsentation). Die Tatsache, dass beide Projekte unabhängig voneinander im selben Monat entstanden, bestätigt die These: Praktiker spüren die Herkunftslücke und bauen Tools, um sie zu schließen.

Vier Ebenen der Herkunft

Session-Metadaten von Agents organisieren sich in vier Ebenen, die jeweils eine andere Frage über die Änderung beantworten.

Jede Ebene verursacht Kosten. Die Speicherung der vollständigen Absichtsebene (ursprünglicher Prompt) ist günstig: ein Textfeld. Die Speicherung der vollständigen Prozessebene (jeder Tool-Aufruf) für eine 90-minütige Session generiert Megabytes an JSON. Die Speicherung der Reasoning-Ebene erfordert, dass der Agent seinen Entscheidungsprozess explizit kommentiert, was die meisten Agents standardmäßig nicht tun. Die Speicherung der Verifikationsebene erfordert Integration mit dem Test-Runner und dem Review-System.

Mein Orchestrierungssystem erfasst alle vier Ebenen durch verschiedene Mechanismen.³ Die Hook-Infrastruktur, die die Erfassung ermöglicht, umfasst 84 Hooks über 15 Event-Typen.⁵ Absicht: Der UserPromptSubmit-Hook protokolliert den ursprünglichen Prompt. Prozess: PostToolUse-Hooks protokollieren jeden Tool-Aufruf und jedes Ergebnis. Reasoning: Das Evidence Gate verlangt vom Agent, für jedes Qualitätskriterium eine spezifische Begründung anzuführen. Verifikation: Die jiro.state.json-Datei zeichnet Testausgaben und Reviewer-Urteile auf.

Die Hooks verfolgen auch, welche Skills der Agent in welcher Reihenfolge aufgerufen hat.¹¹ Ein Commit, der aus dem /review-Skill gefolgt vom /test-Skill resultiert, hat ein anderes Herkunftsprofil als ein Commit aus einer einzelnen unstrukturierten Session. Die Skill-Sequenz offenbart das Workflow-Muster: Review vor Testing oder Testing vor Review? Die Reihenfolge ist wichtig für das Verständnis der Qualitätssicherungsabdeckung. Die Daten existieren über mehrere Zustandsdateien verteilt. Das Problem ist, dass nichts davon an den Git-Commit angehängt wird.

LSP als Herkunftsbrücke

Claude Codes neue LSP-Integration (Language Server Protocol) verändert die Qualität der Session-Herkunftsdaten.⁴

Vor LSP navigierte Claude Code durch Codebasen mittels grep und Dateilesungen. Wenn der Agent die Definition einer Funktion finden musste, suchte er den Funktionsnamen in allen Dateien. Die Suche lieferte unscharfe Ergebnisse: mehrere Treffer, Teiltreffer, Testdateien mit dem Funktionsnamen in Kommentaren. Der Agent wählte den wahrscheinlichsten Treffer. Das Session-Transkript verzeichnete: „Suche nach authenticate_user, gefunden in auth.py, test_auth.py und middleware.py.” Die Herkunftsdaten enthalten die Suche, die Mehrdeutigkeit und die beste Vermutung des Agents.

Mit LSP ruft der Agent goToDefinition auf und erhält die exakte Datei und Zeilennummer in ~50 Millisekunden.⁴ Das Session-Transkript verzeichnet: „authenticate_user definiert in auth.py:47.” Die Herkunftsdaten sind präzise, eindeutig und maschinell verifizierbar. Ein Reviewer, der die Session liest, kann darauf vertrauen, dass der Agent die richtige Definition gefunden hat, nicht eine ähnlich benannte Funktion in einem anderen Modul.

Die Verbesserung summiert sich über die Session. Ein Agent, der 200 Dateien mittels grep liest, generiert Session-Daten voller „Suche nach X, potenzielle Treffer A, B, C gefunden, A ausgewählt.” Ein Agent, der 200 Dateien mittels LSP liest, generiert Session-Daten, die sagen „X definiert in Datei:Zeile, Referenzen in Datei:Zeile, Datei:Zeile, Datei:Zeile.” Die LSP-gestützte Session ist eine präzise Karte des Code-Verständnisses des Agents. Die grep-gestützte Session ist eine unscharfe Annäherung.

LSP fügt sechs Fähigkeiten hinzu, die die Herkunftsqualität verbessern:

Die Herkunftsimplikation: Session-Transkripte von LSP-fähigen Agents sind als Design-Dokumente wertvoller, weil jeder Code-Navigationsschritt verifizierbar ist. Ein Reviewer kann bestätigen, dass das Verständnis des Agents von der Codebasis korrekt war, nicht nur plausibel.

Das code-review-graph-Projekt treibt das strukturelle Verständnis weiter: ein persistenter Code-Graph, der über Sessions hinweg bestehen bleibt und die Token-Kosten des Wiederverständnisses der Codebasis bei jedem Aufruf reduziert.¹³ Wo LSP strukturelle Abfragen innerhalb einer Session bereitstellt, bietet ein persistenter Graph strukturelles Gedächtnis über Sessions hinweg. Für die Herkunft bedeutet dies, dass zukünftige Agents nicht nur das Session-Transkript, sondern auch das strukturelle Verständnis, das die Entscheidungen hervorbrachte, weitertragen werden. Der Graph wird zu einer weiteren Ebene der Herkunftsdaten: nicht nur „der Agent hat authenticate_user in auth.py:47 gefunden”, sondern „der Code-Graph des Agents enthielt bereits die Aufrufhierarchie, sodass er die Navigation übersprang und direkt zur Implementierung ging.” Das Vorwissen des Agents beeinflusst seine Entscheidungen, und dieses Vorwissen gehört in die Herkunftskette.

Wie Session-Metadaten aussehen

Ein reales Beispiel aus meinem Orchestrierungssystem. Story: „Rate Limiting zum Authentifizierungs-Endpunkt hinzufügen.”

Absichtsebene (vom UserPromptSubmit-Hook):

Prompt: "Implement rate limiting on POST /auth/login.
  Use sliding window, 5 attempts per minute per IP.
  Return 429 with Retry-After header."

Prozessebene (von PostToolUse-Hooks):

Files read: 14 (auth/, middleware/, tests/)
Files written: 3 (rate_limiter.py, auth.py, test_rate_limit.py)
Bash commands: 7 (pytest x3, pip install x1, curl x3)
Duration: 23 minutes
Token usage: 87K input, 24K output

Reasoning-Ebene (vom Evidence Gate):

Pattern: Sliding window (token bucket rejected
  because per-IP granularity requires separate
  counters, sliding window handles this natively)
Edge cases: IPv6 normalization, proxy headers
  (X-Forwarded-For validated against trusted proxy list)

Verifikationsebene (von jiro.state.json):

Tests: 12 passed, 0 failed, 0 skipped
Reviewers: correctness (approve), security (approve),
  conventions (approve with note: add docstring to
  rate_limiter.py:RateLimiter class)
Evidence gate: 6/6 criteria met

Die Commit-Nachricht für dieselbe Änderung: „feat: add rate limiting to auth endpoint.” Vierzehn Wörter. Die Session-Metadaten enthalten 2.300 Wörter strukturierter Herkunftsdokumentation. Die Kluft zwischen Commit-Nachricht und Session-Kontext beträgt zwei Größenordnungen.

Die Kosten der Herkunft

Session-Herkunft ist nicht kostenlos. Drei Kostenfaktoren beschränken die Einführung.

Speicher. Eine 90-minütige Agent-Session generiert 500 KB – 2 MB rohes Transkript. Bei 10 Commits pro Tag fügt das vollständige Transkript täglich 5–20 MB zum Git-Repository hinzu. Git Notes speichern die Daten außerhalb der Haupthistorie (sie beeinflussen die git clone-Größe standardmäßig nicht), aber der Audit-Trail in refs/notes/memento-full-audit akkumuliert. Mementos Markdown-Konvertierung reduziert die Rohgröße um etwa 60 %.²

Datenschutz. Session-Transkripte enthalten alles, was der Agent gesehen hat: Dateiinhalte, Umgebungsvariablen, API-Antworten, Fehlermeldungen mit Stack-Traces. Ein an ein öffentliches Repository angehängtes Transkript legt interne Implementierungsdetails offen. Memento behandelt Transkripte als nicht vertrauenswürdige Daten und weist das Zusammenfassungsmodell an, eingebettete Anweisungen zu ignorieren, aber das Rohtranskript im vollständigen Audit-Trail erfordert Zugriffskontrolle.²

Signal-Rausch-Verhältnis. Eine 90-minütige Session, in der der Agent 200 Dateien liest, um 12 zu ändern, enthält 188 Dateien irrelevanter Prozessdaten. Die Herausforderung besteht darin, Navigation (Rauschen) von Entscheidungspunkten (Signal) zu unterscheiden. Das Vier-Ebenen-Modell hilft: Absicht und Reasoning sind signalstark, Prozess ist gemischt, Verifikation ist signalstark. Ein Herkunftssystem, das Absicht und Reasoning standardmäßig speichert und Prozess bei Bedarf, reduziert das Rauschen, ohne den kritischen Entscheidungskontext zu verlieren.

Was Sie heute umsetzen können

Vier minimale Herkunftspraktiken, die keine neuen Tools erfordern:

1. Strukturierte Commit-Nachrichten. Ersetzen Sie „refactor auth module” durch ein strukturiertes Format:

feat: add rate limiting to auth endpoint

Task: sliding window rate limiter, 5/min per IP
Alternatives: token bucket (rejected: per-IP overhead)
Evidence: 12 tests pass, 3 reviewers approve
Session: 23 min, 87K tokens, 14 files read

Das Format ist eine manuelle Version der vier Herkunftsebenen. Die Nachricht beantwortet Absicht (Task), Reasoning (Alternativen) und Verifikation (Belege) in vier Zeilen. Kein Tooling erforderlich.

2. Session-Transkripte neben Commits speichern. Exportieren Sie nach einer Agent-Session das Transkript in eine Datei im Repository (z. B. .sessions/2026-03-02-auth-rate-limit.md). Fügen Sie die Datei zur .gitignore für öffentliche Repos hinzu oder committen Sie sie für interne Repos. Das Transkript steht für Reviews zur Verfügung, ohne Git-Notes-Infrastruktur.

3. Agent-verfasste Commits taggen. Verwenden Sie einen Git-Trailer, um Commits zu kennzeichnen, die ein Agent erstellt hat:

Agent: Claude Code (Opus)
Session-Duration: 23m
Files-Read: 14
Files-Written: 3

Der Trailer erzeugt einen maschinenlesbaren Nachweis der Agent-Beteiligung. git log --grep="Agent: Claude Code" listet alle Agent-verfassten Commits auf. Die Metadaten ermöglichen es zukünftigem Tooling, Herkunftsketten zu rekonstruieren, ohne nachträgliche Annotation.

4. Evidence Gates für Agent-Commits verlangen. Bevor ein Agent committet, verlangen Sie von ihm die Beantwortung von sechs Fragen: Welchem Muster folgt der Code? Welche einfacheren Alternativen gibt es? Welche Grenzfälle werden behandelt? Bestehen die Tests? Welche Dateien haben Sie auf Regressionen geprüft? Löst die Änderung das tatsächliche Problem?¹⁰ Die Antworten bilden die Reasoning- und Verifikationsebenen. Ohne das Gate meldet der Agent „fertig” und die Session enthält nur Prozessdaten. Mit dem Gate generiert jeder Commit strukturierte Herkunftsdokumentation als Nebeneffekt der Qualitätssicherung.

Die Evidence-Gate-Praxis verbindet sich mit dem breiteren Herkunftsargument. Ein Agent, der seine Entscheidungen vor dem Committen begründen muss, generiert hochwertigere Session-Metadaten als ein Agent, der unkontrolliert läuft. Das Gate transformiert Herkunft von einem passiven Nebenprodukt (aufzeichnen, was passiert ist) in ein aktives Qualitätssignal (den Agent zur Erklärung auffordern, was passiert ist und warum).

Kernaussagen

Für Engineering Manager: Jeder Agent-verfasste Commit mit einer einzeiligen Nachricht verwirft das Design-Dokument. Das Session-Transkript enthält die Begründung. Entscheiden Sie, ob diese Begründung für die Code-Review-, Onboarding- und Incident-Response-Workflows Ihres Teams wertvoll ist. Wenn ja, implementieren Sie mindestens strukturierte Commit-Nachrichten.

Für Entwickler: Wenn Sie Agent-verfassten Code übernehmen, sagt Ihnen die Commit-Nachricht, was sich geändert hat. Das Session-Transkript (falls bewahrt) sagt Ihnen, warum. Setzen Sie sich für Session-Herkunft im Agent-Workflow Ihres Teams ein. Das Memento-Projekt bietet einen Git-nativen Ansatz. Strukturierte Commit-Nachrichten bieten einen Ausgangspunkt ohne Infrastruktur.

Für Tool-Entwickler: LSP-Integration macht Session-Transkripte wertvoller, indem sie unscharfe grep-basierte Navigation durch präzise, verifizierbare Code-Referenzen ersetzt. Jede Verbesserung des Code-Verständnisses von Agents verbessert die Qualität der Herkunftsdaten, die Sessions generieren. Entwickeln Sie Exportformate, die die vier Herkunftsebenen bewahren.

FAQ

Was ist Session-Herkunft? Session-Herkunft ist der Nachweis des Reasoning-Prozesses eines KI-Agents während einer Coding-Session: die ursprüngliche Aufgabe, gelesene Dateien, evaluierte Alternativen, getroffene Entscheidungen und produzierte Belege. Das Session-Transkript erfasst das „Warum”, das Commit-Nachrichten und Diffs nicht liefern können.

Was ist Memento? Memento ist eine Open-Source-Git-Erweiterung, die KI-Coding-Session-Transkripte erfasst und als Git Notes an Commits anhängt. Das Tool unterstützt Codex und Claude Code, generiert Markdown-Zusammenfassungen und bietet eine GitHub Action für PR-Integration.²

Wie verbessert LSP Agent-Sessions? Das Language Server Protocol gibt Agents strukturelles Code-Verständnis: exakte Definitionen, typisierte Referenzen, Aufrufhierarchien und Echtzeit-Diagnose. Session-Transkripte von LSP-fähigen Agents enthalten präzise, verifizierbare Code-Navigationsdaten anstelle unscharfer grep-Ergebnisse.⁴

Sollten Session-Transkripte in Git committet werden? Die Antwort hängt von den Datenschutzanforderungen des Repositorys ab. Für interne Repositories bewahrt das Committen von Transkripten die Herkunft. Für öffentliche Repositories sind Git Notes (die beim Klonen standardmäßig nicht übertragen werden) oder separate Speicherung mit Commit-Referenzen sicherere Ansätze.²

Wie viel Speicher erfordert Session-Herkunft? Eine typische 30-minütige Agent-Session generiert 200 KB – 800 KB rohes Transkript. Git Notes speichern die Daten außerhalb der Hauptobjektdatenbank und halten die git clone-Größen standardmäßig unverändert. Mementos Markdown-Konvertierung reduziert die Rohgröße um etwa 60 %. Für Teams, die 10–20 Agent-Sessions pro Tag durchführen, sind täglich 2–10 MB an Herkunftsdaten zu erwarten — vergleichbar mit einem Screenshot in mittlerer Auflösung pro Session.²

Wie ist das Verhältnis zwischen Agent-Observability und Session-Herkunft? Agent-Observability überwacht, was Agents in Echtzeit tun: Ressourcenverbrauch, Richtlinieneinhaltung, Laufzeitverhalten.⁷ Session-Herkunft zeichnet auf, was Agents entschieden haben und warum, im Nachhinein. Observability beantwortet „Verhält sich der Agent gerade korrekt?” Herkunft beantwortet „Warum hat der Agent letzten Dienstag diese Entscheidung getroffen?” Die beiden Systeme ergänzen sich: Observability erkennt Probleme live, Herkunft erklärt sie nachträglich.

Quellen