Was ist AI Agent State? Leitfaden 2026: Zustandsverwaltung, JSON State, Memory, Workflow und Aufgabenausführung

Was Agent State ist — gegenüber Chatverlauf und Session

Ein Satz reicht: Agent State ist der strukturierte Schnappschuss, der einen Run pausierbar, fortsetzbar und wiederholbar macht. Er beantwortet vier Fragen: Was ist das Ziel, auf welchem Hop stehen wir, welche Arbeitsergebnisse sind schon committed, wer blockiert den nächsten Schritt (Tool, Mensch oder maxSteps). Das Modell wählt die Aktion aus der aktuellen Beobachtung; die Runtime führt aus und schreibt die Position zurück. Ohne prüfbare Position kann die Schleife nur den ganzen Chat wieder einfügen — das ist Chat, keine Zustandsverwaltung.

Der Chatverlauf ist die Nachrichtenliste, die das Modell sieht: user / assistant / tool. Eine Session (OpenAI Conversations, previous_response_id, der alte Assistants-Thread) ist der Griff, den der Anbieter sieht: welche modellseitigen Einträge die nächste Anfrage mitnehmen soll. State ist die Position, die Ihre Runtime sieht: wie weit der Abgleich ist, der Betrag zur Bestätigung, der aktuelle Graphknoten, die Checkpoint-ID. Sie dürfen koexistieren, sich aber nicht verkleiden. messages[] als einzige Wahrheit führt bei Retries zu Doppelabbuchung oder Doppelmail. Eine Conversation-ID als Geschäftszustand, und ein Anbieterwechsel lässt die Position fallen. Nach Assistants → Responses hat sich das Sitzungsprimitiv geändert — binden Sie Geschäftsschnappschüsse noch weniger an Plattformobjekte. Siehe Assistants → Responses Migration.

Die meisten 2026er Vorfälle vermischen Schichten: Tool-Arguments im State, der ganze State-Blob im nächsten Prompt, Langzeitgedächtnis als Checkpoint abgespielt. Getrennt hat das Debuggen einen Griff: das Modell hat eine Beobachtung falsch gelesen; Reducer / Schema hat eine schlechte Position geschrieben; Memory hat die falsche Präferenz geholt. Die Karte:

JSON State: der Checkpoint ist der Vertrag

State als JSON schreiben Sie, um zu validieren, zu diffen und wiederzugeben. Orchestratoren der LangGraph-Familie speichern jeden Super-Step als Checkpoint, fädeln sie mit thread_id und zeigen mit checkpoint_id auf ein Bild. Produktion nutzt Postgres- oder SQLite-Saver, keinen In-Process-MemorySaver. Namen ändern sich; die Form nicht: ein parsebares Objekt mit schemaVersion, Status-Enum, step, working, memoryRefs. Der Serializer darf JsonPlus oder erweitertes JSON sein, aber die Schicht, die Sie loggen, exponieren und debuggen, sollte ein schlichtes JSON-Objekt sein — sonst sind Schema-Check und Browser-Diff nutzlos.

Der Schnappschuss unten ist nur Position. Kein messages[], kein rohes Downstream-HTTP. Geschäftsfelder liegen in working; ein Tool-Aufruf behält name und callId; Memory sind Zeiger. Projizieren Sie das Transkript bei Bedarf aus dem Checkpoint in den Modellkontext — behandeln Sie Kontext nicht umgekehrt als State.

{
  "schemaVersion": "1.0",
  "runId": "run_7c2a",
  "threadId": "thr_invoice_42",
  "goal": "Reconcile January 2026 paid invoices",
  "status": "awaiting_tool",
  "step": 3,
  "maxSteps": 12,
  "node": "call_tools",
  "plan": ["searchInvoices", "sumTotals", "askConfirm"],
  "working": {
    "invoiceCount": 2,
    "currency": "USD"
  },
  "pendingTool": {
    "name": "searchInvoices",
    "callId": "call_8f3a"
  },
  "memoryRefs": ["mem_user_prefs", "mem_last_reconcile"],
  "checkpointId": "ckpt_3"
}

Beide Stile funktionieren: jedes Mal ein Vollsnapshot oder ein JSON-Patch / Reducer. Vollsnapshots diffen und spielen sauber; Patches sparen Speicher und müssen selbst validierbar sein. In beiden Fällen: ein Draft-2020-12-Schema festlegen. status als Enum (running / awaiting_tool / awaiting_human / succeeded / failed / cancelled), step als Ganzzahl, working-Schlüssel aus dem Geschäft, additionalProperties false, damit Tool-Müll nicht einsickert. Die Antwort an Nutzer oder Downstream ist eine eigene Structured-Output-Datei — nicht mit dem Checkpoint teilen. Siehe AI Structured Output.

