Am 27. Februar 2026 kündigten OpenAI und Amazon eine Stateful Runtime Environment für Frontier-Agenten an — persistente Dateisysteme und Speicher, die über Tool-Aufrufe innerhalb von Agentensitzungen hinweg bestehen bleiben. Das ist eine bedeutende Fähigkeit. Agenten, die zwischen Runs alles vergessen, sind grundlegend eingeschränkt.
Aber persistenter Speicher allein reicht für Enterprise-AI nicht aus. Die Frage ist nicht ob Agenten sich erinnern sollten — es ist wer kontrolliert, was sie sich merken, und wer es sehen kann.
Versprechen und Gefahr von persistentem Agentenspeicher
Persistenter Speicher macht Agenten dramatisch leistungsfähiger. Ein Agent, der sich an den bevorzugten Kommunikationsstil Ihres Teams, Ihre Genehmigungsschwellen, Ihre Kundensegmente erinnert — dieser Agent wird mit jedem Run besser.
Die Gefahr ist ebenso klar. Ein Agent mit unkontrolliertem persistentem Speicher kann:
- Veraltete oder falsche Fakten ansammeln, die die Ausgabequalität über die Zeit verschlechtern
- Informationen zwischen Abteilungen durchsickern lassen, wenn der Speicher nicht eingegrenzt ist
- Compliance-Audits widerstehen, wenn es keine Aufzeichnung gibt, was wann und woher gelernt wurde
- Versteckte Abhängigkeiten schaffen, wenn nachgelagerte Workflows auf undurchsichtigem Agentenzustand basieren
Für regulierte Branchen — Gesundheitswesen, Finanzdienstleistungen, Behörden — ist undurchsichtiger persistenter Speicher nicht nur eine Governance-Lücke. Es ist ein Ausschlusskriterium.
13 von 14 zustandsbehafteten Fähigkeiten: Bereits in JieGou
Als wir Frontiers Stateful Runtime gegen JieGous bestehende Architektur bewertet haben, stellten wir fest, dass 13 von 14 zustandsbehafteten Fähigkeiten bereits abgedeckt waren:
| Fähigkeit | JieGou-Abdeckung |
|---|---|
| Strukturierter Ein-/Ausgabezustand | Recipe-I/O-Schemas mit Validierung |
| Schritt-zu-Schritt-Datenfluss | previousStepOutputs-Map im Workflow-Executor |
| Bedingte Verzweigung auf Zustand | ConditionStep mit Expression-Evaluation |
| Schleifenzustandsverwaltung | LoopContext mit Iterationsverfolgung |
| Paralleler Ausführungszustand | Promise.allSettled mit Fehlerkaskadierung |
| Genehmigungsgate-Zustand | ApprovalPauseError mit Checkpoint-Resume |
| Gemeinsamer Speicher (Multi-Agent) | sharedMemory-Map auf StepExecutionContext |
| Konvergenzschleifenzustand | ConvergenceLoop mit Eval-Feedback-Injection |
| Checkpoint/Resume | WorkflowCheckpointV2 mit Pro-Schritt-Tracking |
| Wissensabrufzustand | RAG-Kontext mit Auto-Context-Resolution |
| Brand-Voice-Zustand | Brand-Voice-Profile mit Abteilungs-Scoping |
| Glossarzustand | Glossar-Kontextinjektion pro Abteilung |
| Few-Shot-Lernzustand | Few-Shot-Beispielkuratierung aus der Run-Historie |
Die eine Lücke: workflow-übergreifender persistenter Agentenspeicher — Fakten, die zwischen separaten Workflow-Ausführungen bestehen bleiben.
Die 14. Fähigkeit: Agent Workspaces
Wir haben Agent Workspaces gebaut, um diese Lücke zu schließen — aber mit einer kritischen Designentscheidung: jedes Stück persistenter Zustand ist standardmäßig geregelt.
Ein Agent Workspace ist ein strukturierter Key-Value-Store, der auf einen Agenten innerhalb eines Accounts eingegrenzt ist. Jeder Eintrag verfolgt:
- Key: Ein beschreibender Bezeichner (z.B.
preferred_tone,primary_contact,approved_budget) - Value: Das gelernte Faktum (JSON-serialisierbar, max. 10 KB)
- Source: Wie der Eintrag erstellt wurde —
auto(LLM-extrahiert),user(manuell gesetzt) oderstep_output(aus einem Workflow-Schritt erfasst) - Run ID: Welcher Workflow-Run diesen Eintrag produziert hat
- Timestamp: Wann er zuletzt aktualisiert wurde
Diese Herkunftsmetadaten sind es, was geregelten Zustand von rohem persistentem Speicher unterscheidet.
Wie es funktioniert
-
Kontextinjektion: Wenn ein Recipe innerhalb eines Workflows ausgeführt wird, der einen zugehörigen Agent Workspace hat, werden die Workspace-Einträge als
<agent_workspace>-Abschnitt formatiert und in den Prompt-Kontext injiziert — neben Glossar, Few-Shot-Beispielen und RAG-Dokumenten. -
Automatische Erfassung: Nach Abschluss eines Workflow-Schritts verwendet ein optionaler Erfassungsschritt einen leichtgewichtigen LLM-Aufruf, um dauerhafte Fakten aus der Ausgabe zu extrahieren. Nur Fakten, die es wert sind, über zukünftige Runs hinweg zu bestehen, werden gespeichert — keine flüchtigen Details.
-
Manuelle Kuratierung: Benutzer können Workspace-Einträge über die API inspizieren, bearbeiten, hinzufügen und löschen. Das ist keine Blackbox — es ist ein geregelter Datenspeicher.
Beschränkungen durch Design
- Maximal 100 Einträge pro Workspace — verhindert unbegrenztes Speicherwachstum
- 10 KB pro Eintragswert — hält Einträge fokussiert und abrufbar
- Ca. 2.000 Token-Budget für Prompt-Injektion — Workspace-Kontext verdrängt nicht die eigentliche Aufgabe
- Abteilungs-Scoping — Workspaces erben dieselben Zugriffskontrollen wie der Rest von JieGou
Warum geregelter Zustand > roher persistenter Speicher
| Dimension | Geregelter Zustand (JieGou) | Roher persistenter Speicher (Frontier SRE) |
|---|---|---|
| Sichtbarkeit | Jeder Eintrag hat Herkunft (Quelle, Run-ID, Zeitstempel) | Zustand lebt innerhalb der Agent-Runtime |
| Auditierbarkeit | In Audit-Log integriert; Compliance-Teams können inspizieren | Runtime-Zustand ist der Governance-Schicht nicht zugänglich |
| Eingrenzung | Abteilungsbezogen mit RBAC-Durchsetzung | Sitzungsbezogen; workflow-übergreifender Scope unklar |
| Größenkontrolle | Harte Limits (100 Einträge, je 10 KB) | Dateisystem-Persistenz — keine inhärenten Limits |
| Veralterung | Zeitstempel + manuelle Kuratierung ermöglichen Faktenhygiene | Kein eingebauter Mechanismus für Faktenablauf |
| Compliance | API-Zugriff für automatisierte Compliance-Prüfungen | Erfordert individuelles Tooling zur Inspektion des Agentenzustands |
Der fundamentale Unterschied: Frontiers Stateful Runtime macht Agenten leistungsfähiger. JieGous geregelter Zustand macht Agenten leistungsfähiger und auditierbarer.
Vergleich mit Frontiers Stateful Runtime
Frontiers Stateful Runtime Environment ist beeindruckendes Engineering. Persistente Dateisysteme, tool-übergreifender Speicher und Integration mit Amazons Infrastruktur schaffen eine leistungsstarke Ausführungsumgebung für autonome Agenten.
Aber sie ist für Agentenfähigkeit konzipiert, nicht für Enterprise-Governance. Der Runtime-Zustand ist für die Nutzung durch den Agenten optimiert — nicht für Compliance-Teams zur Inspektion, nicht für Abteilungsgrenzen zur Durchsetzung, nicht für Audit-Trails zur Erfassung.
JieGou nähert sich persistentem Zustand aus der entgegengesetzten Richtung: Governance zuerst, Fähigkeit zweitens. Agent Workspaces sind weniger flexibel als ein volles Dateisystem — und das ist der Punkt. Die Beschränkungen (strukturierte Einträge, harte Limits, Herkunftsverfolgung) sind Features, keine Einschränkungen.
Für Teams, die experimentelle AI-Agenten bauen, ist Frontiers Ansatz überzeugend. Für Teams, die AI in regulierten Umgebungen bereitstellen, wo jedes Stück Agentenzustand erklärbar und auditierbar sein muss, ist geregelter Zustand der einzig gangbare Weg.
Erste Schritte mit Agent Workspaces
Agent Workspaces sind heute über die JieGou-API verfügbar:
- Workspace erstellen für jeden Agenten in Ihrem Account
- Mit Workflows verknüpfen — Workspace-Kontext wird automatisch während der Ausführung injiziert
- Auto-Capture aktivieren — das System dauerhafte Fakten aus Schrittausgaben extrahieren lassen
- Überprüfen und kuratieren — Einträge inspizieren, Werte bearbeiten, veraltete Fakten entfernen
Der Workspace integriert sich mit JieGous bestehendem Governance-Stack: Audit-Protokollierung, RBAC, Abteilungs-Scoping und Compliance-Export gelten alle für Workspace-Operationen.
Fazit: Governance ist der Differenzierer
Persistenter Speicher ist Grundvoraussetzung für leistungsfähige AI-Agenten. Jede Plattform wird ihn bald haben.
Der Differenzierer ist nicht ob Agenten sich erinnern können — sondern ob Sie sehen, kontrollieren und auditieren können, was sie sich merken. Für Enterprise-AI ist geregelter Zustand kein Nice-to-have. Es ist die Anforderung, die Produktionsbereitstellungen von Wissenschaftsexperimenten unterscheidet.
JieGous geregelte Zustandsarchitektur deckt 14/14 zustandsbehaftete Fähigkeiten ab — mit jeder Zustandsmutation sichtbar, auditierbar und eingegrenzt. Das ist die Grundlage, die Enterprise-AI braucht.
Erfahren Sie mehr über JieGous Governance-Architektur oder vergleichen Sie mit OpenAI Frontier.