Managed Agents skalieren: Gehirn und Hände trennen

• Der Hosting-Service Managed Agents für langlaufende Agenten setzt auf eine schnittstellenbasierte Architektur, die stabil bleibt, auch wenn sich der Harness mit dem Fortschritt der Modelle verändert
• Der Harness kodiert Annahmen über Aufgaben, die Claude nicht allein ausführen kann. Mit der Weiterentwicklung des Modells werden diese Annahmen jedoch veraltet (stale) und verursachen unnötigen Overhead
• So wie ein Betriebssystem Hardware über Abstraktionen wie Prozesse und Dateien virtualisiert, virtualisiert Managed Agents Agentenkomponenten (Session, Harness, Sandbox), sodass sie unabhängig voneinander austauschbar sind
• Durch die Trennung von Gehirn (Harness) und Händen (Sandbox) wurden Leistungsverbesserungen erreicht: p50 TTFT um etwa 60 % reduziert, p95 um mehr als 90 % reduziert
• Dieses Design übernimmt die Rolle eines Meta-Harness, das künftig jede neue Harness- oder Sandbox-Variante aufnehmen kann

---

Annahmen des Harness werden mit dem Modellfortschritt veraltet

• Der Harness ist eine Struktur, die Annahmen über Aufgaben kodiert, die Claude nicht selbst erledigen kann. Mit der Weiterentwicklung des Modells werden diese Annahmen jedoch überflüssig
• In Claude Sonnet 4.5 trat das Phänomen "context anxiety" auf, bei dem Aufgaben frühzeitig beendet wurden, wenn sich das Kontextlimit näherte. Deshalb wurde dem Harness ein Kontext-Reset hinzugefügt
• In Claude Opus 4.5 verschwand dieses Verhalten, wodurch die Reset-Logik zu unnötigem Code wurde
• Da zu erwarten ist, dass sich Harnesses weiter verändern, wurde der Managed-Agents-Service auf Basis einer allgemeinen Schnittstelle aufgebaut, die nicht an eine bestimmte Implementierung gebunden ist

Eine von Betriebssystemen inspirierte Designphilosophie

• Betriebssysteme virtualisieren Hardware über Abstraktionen wie Prozesse und Dateien, sodass auch Programme ausgeführt werden können, die noch gar nicht existieren
• So wie der Befehl read() unabhängig davon gleich funktioniert, ob dahinter ein Disk Pack aus den 1970ern oder eine moderne SSD steckt, überdauern Abstraktionen die zugrunde liegende Hardware
• Managed Agents folgt demselben Muster und virtualisiert Agentenkomponenten
  • Session: ein Append-only-Log aller aufgetretenen Ereignisse
  • Harness: die Schleife, die Claude aufruft und Tool-Aufrufe weiterleitet
  • Sandbox: die Ausführungsumgebung, in der Claude Code ausführt und Dateien bearbeitet

Frühes Design: Grenzen eines einzelnen Containers (das „Pet“-Problem)

• Anfangs wurden Session, Harness und Sandbox in einem einzigen Container untergebracht
• Das hatte Vorteile: Dateibearbeitung war direkt per Syscall möglich, und Service-Grenzen mussten nicht entworfen werden
• Allerdings entstand das Problem, dass der Container zu einem „pet“ wurde, also zu einer individuellen Instanz, die sich nicht einfach ersetzen lässt
  • Bei einem Container-Ausfall ging die Session verloren
  • Wenn der Container nicht mehr reagierte, musste er manuell wiederhergestellt werden
• Aus Debugging-Sicht war es mit dem WebSocket-Event-Stream allein unmöglich festzustellen, wo ein Fehler auftrat. Ein Shell-Zugriff auf den Container war ebenfalls schwierig, da er Nutzerdaten enthielt
• Der Harness ging davon aus, dass sich alle Arbeitsziele im Container befinden. Bei Anforderungen nach einer VPC-Anbindung von Kunden waren deshalb Network Peering oder die Ausführung des Harness in der eigenen Umgebung nötig

Trennung von Gehirn und Händen (Kernarchitektur)

• „Gehirn“ (Claude und Harness), „Hände“ (Sandbox und Tools) und „Session“ (Event-Log) werden jeweils über unabhängige Schnittstellen getrennt
• Jede Komponente kann unabhängig ausfallen oder ersetzt werden

Der Ausbruch des Harness aus dem Container

• Der Harness wurde aus dem Container herausgelöst und ruft den Container nun wie jedes andere Tool über execute(name, input) → string auf
• Dadurch wurde der Container von „cattle“ zu einer austauschbaren Instanz
• Fällt ein Container aus, behandelt der Harness dies als Fehler bei einem Tool-Aufruf. Entscheidet Claude auf Wiederholung, wird über provision({resources}) ein neuer Container initialisiert

Wiederherstellung nach Harness-Ausfällen

• Da sich das Session-Log außerhalb des Harness befindet, muss darin kein interner Zustand überleben
• Im Fehlerfall werden per wake(sessionId) → getSession(id) die Event-Logs geladen und ab dem letzten Ereignis fortgesetzt
• Während der Agenten-Schleife hält der Harness mit emitEvent(id, event) dauerhaft gespeicherte Event-Aufzeichnungen aufrecht

Sicherheitsgrenzen

