Anthropic Managed Agents: Warum die Brain-Hands-Session-Architektur skaliert

Wer langläufige KI-Agenten in Produktion betreibt, kennt das Problem: Ein Container-Absturz reißt den gesamten Session-Kontext mit sich. Credentials liegen im selben Namensraum wie generierter, nicht vertrauenswürdiger Code. Und jedes Mal, wenn ein Modell besser wird, muss das Harness nachgezogen werden, weil es Annahmen über Modell-Schwächen kodiert hat, die längst nicht mehr gelten. Anthropic hat dieses Bündel an strukturellen Problemen mit dem neuen Service Managed Agents angegangen – einer gehosteten Runtime, die sich seit dem 8. April 2026 in der öffentlichen Beta befindet.

Der Engineering-Blog-Post "Scaling Managed Agents: Decoupling the brain from the hands" legt die Architektur offen. Das Kernprinzip ist nicht neu – es ist die gleiche Virtualisierungslogik, die Betriebssysteme vor Jahrzehnten auf Hardware angewendet haben. read() ist heute identisch, egal ob es auf einem Plattenpack der 1970er oder einer modernen NVMe läuft. Managed Agents überträgt diese Abstraktionslogik auf die drei Kernkomponenten eines Agenten: Brain, Hands und Session.

Das Pet-Problem: Warum der Monolith für Agenten nicht funktioniert

Anthropics initiale Implementierung von Managed Agents war ein klassischer Monolith: Session-Log, Harness und Sandbox liefen im selben Container. Die Vorteile waren real – File-Edits via direkten Syscalls, keine Service-Boundaries, die man designen musste. Aber der Container wurde zum Pet.

In der Pets-vs-Cattle-Analogie aus der Cloud-Infrastruktur ist ein Pet ein benanntes Einzelstück, das du nicht verlieren kannst. Ein Container, der Session-State, Ausführungsumgebung und Steuerungslogik gleichzeitig hält, ist genau das: ein Pet. Fällt er aus, ist die Session weg. Hängt er sich auf, muss jemand manuell eingreifen. Das einzige Debugging-Fenster war der WebSocket-Event-Stream – der aber nicht unterscheiden konnte, ob ein Bug im Harness steckte, ein Paket gedroppt wurde oder der Container offline war. Shell-Zugriff zur Diagnose war wegen der gleichzeitigen Präsenz von Nutzerdaten im Container ein Sicherheitsproblem.

Das zweite strukturelle Problem: Das Harness nahm an, dass alles, womit Claude arbeitet, im selben Container liegt. Sobald Enterprise-Kunden Claude mit ihrem eigenen Virtual Private Cloud verbinden wollten, mussten sie entweder ihr Netzwerk mit Anthropics peeren – oder das Harness in ihrer eigenen Umgebung betreiben. Eine im Code hartcodierte Annahme wurde zur Integrations-Barriere.

Brain, Hands, Session: Die drei entkoppelten Interfaces

Die Lösung ist eine konsequente Separierung in drei unabhängig austauschbare Komponenten, die jeweils über ein minimales Interface kommunizieren:

• Brain (Claude-LLM + Harness-Steuerungsschleife): Trifft Entscheidungen, ruft Tools auf, schreibt Events in die Session.
• Hands (Sandboxes + Tools): Führen Code aus, interagieren mit Dateisystemen und externen Services. Werden über execute(name, input) → string angesprochen.
• Session (append-only Event-Log): Dauerhafter, außerhalb des Harness liegender Zustandsspeicher. Wird über emitEvent(id, event) beschrieben und über getEvents() ausgelesen.

Die entscheidende Konsequenz: Jede Komponente kann unabhängig ausfallen oder ersetzt werden. Stirbt ein Container, fängt das Harness den Fehler als Tool-Call-Error ab und gibt ihn an Claude weiter. Claude kann entscheiden, ob es retried – ein neuer Container wird dann mit provision({resources}) initialisiert. Stirbt das Harness selbst, ist das kein Problem, weil die Session außerhalb des Harness lebt. Ein neues Harness bootet mit wake(sessionId), lädt den Event-Log via getSession(id) und setzt ab dem letzten Event fort. Container und Harness sind jetzt Cattle – austauschbar, ohne Zustandsverlust.

Credential-Isolation: Das strukturelle Sicherheitsargument

Im gekoppelten Design lag von Claude generierter, nicht vertrauenswürdiger Code im selben Container wie die Credentials. Eine erfolgreiche Prompt-Injection musste Claude nur dazu bringen, seine eigene Umgebung zu lesen – danach waren Tokens für beliebige neue Sessions verfügbar. Narrow Scoping ist ein naheliegender Mitigationsansatz, aber er kodiert wieder eine Annahme darüber, was Claude mit einem eingeschränkten Token nicht tun kann. Diese Annahme wird mit jedem Modell-Release fragwürdiger.

Managed Agents adressiert das strukturell: Tokens sind von der Sandbox physisch getrennt. Für Git-Repositories wird der Access-Token beim Sandbox-Initialisierungsprozess verwendet, um das Repo zu klonen und in den lokalen Git-Remote einzubauen. Code innerhalb der Sandbox kann danach git push und pull ausführen, ohne dass der Agent je den Token selbst zu Gesicht bekommt. Für Custom-Tools mit OAuth werden Tokens in einem Vault außerhalb der Sandbox gehalten. Claude ruft MCP-Tools über einen dedizierten Proxy auf – der Proxy kennt einen Session-assoziierten Token, holt die echten Credentials aus dem Vault und stellt den externen Call. Das Harness selbst hat zu keinem Zeitpunkt Zugriff auf Credentials.

