Claude Managed Agents: Setup, Konfiguration und SDK Trade-offs

Claude Managed Agents ist Anthropics gehostete Agent-Infrastruktur, zum Zeitpunkt des Schreibens in Beta. Sie führt die Agent-Schleife, die Sandbox und das Session-Log auf Anthropics Seite aus und berechnet die Laufzeit mit 0,08 $ pro Session-Stunde zusätzlich zu Token ab, wobei Leerlaufzeit kostenlos ist. Du sendest Events und streamst Ergebnisse, statt diese Schicht selbst zu pflegen. Dieser Beitrag ist eine dokumentierte Anleitung, was der Service hostet, wie sich der ant apply datei-basierte Workflow verhält und wo das Agent SDK immer noch die bessere Wahl ist.

Hinweis: Managed Agents ist zum Zeitpunkt des Schreibens ein Beta-Service. Behandle alles hier entsprechend.

Was Claude Managed Agents für dich hostet

Kurz gesagt: Anthropic führt das Agent-Harness, die Compute-Sandbox und das Session-Log aus. Du sendest Events und streaming die Ergebnisse über HTTP zurück. Das war's. Du verwaltest nicht den Container-Lebenszyklus, die Tool-Ausführungsumgebung oder die Wiederholungslogik für vorübergehende Ausfälle.

Genauer gesagt, hier ist, was auf Anthropics Seite landet:

• Die Agent-Schleife. Claude entscheidet, wann ein Tool aufgerufen werden soll, verarbeitet das Ergebnis und iteriert, ohne dass du die Orchestrierung schreibst.
• Eingebaute Tools. Bash, Dateivorgänge, Websuche, alle zugänglich über den Tool-Typ agent_toolset_20260401. Du verdrahtest diese nicht selbst.
• Pro-Session-Sandboxes. Jede Session erhält ihre eigene isolierte Ausführungsumgebung. Kein Cross-Session-Bleed.
• Dauerhafte Session-Logs. Wenn deine Anwendung den Stream unterbricht, ist die Session nicht verschwunden. Du verbindest dich wieder und holst auf.
• MCP-Integration. Custom-Tools verbinden sich als MCP-Server. Claude triggert das Tool; dein Service gibt Ergebnisse über das Protokoll zurück. Nichts, das du in deinen Deploy bündeln musst.
• Prompt Caching. Auf Plattformebene eingebaut, was zählt, sobald deine System-Prompts lang werden.

Was du auf deiner Seite behältst: die Agent-Definition, deine MCP-Server-Implementierungen und jegliche Business-Logik, die entscheidet, wann eine Session gestartet oder gestoppt werden soll. Das ist eine viel kleinere Oberfläche zu besitzen als ein vollständiges Harness.

Hatchworks behandelt die Infrastruktur-Aufteilung klar: Inference kann starten, bevor ein Container bereitgestellt wird, was oft schneller für Cold-Start-Agenten ausfällt, auch wenn jeder Tool-Aufruf eine Service-Grenze kreuzt.

Wann man Managed Agents, das Agent SDK oder Claude Code wählt

Die Verwirrung, die ich am häufigsten sehe, ist, dass Leute diese drei als austauschbar behandeln. Das sind sie nicht.

Claude Code ist ein Terminal-Tool. Großartig für einen Entwickler, der Aufgaben lokal ausführt. Nicht etwas, das man in ein Produkt einbettet.

Das [Agent SDK](/blog/claude-agent-sdk-guide-2026/) führt die Agent-Schleife in deinem eigenen Prozess auf deiner eigenen Infrastruktur aus. Direkter Dateisystem-Zugriff, private Netzwerkverbindung, vollständige Kontrolle über die Ausführungsumgebung. Du wählst das SDK, wenn du Dinge wie lokale Dateischreib-Vorgänge ohne Service-Grenze brauchst, vorhandene Infrastruktur, für die du bereits bezahlt hast, oder Multi-Provider-Flexibilität auf Modellebene (obwohl du vorerst mit dem SDK an Claude gebunden bist).

Managed Agents ist die gehostete Lösung. Du erhältst persistente Sessions, Sandbox-Computing und eingebaute Observability, ohne etwas davon selbst zu bauen. Das Kostenmodell ist pro Session-Stunde, nicht nur pro Token, daher belohnt es kurze fokussierte Sessions und bestraft lange untätige.

Hier ist die Entscheidungstabelle:

Eine Sache, die es wert ist, zu kennzeichnen: Wie in der SDK-Anleitung auf hidekazu-konishi.com vermerkt, ist ein gängiger Weg, lokal mit dem SDK zu prototypisieren und zu Managed Agents zu migrieren, sobald du gehostete Sandboxes möchtest, die du nicht selbst betreiben möchtest.