Memory: Erinnerung ist nicht die Maschinenposition

Memory beantwortet „was über Zeit noch bekannt sein soll“. State beantwortet „wo dieses Bild stehen blieb“. Drei Schichten sind 2026 üblich: Arbeitsgedächtnis (Nachrichten dieser Runde und jüngste tool_result), Kurzzeit- / Thread-Gedächtnis (Checkpoint-Kette auf einer thread_id — LangGraphs short-term memory), Langzeitgedächtnis (Store über Threads: Präferenzen, Fakten, Verfahren). Alles in ein Riesen-JSON zu stopfen wirkt billig; Wiedergabe und Vergessenspolitik zerbrechen gemeinsam.

Nach Inhalt: episodisch (was in diesem Abgleich geschah), semantisch (der Nutzer will USD-Summen), prozedural (wiederverwendbare Schritte wie „Rechnungen suchen, dann summieren“). Nur vom aktuellen Run zitierte Erinnerungen gehören in State.memoryRefs. Ein Millionen-Token-Fenster setzt diese Zeiger nicht außer Dienst — ein Fenster ist Budget, keine Wahrheit. Siehe 1M-Token-Kontext.

Langfristige Einträge brauchen einen festen Umschlag: id, kind, scope, text oder data, source, updatedAt. source sagt, ob der Nutzer es nannte, ein Tool es lieferte oder das Modell es zusammenfasste — die letzten beiden müssen widerrufbar sein. Nach einem Treffer nur die id in den State schreiben und den Körper bei Bedarf in den Kontext injizieren. Beispiel:

{
  "id": "mem_user_prefs",
  "kind": "semantic",
  "scope": "user",
  "userId": "u_1042",
  "text": "Prefers USD totals and weekday email summaries",
  "source": "explicit_setting",
  "updatedAt": "2026-09-01T09:00:00Z"
}

Workflow vs. Agent: wer Kanten zieht, wer State schreibt

In einem klassischen Workflow (n8n, Temporal, eigene Zustandsmaschine) verdrahten Menschen den nächsten Hop. State sind Workflow-Variablen: Bestell-ID, Retry-Zähler, ob Kompensation schon lief. Beim Agenten wählt das Modell den nächsten Hop aus der aktuellen JSON-Beobachtung; State hält außerdem plan, node, pendingTool. Produktion 2026 ist selten reinrassig: ein Graph mit Agent-Knoten — Kanten sind Workflow, innen ist eine Tool-Schleife. Ein JSON-State-Objekt bedient zwei Leser: der Orchestrator liest status / node; das Modell sieht nur die projizierte Beobachtungsmenge.

MCP besitzt diese Schicht nicht. Remote-MCP um 2026-07-28 ist zustandsloses JSON-RPC: jede Anfrage trägt ihre Metadaten; der Server merkt sich Ihre Geschäftsposition nicht. Das ist die richtige Transportwahl, nicht „Agenten dürfen keinen Zustand haben“. Anwendungszustand lebt weiter in Ihrem Checkpoint. Details: Stateless MCP. Tool-Argument-Schema und State-Schema müssen getrennte Dateien sein — Eingaben eines Hops vs. Maschinenposition. Siehe MCP und JSON Schema.

Seitliche Delegation läuft über A2A: das Gegenüber ist ein undurchsichtiger Agent; die Aufgabe hat eigenen Lebenszyklus (submitted / working / completed / failed) und Artifacts. Das ist eine andere Zustandsmaschine — nicht ins lokale Checkpoint mischen. Der Orchestrator heftet sie mit parentRunId. Vergleich: A2A vs MCP. Ein Modell-Gateway (z. B. lokales /v1) ändert nur die Inferenzversorgung, nicht die State-Form. Stabile Verträge machen Fallback sinnvoll.

Aufgabenausführung: Run, Step, Idempotenz, Retries

