Managed Agents vs Self-Hosted, wann was Sinn ergibt

Seit dem 23. April 2026 ist "Memory for Managed Agents" bei Anthropic in Public Beta. Das ist Anthropics direkter Schritt zu einer Hosted-Plattform für Agent-Worker, mit Session-, Harness- und Sandbox-Virtualisierung als entkoppelte Services. Bis dahin musste man so etwas selber hosten: eigener Postgres, eigener Memory-Server, eigener Container-Runner. Jetzt geht es als-Service.

Das wirft die Frage auf die Du als Operator irgendwann beantworten musst: Hosted oder Self-Hosted?

In dieser Lesson lernst Du wann was Sinn ergibt, was die echten Trade-Offs sind, und wie Du eine Entscheidung dokumentierst die Du in zwei Jahren noch nachvollziehen kannst.

Was Managed Agents von Anthropic eigentlich ist

Drei entkoppelte Services:

• Session Service. Konversations-State und Memory, persistent über Sessions hinweg. Was bei Dir lokal die Postgres-Tabelle wäre, läuft hier auf Anthropic-Infrastruktur.
• Harness Service. Das was den Agent ausführt: tools verfügbar machen, MCP-Server connecten, Permissions checken.
• Sandbox Service. Code-Ausführung in isolierter Umgebung. Statt Du baust Docker-Container und Daemons, schickst Du Bash-Code zur Sandbox und kriegst das Ergebnis zurück.

Plus ein Token-Vault für Secrets. Heißt: Du musst nicht mehr API-Keys in Containern verwalten oder Vault-Lookups bauen. Du gibst Anthropic einmal Deine Secrets, der Sandbox-Service kriegt sie zur Laufzeit.

Pricing: Im Beta ist es Teil vom Max Plan, später wahrscheinlich Per-Sandbox-Hour. Genaue Konditionen gibt's noch nicht öffentlich.

Wann Hosted (Managed Agents) Sinn ergibt

Wenn Du der Bauer bist und nicht der Devops-Mensch. Du baust ein Tool, willst nicht parallel ein Postgres-Cluster managen. Hosted nimmt Dir alle Infra-Fragen ab.

Wenn Du einen Prototyp validierst. Schneller starten, weniger Setup. Wenn der Prototyp scheitert, hast Du nichts hingestellt das Du jetzt abreissen musst.

Wenn Dein Use-Case kein hartes Datenhoheits-Anforderung hat. B2C-Tools, Marketing-Automatisierung, persönliche Assistenten. Daten dürfen ins US-Cloud, kein Compliance-Hinderniss.

Wenn Latenz primär ist und Du nicht selber optimieren willst. Anthropic hat Edge-Lokationen weltweit, Selber-Hosten in Frankfurt heißt 200ms Round-Trip wenn ein User aus Australien zugreift.

Wenn Du wenig Custom-MCP-Server hast. Hosted unterstützt out-of-the-box die Standard-MCPs (GitHub, Slack, Notion etc). Dein eigener interner MCP geht auch, aber dann brauchst Du noch eine Public-URL plus Auth.

Wann Self-Hosted Sinn ergibt

Wenn Datenhoheit ein harter Anforderung ist. EU-Datenresidenz für DSGVO-sensible Daten, deutsche Bundesnetzagentur-Audits, Health-Care, juristische Mandate. Anthropic-Hosted ist US-Cloud, das geht für viele KMU rechtlich nicht.

Wenn Deine Use-Cases sehr custom sind. Du brauchst zehn eigene MCP-Server die alle gegen Deine internen APIs gehen, mit Auth-Patterns die Hosted nicht kennt. Self-Hosted gibt Dir die Freiheit alles selber zu definieren.

Wenn Du die Kostenkontrolle behalten willst. Bei großen Volumes kann ein selbst betriebener Postgres deutlich günstiger sein als Per-Session-Pricing eines Managed-Service. Aber: Du zahlst dafür mit Devops-Zeit.

Wenn Du Air-Gap Anforderungen hast. Manche Konzern-Setups erlauben keine Cloud-Calls von Production-Systemen. Self-Hosted ist die einzige Option.

Wenn Du tief Customizing willst. Eigene Memory-Strategien, eigene Decay-Funktionen, eigene Embedding-Modelle. Das geht in Hosted nicht oder nur eingeschränkt.

Die Hybrid-Variante (oft die richtige Antwort)

In der Praxis ist die Antwort selten "alles hosted" oder "alles self-hosted", sondern Hybrid:

• Hosted für die Standard-Use-Cases. Tagesgeschäft, Marketing, allgemeine Assistenten. Schnelle Iteration, keine Infra-Pflege.
• Self-Hosted für die sensitiven Use-Cases. Kunden-Daten, Finanzberichte, juristische Inhalte. EU-Server, eigene Memory-Datenbank, eigener Container-Runner.

Für StudioMeyer machen wir genau das: SaaS-Memory-Server (memory.studiomeyer.io) ist hosted, aber unsere internen Agents (Academy Fleet, MCP SaaS Fleet) laufen auf eigenem Container-Setup mit eigener Postgres, weil dort interne Daten und Customer-Daten zusammenkommen.

Decision-Framework

Wenn Du nicht sicher bist, geh diese fünf Fragen durch:

1. Datenhoheit: Müssen die Daten in EU/Deutschland bleiben? Wenn ja → Self-Hosted oder EU-hosted Anbieter.
2. Compliance: DSGVO-sensibel, Health/Legal/Finance, BaFin-relevant? Wenn ja → Self-Hosted oder Enterprise-Plan mit DPA.
3. Custom-MCPs: Hast Du mehr als zwei eigene MCP-Server die intern laufen? Wenn ja → Self-Hosted ist einfacher.
4. Devops-Kapazität: Hast Du jemanden der einen Postgres-Cluster pflegt und Disaster-Recovery testet? Wenn nein → Hosted.
5. Volume + Kostenkontrolle: Mehr als 1000 Sessions/Tag? Wenn ja → Self-Hosted wird günstiger ab einer Schwelle.

Wenn Du auf 2 oder 3 davon "ja" sagst → Self-Hosted oder Hybrid. Sonst → Hosted starten, später migrieren wenn nötig.

Migrations-Pfad

Wichtig: Du kannst von Hosted zu Self-Hosted migrieren, aber es ist Arbeit. Anthropic Managed Agents speichert Memory in deren Format, Du musst es exportieren und in Dein eigenes Format konvertieren. Plan dafür mindestens eine Woche ein wenn Du das ernst machst.

Andersherum (Self-Hosted zu Hosted) ist tendenziell einfacher, weil Anthropic Import-Tools anbietet. Aber auch das ist nicht null Aufwand.

Was Du jetzt hast

Ein klares Bild davon was Hosted vs Self-Hosted bedeutet, wann was Sinn ergibt, und ein Decision-Framework für Deine eigene Architektur. Wichtig: das ist keine Religionsfrage, sondern eine Use-Case-getriebene Entscheidung die sich über Zeit ändern kann.

Plus: 80 Prozent der StudioMeyer-Kunden fahren Hybrid. Hosted wenn schnell, Self-Hosted wenn sensitiv. Diese 80-Prozent-Lösung ist meistens die richtige.

Naechste Schritte

Capstone Level 5 ist Dein Test-Fall. Bau einen Multi-Agent-Setup für ein Use-Case Deiner Wahl, dokumentier ob Du Hosted oder Self-Hosted nimmst und warum. Wenn Du das schreibst statt nur zu denken, hast Du eine Entscheidungsbasis für späteres Refactoring.