• Im gekoppelten Design lief von Claude erzeugter, nicht vertrauenswürdiger Code im selben Container wie Zugangsdaten, sodass Prompt Injection Umgebungsvariablen auslesen konnte
• Gelangte ein Angreifer an ein Token, konnte er uneingeschränkt neue Sessions erzeugen und Arbeit delegieren
• Die strukturelle Lösung bestand darin, die Komponenten so zu trennen, dass die Sandbox niemals direkten Zugriff auf Tokens hat
• Git: Beim Initialisieren der Sandbox mit einem Repository-Access-Token wird geklont und mit einem lokalen Git-Remote verbunden, sodass der Agent push und pull ausführen kann, ohne das Token direkt zu handhaben
• MCP-Custom-Tools: OAuth-Tokens werden in einem sicheren Vault gespeichert. Ein dedizierter Proxy holt beim MCP-Tool-Aufruf die zur Session gehörenden Zugangsdaten aus dem Vault und ruft damit den externen Dienst auf

Die Session ist nicht Claudes Kontextfenster

• Langlaufende Aufgaben überschreiten häufig die Länge von Claudes Kontextfenster, weshalb irreversible Entscheidungen darüber nötig werden, was erhalten bleibt
• Compaction: Claude speichert eine Zusammenfassung des Kontextfensters
• Memory-Tool: Claude schreibt Kontext in Dateien, um sessionübergreifend lernen zu können
• Context Trimming: Selektives Entfernen von Tokens wie alten Tool-Ergebnissen oder Thinking-Blöcken
• Irreversibles Verwerfen von Kontext kann scheitern, weil sich schwer vorhersagen lässt, welche Tokens ein zukünftiger Turn benötigt
• Frühere Forschung hat untersucht, Kontext als außerhalb des Kontextfensters existierendes Objekt zu speichern, auf das das LLM programmatisch per selbst geschriebenem Code zugreift

Nutzung des Session-Logs in Managed Agents

• Die Session dient als Kontextobjekt, das außerhalb des Kontextfensters existiert
• Sie wird dauerhaft im Session-Log gespeichert, nicht in einer Sandbox oder REPL
• Über die Schnittstelle getEvents() lassen sich positionsbasierte Slices des Event-Streams auswählen
  • Weiterlesen ab der letzten Leseposition
  • Einige Events vor einen bestimmten Zeitpunkt zurückspulen
  • Den Kontext vor einer bestimmten Aktion erneut lesen
• Die geladenen Events können im Harness transformiert und anschließend an Claudes Kontextfenster übergeben werden
• Zu diesen Transformationen gehören Kontextbereinigung und Context Engineering für eine hohe Prompt-Cache-Trefferquote
• Die Session garantiert nur dauerhafte Speicherung und Abruf; das konkrete Kontextmanagement wird dem Harness überlassen, damit sich das System an künftige Modellanforderungen anpassen kann

Viele Gehirne, viele Hände

Viele Gehirne (Many Brains)

• Die Trennung von Gehirn und Händen löste frühe Kundenbeschwerden: Für Arbeit an Ressourcen innerhalb einer VPC ist kein Network Peering mehr nötig
• Im frühen Design brauchte jedes Gehirn einen eigenen Container, weshalb Inference erst nach Abschluss des Container-Provisionings beginnen konnte
• Selbst Sessions ohne Sandbox-Bedarf trugen die Kosten eines vollständigen Container-Setups, etwa Repository-Klonen, Prozessstart und Laden ausstehender Events
• Nach der Trennung wird ein Container nur noch bei Bedarf per Tool-Aufruf provisioniert, wodurch unnötige Wartezeit entfällt
• Die Inference kann beginnen, sobald die Orchestrierungsschicht ausstehende Events aus dem Session-Log geladen hat
• Ergebnis: p50 TTFT etwa 60 % niedriger, p95 TTFT mehr als 90 % niedriger
• Die Skalierung auf viele Gehirne bedeutet schlicht, mehrere zustandslose (stateless) Harnesses zu starten und sie nur bei Bedarf mit Händen zu verbinden

Viele Hände (Many Hands)

• Erforderlich ist die Fähigkeit, jedes Gehirn mit mehreren Ausführungsumgebungen zu verbinden
• Claude muss über mehrere Ausführungsumgebungen hinweg denken und entscheiden, wie Aufgaben verteilt werden. Das ist kognitiv schwieriger als eine einzelne Shell
• Anfangs wurde das Gehirn wegen begrenzter Modellfähigkeiten in einen einzelnen Container gesetzt. Mit steigender Intelligenz wurde dieser einzelne Container jedoch selbst zur Einschränkung
• Im entkoppelten Design wird jede Hand als Tool execute(name, input) → string behandelt
  • Unterstützt werden Custom Tools, MCP-Server und eigene Tools
  • Der Harness muss nicht wissen, ob eine Sandbox ein Container, ein Smartphone oder ein Pokémon-Emulator ist
• Da Gehirn und Hände nicht gekoppelt sind, können Hände auch zwischen Gehirnen übergeben werden

Fazit: Managed Agents als Meta-Harness

• Der Ansatz entspricht dem eines Betriebssystems, das Hardware virtualisiert und damit auch Programme aufnehmen kann, die noch nicht existieren
• Managed Agents ist ein Meta-Harness, der nicht an einen bestimmten Harness gebunden ist und eine allgemeine Schnittstelle für unterschiedliche Harnesses bietet
• Auch Claude Code kann als ein Harness verwendet werden, ebenso aufgabenspezifische Agenten-Harnesses
• In Bezug auf die Schnittstellen gibt es eine klare Position: Claude benötigt die Fähigkeit zu Zustandsmanipulation (Session) und Berechnungsausführung (Sandbox)
• Das Interface-Design ist auf Skalierung zu vielen Gehirnen und Händen sowie auf langfristig stabilen und sicheren Betrieb ausgelegt
• Über Anzahl oder Ort von Gehirnen und Händen werden keinerlei Annahmen getroffen