Die Ausführungsschicht macht aus dem Schnappschuss eine wiederherstellbare Maschine. Jedes Nutzerziel öffnet eine runId; jeder Tool-Hop ist ein Step; jeder Downstream-Schreibvorgang (Abbuchung, Mail, Ticket) trägt eine idempotencyKey. Nach einem Absturz vom letzten Checkpoint fortsetzen und Nebenwirkungen erfolgreicher Steps nicht wiederholen. Pending Writes (manche Knoten ok, manche fehlgeschlagen) gehören in den Schnappschuss — nicht ins Raten des Betriebs.

Menschliche Freigabe ist ein Status erster Klasse, kein Sonderzweig: status=awaiting_human, das zu bestätigende Objekt in working, Fortsetzen nur mit legalen Übergängen (genehmigen → weiter, ablehnen → fehlschlagen oder Plan ändern). Nicht „das Modell nochmal fragen“ statt einer Transition — das Modell sieht einen Klick nicht, den Sie nie in die Beobachtung geschrieben haben. maxSteps, Nutzerabbruch und Schema-Fehler sind ebenfalls Stopps: in status schreiben, nicht nur ins Log.

Wählen Sie einen Besitzer der Historie zwischen Anbieter-Session und Ihrem Ausführungsprotokoll. Responses kann Reasoning-Einträge über Conversation oder previous_response_id fortsetzen; das Band ist modellseitig, nicht die Abgleichsposition. Empfehlung: Sie besitzen Checkpoint und Aufgabenumschlag; die Plattform besitzt nur die Reasoning-Einträge, die sie unverändert zurückverlangt (manche Anbieter fordern reasoning_content wörtlich, sobald tool_calls da sind). Umschlag:

{
  "taskId": "task_a2a_91",
  "parentRunId": "run_7c2a",
  "kind": "delegate",
  "status": "working",
  "idempotencyKey": "inv-jan-2026-reconcile",
  "steps": [
    { "id": "s1", "name": "searchInvoices", "ok": true },
    { "id": "s2", "name": "sumTotals", "ok": null }
  ],
  "artifacts": []
}

Bei Delegation an ein Kind-Agent die entfernte taskId in lokalem working oder steps ablegen — deren Artifacts nicht in dasselbe Checkpoint flachklopfen. Zwischenprodukte sind eine neue JSON-Familie; halten Sie sie aus finalem Structured Output und MCP-Arguments heraus. Stempeln Sie jetzt correlationId / runId auf jedes Tool-Log. DevDay-artige Observability join’t auf demselben Schlüssel. Siehe OpenAI DevDay 2026 Prognosen.

Validierung vor Ort und JSONVue

Bevor ein Checkpoint landet: parse → Schema → Geschäftsregeln. Ein kluges Modell ersetzt diese drei Schritte nicht. Schlechter State ist schlimmer als schlechte Arguments: Arguments sind ein Hop; State ist die Wahrheit des Runs.

1. Checkpoint JSON.parse; bei Fehler Schreiben verweigern und die vorherige ckpt_id behalten.
2. status / step / working gegen das State-Schema (Draft 2020-12) prüfen; path und keyword ausgeben.
3. Geschäftstor: monotoner step, stabiler Idempotenzschlüssel, jeder memoryRef existiert, illegale Statusübergänge scheitern geschlossen.

Drei Blobs nebeneinander: ckpt_n, ckpt_n+1 und die Beobachtung, die Sie dem Modell projiziert haben. Formsprünge sitzen fast immer im Reducer. Im Browser: JSON-Formatierer für den Snapshot-Baum; JSON-Schema-Prüfung für State- und Memory-Umschläge; JSON Diff für benachbarte Checkpoints. Teilen Sie Fixtures valid / fehlender step / illegaler status in CI und manuellem Debug.

Weiterlesen: Was ist ein AI Agent, Structured Output, Stateless MCP, A2A vs MCP, 1M-Token-Kontext.

FAQ

Fazit und nächste Schritte

Agent State 2026 in einem Satz: Die Runtime merkt sich die Position in einem validierbaren JSON-Schnappschuss, Memory liefert nur zitierte Erinnerung, ein Workflow zieht Kanten oder übergibt sie dem Modell, und Ausführung macht aus dem Schnappschuss mit run / step / Idempotenzschlüssel eine wiederherstellbare Maschine. Chatverlauf und Anbietersessions ersetzen diesen Schnappschuss nicht.

Als Nächstes: State-Schema und einen gültigen Checkpoint schreiben; benachbarte Snapshots in JSONVue diffen; Fixtures für fehlendes Feld und illegalen Status ergänzen. Schleifendefinition im Agent-Artikel; finale Antwortform in Structured Output; Protokolle in MCP / A2A.