Dieser Ansatz macht die Sicherheitsarchitektur unabhängig von Claude-Fähigkeiten: Selbst wenn Claude in einer zukünftigen Version erheblich smarter ist, kann es keine Credentials exfiltrieren, auf die es strukturell keinen Zugriff hat.

Session als externes Context-Objekt: Jenseits von Context-Anxiety

Langläufige Tasks übersteigen regelmäßig das Kontext-Fenster eines LLMs. Die klassischen Strategien – Kompaktierung, Trimming, Summarization – sind alle irreversibel. Es ist schwer vorherzusagen, welche Tokens in zukünftigen Turns gebraucht werden. Wird eine Nachricht kompaktiert und nicht extern gespeichert, ist sie weg.

Anthropic hatte schon in früheren Harness-Designs ein Beispiel für das Staleness-Problem dokumentiert: Claude Sonnet 4.5 beendete Tasks vorzeitig, wenn es sein Kontext-Limit nahte – "Context Anxiety" nannten sie das Phänomen. Das Harness bekam einen Context-Reset eingebaut. Als dasselbe Harness mit Claude Opus 4.6 lief, war das Verhalten verschwunden. Der Reset war toter Code geworden – eine Annahme über Modell-Schwächen, die das Modell nicht mehr hatte.

Die Session in Managed Agents löst dieses Problem anders als bisherige Ansätze: Der Event-Log lebt dauerhaft außerhalb des Kontext-Fensters und wird über getEvents() mit positionalen Slices abgefragt. Das Harness kann flexibel entscheiden, welche Slice es in Claudes Kontext-Fenster lädt – an der letzten gelesenen Position fortsetzen, ein paar Events vor einem kritischen Moment zurückspulen, Kontext vor einer bestimmten Aktion erneut lesen. Transformationen der Events vor der Übergabe an Claude sind möglich und können für hohe Prompt-Cache-Hit-Rates optimiert werden. Die Trennung von dauerhafter Kontextspeicherung und Kontextpräsentation im LLM-Fenster ist architektonisch sauber.

So What? Der ROI für Teams, die Agenten in Produktion betreiben

Die Architekturfrage ist keine akademische. Teams, die heute langläufige Agenten betreiben, stecken Infrastruktur-Engineering-Zeit in genau die Probleme, die Managed Agents abstrahiert: Session-Persistenz, Harness-Recovery, Credential-Handling, Sandbox-Isolation. Der Service übernimmt diesen Stack – inklusive der Designentscheidungen, die bei einem Monolith zu Produktionsproblemen führen.

Für Teams, die Claude-basierte Agenten auf Enterprise-Infrastruktur deployen wollen, ist die VPC-Integration besonders relevant: Da das Harness die Sandbox nur noch über ein Interface anspricht und nicht mehr im selben Container wie der Code läuft, ist der Anschluss an Kunden-eigene Ausführungsumgebungen kein Netzwerk-Peering-Problem mehr, sondern ein Interface-Problem. Das ist der Unterschied zwischen Monaten und Tagen an Integrationsaufwand.

Aus EU AI Act-Perspektive ist die strukturelle Credential-Isolation relevant für Teams, die Managed Agents in Hochrisiko-Kontexten einsetzen. Ab August 2026 greift der Hauptteil des AI Acts, der unter anderem Anforderungen an technische Robustheit und Sicherheit von Hochrisiko-KI-Systemen kodifiziert. Eine Architektur, bei der Credentials strukturell unerreichbar für generierte Code-Ausführung sind, liefert hier ein gut dokumentierbares Sicherheitsargument. Strafen bei Verstößen gegen Hochrisiko-Anforderungen können bis zu 15 Millionen Euro oder 3 Prozent des Jahresumsatzes betragen (siehe EU AI Act Art. 99). Laut aktuellen Analysen werden autonome KI-Agenten bis Ende 2026 rund 70 Prozent der standardisierten Geschäftsabläufe in der IT-Infrastruktur beeinflussen.

Fazit: Wann Managed Agents die richtige Wahl ist

Managed Agents ist kein Framework für alle Agenten-Use-Cases. Für einfache, kurzläufige Tasks mit stabilen Kontext-Fenster-Anforderungen bleibt ein direkter API-Call mit Tool-Use die unkompliziertere Wahl. Der Service entfaltet seinen Mehrwert, wenn drei Bedingungen zusammenkommen: Die Task läuft lange genug, um das Kontext-Fenster zu überschreiten. Der Agent führt Code aus, der nicht im selben Namensraum wie Credentials liegen darf. Und das Harness soll unabhängig von Modell-Updates gewartet werden können, ohne jedes Mal Annahmen über Modell-Schwächen zu überprüfen.

Für Teams, die heute bereits Agenten-Infrastruktur selbst bauen, lohnt es sich, die Architektur gegen das Brain-Hands-Session-Muster zu spiegeln. Nicht als Anleitung zur Migration auf Managed Agents – sondern als Designprinzip: Wer Session-Log, Harness und Sandbox in einem Container hält, baut sich ein Pet, das er nicht verlieren kann. Das ist keine KI-spezifische Erkenntnis, sondern Cloud-Infrastruktur-Hygiene, angewendet auf einen neuen Stack.