Falls deine spezifische Herausforderung darin besteht, das vollständige agentic-Produkt drumherum zu bauen, könnte unsere agentic-Engineering-Arbeit dir ein paar Umwege sparen.

Erstelle einen Agent und überprüfe eine Session

Dies ist eine dokumentierte Anleitung, keine verifizierte Produktionsausführung. Ich beschreibe das Verfahren aus der offiziellen Dokumentation; betrachte jeden Code hier als illustrativ, bis du ihn gegen deinen eigenen Schlüssel ausgeführt hast.

Zu einem laufenden Agent braucht es vier Schritte.

1. Erstelle eine Agent-Definition. Hier beschreibst du, was der Agent tun kann: auf welche integrierten Tools er Zugriff hat, welche MCP-Server er aufrufen kann, und was sein System-Prompt ist.
2. Erstelle eine Ausführungsumgebung. Die Plattform stellt eine Sandbox bereit, die auf deine Agent-Definition ausgerichtet ist.
3. Starte eine Session. Du sendest ein Start-Event mit der Eingabe deines Benutzers. Die Session-ID kommt sofort zurück.
4. Streame Events. Tool-Aufrufe, Zwischenergebnisse und die endgültige Antwort kommen alle im Stream an. Du verarbeitest sie in deiner Anwendung.

Über die sieben offiziellen SDKs (Python, TypeScript, Go, Java, C#, Ruby, PHP) ist die Form dieses Ablaufs konsistent, auch wenn die Syntax unterschiedlich ist. Der Werkzeugtyp agent_toolset_20260401 ist das, was den vollständigen integrierten Werkzeugkasten in einer einzigen Deklaration freischaltet. Du zählst bash, Dateivorgänge und Web-Suche nicht einzeln auf.

Sobald eine Session läuft, kannst du sie über den Session-Log-Endpunkt überprüfen. Hier zeigt sich der Persistenz-Vorteil konkret. Unterbreche den Stream, verbinde dich erneut, und das Log wird von wo du aufgehört hast abgespielt. Bei lang laufenden Aufgaben, bei denen der Client die Verbindung trennen könnte, ist das sehr wichtig.

Verwalte Ressourcen mit ant apply und claude-lock.json

Das ant CLI ist ein separates Tool vom SDK selbst. Installiere es über Homebrew. Es bietet einen dateigestützten Workflow zum Deklarieren deiner Agent-Ressourcen (Agents, Umgebungen, MCP-Server-Registrierungen) in Konfigurationsdateien und wende sie dann auf die Plattform an.

Die ant apply-Dokumentation beschreibt den Kernbefehl:

ant apply

Bevor du Production anfasst, führe das Dry-Run-Flag aus:

Das ant CLI ist ein separates Tool vom SDK selbst. Installiere es über Homebrew. Es bietet einen dateigestützten Workflow zum Deklarieren deiner Agent-Ressourcen (Agents, Umgebungen, MCP-Server-Registrierungen) in Konfigurationsdateien und wende sie dann auf die Plattform an.

Dies zeigt eine Vorschau, was die Anwendung bewirken würde. Wichtiger Vorbehalt aus der offiziellen Dokumentation: --dry-run kann auch bei einem Plan, der zur Apply-Zeit blockiert würde, mit 0 beendet werden. Behandle einen sauberen Dry-Run nicht als Garantie, dass die vollständige Anwendung erfolgreich sein wird. Überprüfe die tatsächliche Anwendung zunächst in einer Staging-Umgebung.

Die Datei claude-lock.json ist die Sperrdatei, die den aktuellen Zustand deiner bereitgestellten Ressourcen erfasst. Denk an sie wie an package-lock.json – sie fixiert Ressourcenversionen und verhindert Drift zwischen dem, was du deklariert hast, und dem, was die Plattform ausführt. Nach jedem ant apply wird die Sperrdatei aktualisiert, um den neuen Zustand widerzuspiegeln. Versionskontrolle sie. Behandle Änderungen daran als bedeutungsvoll in Code-Reviews.

Ein Serialisierungspunkt, der Probleme verursacht: Teilweise Anwendungen. Wenn ant apply in der Mitte fehlschlägt, befinden sich einige Ressourcen im neuen Zustand und andere nicht. Die Sperrdatei wird die teilweise Aktualisierung widerspiegeln. Bevor du ant apply erneut ausführst, vergleiche die Sperrdatei mit dem, was tatsächlich bereitgestellt wurde, gleiche ggf. manuell ab, und führe dann erneut aus. Eine zweite Anwendung über einen unterbrochenen Teilzustand auszuführen, ohne vorher zu prüfen, kann Ressourcen in einem verwirrten Zwischenzustand hinterlassen.

Das unterscheidet sich von Tools wie Terraform, die einen separaten plan-Schritt in der CLI haben. Es gibt kein ant plan. Der Dry-Run ist deine Vorschau. Gestalte deine CI entsprechend.

Änderungen in CI überprüfen und Teilausfälle handhaben

Für Teams, bei denen mehrere Entwickler gegen die gleiche Managed Agents-Umgebung arbeiten, wird dringend empfohlen, Änderungen von CI aus statt von lokalen Maschinen anzuwenden. Andernfalls entstehen Race Conditions in der Sperrdatei.

Hier ist der Workflow, den ich vorschlagen würde:

1. PR wird geöffnet. CI führt ant apply --dry-run aus und postet die Ausgabe als PR-Kommentar.
2. Reviewer prüft das Diff, einschließlich aller Sperrdatei-Änderungen.
3. Bei Merge zu main führt CI ant apply gegen die Staging-Umgebung aus.
4. Promote zu Production nur nach erfolgreichem Staging-Apply und wenn Sessions korrekt funktionieren.

Die Serialisierungsanforderung ist die wichtigste operative Einschränkung. Du kannst nicht zwei ant apply-Aufrufe parallel gegen die gleiche Umgebung ausführen. Wenn dein CI-System mehrere Merges schnell in die Warteschlange einreihen kann, erzwinge eine Sperre auf Pipeline-Ebene (die meisten CI-Plattformen haben genau dafür eine Concurrency-Group-Einstellung).

Die Checkliste für die Behandlung von Teilausfällen sieht so aus:

• Überprüfe die Sperrdatei unmittelbar nach einem fehlgeschlagenen Apply. Notiere, welche Ressourcen aktualisiert wurden und welche nicht.
• Führe ant apply nicht blind erneut aus. Lies zuerst die Fehlermeldung.
• Wenn der Teilzustand sicher ist, um ihn zu belassen, während du untersuchst, dann belasse ihn. Wenn sich Ressourcen in einem unterbrochenen Zwischenzustand befinden, musst du möglicherweise manuell zurückrollen, bevor du neu anwendest.
• Führe nach der Behebung ant apply --dry-run erneut aus, bevor die vollständige Anwendung stattfindet, um zu bestätigen, dass der Plan richtig aussieht.

Da --dry-run auch bei einem blockierten Plan mit 0 beendet werden kann, überspringe den Review-Schritt nicht, auch wenn der Dry-Run sauber aussieht.

Beta-Limitierungen, Kosten und eine Bereitstellungs-Checkliste

Managed Agents ist ein Beta-Service. Diese Bezeichnung ist für alles Produktionskritische relevant. Funktionen können sich ändern. Preise können sich ändern. Verfügbarkeitszusicherungen in Beta sind nicht mit GA identisch.

Kosten. Der veröffentlichte Tarif beträgt 0,08 $ pro Session-Stunde, berechnet nur während eine Session läuft (Leerlaufzeit wird nicht berechnet), wobei Token zusätzlich zu Standard-Modellraten berechnet werden. Das macht es relativ vorhersehbar für kurze, aufgabenorientierte Sessions. Bei langdauernden Sessions mit umfangreicher Tool-Nutzung solltest du die Session-Dauer aktiv überwachen. Der Leitfaden von vibecodingacademy setzt das in Kontext: Kostenkonkurrenzfähigkeit hängt von der Engineerzeit ab, die du für den Aufbau gleichwertiger selbstverwalteter Infrastruktur aufwenden würdest, was real und oft unterschätzt wird.

Aktuelle Einschränkungen in Beta:

• Custom Tools werden über MCP-Server geroutet, nicht als In-Process-Funktionen. Wenn dein Custom Tooling eng an die Laufzeit deiner Anwendung gekoppelt ist, musst du es zunächst in einen MCP-Server extrahieren.
• Session-Observability erfolgt über den Session-Log-Endpoint. Es gibt kein eingebautes Dashboard-Äquivalent zu dem, was du selbst auf Basis des SDK aufbauen würdest.
• ant apply zeigt Partialausfallsemantik und erfordert manuelle Abstimmung. Es gibt kein automatisches Rollback.
• Serialisierte apply-Vorgänge bedeuten, dass der Pipeline-Durchsatz durch die apply-Dauer begrenzt ist.

Checkliste vor der Bereitstellung:

1. Agent-Definition überprüft und System-Prompt abgeschlossen
2. MCP-Server registriert und vor der Verdrahtung mit dem Agent unabhängig getestet
3. claude-lock.json committed und als überprüftes Artefakt behandelt
4. ant apply --dry-run Ausgabe von einer zweiten Person überprüft, bevor ein Production-apply durchgeführt wird
5. Session-Dauer-Überwachung etabliert (auf unerwartet lange Sessions achten)
6. Verfahren zur Partialausfallwiederherstellung für Ihr Team dokumentiert
7. Staging-Umgebung vor Production-Bereitstellung validiert
8. Budget-Warnungen auf Kontoebene konfiguriert, da sich die Beta-Preisgestaltung ändern könnte

Eine letzte Anmerkung zur Build-vs-Buy-Frage. Das Agent SDK gibt Dir mehr Kontrolle, ja. Aber Kontrolle bedeutet Verantwortung. Wie ksred zum SDK bemerkt, können agentic Sessions, die umfangreiche Arbeit leisten, schnell teuer werden, und die Fehlerwiederherstellung liegt vollständig in Deinem Design beim SDK. Managed Agents tauscht etwas von dieser Kontrolle gegen dauerhafte Sessions und Infrastruktur ein, die Du nicht betreiben musst. Keiner ist falsch. Die Wahl hängt davon ab, was Dein Team tatsächlich warten kann.

ant apply --dry-run Ausgabe von einer zweiten Person überprüft, bevor ein Production-apply durchgeführt wird

Funktioniert Managed Agents mit einem beliebigen Claude-Modell oder ist es auf bestimmte Versionen beschränkt?

Die offizielle Dokumentation listet zum Zeitpunkt des Schreibens keine spezifischen Modellbeschränkungen in Managed Agents auf. Angesichts des Beta-Status kann die Modellverfügbarkeit sich verschieben. Überprüfe die overview page direkt, bevor Du Dich auf eine bestimmte Modellversion in einer Production-Agent-Definition festlegst.

Kann ich die gleiche Agent-Definition lokal mit dem SDK zu Testzwecken ausführen, bevor ich zu Managed Agents deploye?

Nicht direkt. Das SDK führt die Loop in Deinem eigenen Prozess gegen Deine lokale Umgebung aus; Managed Agents führt sie in Anthropic's Sandbox aus. Du kannst das Agent-Verhalten mit dem SDK prototypisieren, aber der Ausführungskontext ist unterschiedlich genug, dass Du die tatsächliche Managed Agents-Bereitstellung in einer Staging-Umgebung testen solltest, bevor Du zur Production hochfährst.

Wie handhabt Managed Agents die Authentifizierung für MCP-Server, die Anmeldedaten benötigen?

Die offizielle Dokumentation beschreibt benutzerdefinierte Tools als Verbindung über MCP-Server, wobei Claude das Tool auslöst und Dein Service die Ergebnisse zurückgibt. Die Verwaltung von Anmeldedaten für diese MCP-Server liegt in Deiner Verantwortung auf Serverebene. Managed Agents injiziert Anmeldedaten nach aktuellem Dokumentationsstand nicht in MCP-Aufrufe in Deinem Namen.

Gibt es eine Möglichkeit, die Ausgaben pro Session in Managed Agents zu begrenzen, wie der max_budget_usd Parameter des SDK?

Der max_budget_usd Parameter des SDK auf query() ist eine SDK-Ebenen-Kontrolle, die sich nicht direkt auf die Managed Agents REST API überträgt. Budget-Kontrollen innerhalb von Managed Agents sind in der aktuellen Beta nicht auf die gleiche Granularität dokumentiert. Warnungen auf Kontoebene sind derzeit die sicherste Auffanglösung.

Was geschieht mit einer laufenden Session, wenn die Region oder Sandbox einen Ausfall erleidet?

Dauerhafte Session-Logs sind ein Kerndesign-Feature von Managed Agents, aber die Einzelheiten der Session-Wiederherstellung über einen Infrastruktur-Ausfall hinweg werden in der aktuellen Beta-Dokumentation nicht detailliert beschrieben. Angesichts der Beta-Bezeichnung solltest Du die Dauerhaftigkeitsgarantie als Best-Effort behandeln, bis Anthropic ein SLA für den Service veröffentlicht.

Die ehrliche Zusammenfassung: Managed Agents ist ein genuinely nützlicher Service, der eine große Klasse von Infrastrukturarbeit eliminiert. Der ant apply Workflow ist unkompliziert, wenn Du die dry-run Fallstricke und die Serialisierungsanforderung verstehst. Aber es ist beta, die Partialausfallsemantik erfordert Sorgfalt, und es ist nicht die richtige Antwort, wenn Du lokalen Dateisystemzugriff benötigst oder bereits Agent-Infrastruktur hast, mit der Du zufrieden bist. Beginne mit der Entscheidungstabelle, wähle basierend auf dem, was Dein Team tatsächlich besitzen möchte, und behandle die Lockfile so ernst wie jede andere State-Datei.