Anthropic und Google haben das gleiche Produkt gelauncht. 2 Wochen Abstand. Verschiedene Logos.

Im April 2026 brachte Anthropic Claude Managed Agents in die öffentliche Beta. 3 Wochen später auf der Google I/O lieferte Google Managed Agents innerhalb der Gemini API aus, verpackt in eine Entwickler-Suite namens Project Antigravity. Falls ihr verfolgt habt, wohin sich Vibe-Coding entwickelt (über die Demo hinaus, in die Produktion), ist das das Signal, auf das ihr gewartet habt.

Beide Keynotes verwendeten unterschiedliche Begriffe. Beide Preisseiten sehen völlig unabhängig aus. Die Presse berichtete über sie als konkurrierende Visionen.

Das sind keine konkurrierenden Visionen. Gleiche Architektur, 2 Logos auf dem Container.

Ich verbrachte ein paar Tage damit, beide Dokumentationen nebeneinander zu lesen. Das Ausmaß der Konvergenz ist zu offensichtlich, um es als Zufall oder Kuriosität abzutun. Es ist ein direktes Signal darüber, wo echte Wertschöpfung in der KI-Infrastruktur 2026 tatsächlich landet.

Was mich beim Lesen beider Dokumentationen beeindruckte: beide Teams wissen genau, was sie tun. Sie konvergierten nicht zufällig. Sie lösten dasselbe Problem auf dieselbe Weise, weil es wirklich nur 1 Weg gibt, der funktioniert. Und dieser Weg ist nicht das Modell. Es ist die Runtime.

Das Diagramm hinter beiden Keynotes

Beide Produkte implementieren dieselbe physische Trennung: das Modell-"Gehirn" läuft in der Cloud des Anbieters. Die Tool-Ausführungs-"Hände" laufen in einer ephemeren Linux-Sandbox, die ebenfalls dem Anbieter gehört. Eine persistente Session verbindet beide für Stunden, Tage oder Wochen.

Anthropic nennt es "Trennung von Gehirn und Händen." Google macht sich nicht die Mühe, es zu benennen. So funktioniert einfach die Managed Agents API. Unterschiedliche Formulierung. Identisches Diagramm.

In beiden Systemen macht ihr einen einzigen API-Aufruf, um einen Agenten bereitzustellen. Der Anbieter startet einen isolierten Linux-Container in seinem eigenen Rechenzentrum. Das Modell entscheidet, was zu tun ist. Wenn es Shell-Befehle ausführen, Dateien bearbeiten, im Web browsen oder einen externen Service aufrufen möchte, werden diese Aktionen innerhalb dieses Containers ausgeführt (nicht auf euren Servern, nicht in einem Docker-Image, das ihr wartet, nicht in einer Lambda, die ihr bereitgestellt habt). Der Container des Anbieters, im Netzwerk des Anbieters, schreibt in die Audit-Logs des Anbieters.

Ihr bekommt einen Stream von Events zurück: das Reasoning des Modells, die Tool-Aufrufe, die Outputs. Ihr berührt nie die Maschine. Könnt ihr nicht. Das ist das Produkt.

Für alle, die den Vibe-Coding-zu-Produktion-Weg durchlaufen haben, sollte das als genau die Infrastruktur-Entscheidung registriert werden, die ihr bereits manuell getroffen habt. Vibe Coding, For Real ist wo ich genau auf diesen Tradeoff eingegangen bin, den wo "wer besitzt die Runtime" aufhört, theoretisch zu sein.

Die 5 Teile, die niemand umbenannte

Sobald ihr das Gehirn-und-Hände-Framework akzeptiert, ergibt sich der Rest der Ähnlichkeit daraus. Beide Plattformen liefern 5 Komponenten aus, oft mit Namen, die kaum verschleierte Übersetzungen voneinander sind.

Ephemere Sandbox. Anthropic stellt einen frischen Linux-Container pro Session bereit, mountet Dateien in /workspace und stellt bash, Dateioperationen und Web-Browsing als native Tools zur Verfügung. Google macht dasselbe: eine Linux-Sandbox, ein code_execution-Tool, ein google_search-Tool, ein url_context-Tool. Beide standardmäßig auf deny-all Networking. Beide lassen euch Dateien aus Cloud-Storage mounten oder ein Git-Repo beim Start klonen.

Stateful Sessions mit Checkpointing. Anthropic bewahrt das Dateisystem des Containers, installierte Pakete und Conversation-History über Verbindungsabbrüche hinweg auf und behält Checkpoints für 30 Tage Inaktivität. Google macht dasselbe über die Interactions API: gebt eine previous_interaction_id weiter und der Server rekonstruiert den gesamten vorherigen Kontext. Beide nennen das "stateful" Execution. Beide haben ihre ursprünglichen stateless APIs als agentic primitive aufgegeben.

Das Wire-Protokoll: MCP. Beide Produkte konvergierten auf das Model Context Protocol (der Standard, den Anthropic Ende 2024 open-sourcte) als Weg für Agenten, mit externen Systemen zu kommunizieren. Beide stellen einen Vault für Credentials zur Verfügung, sodass API-Keys nie in euren Agent-Prompts oder eurem Code erscheinen. Beide injizieren Credentials an der Network-Egress-Grenze. Google fügte "MCP Tunnels" für outbound-only private Netzwerkzugriff im Mai 2026 hinzu. Anthropic lieferte dieselbe Fähigkeit unter demselben Namen im selben Monat aus. Falls ihr darüber nachgedacht habt, warum CLIs immer noch managed MCP für bestimmte Workloads übertreffen, ändert diese Konvergenz direkt diese Kalkulation.

Die Orchestrierungs-Schicht. Multi-Agent-Orchestrierung wechselte von "Third-Party-Framework, das ihr anschraubt" zu "native API-Feature" in beiden Ökosystemen fast zur exakt gleichen Zeit. Anthropics Version: ein lead_agent deklariert ein Roster von Sub-Agenten und synthetisiert deren parallele Outputs. Googles Version: Antigravitys Shared Agent Harness instantiiert parallele Sub-Agenten aus einem einzigen Projekt. Beide kannibalisieren LangGraphs, CrewAIs und LlamaIndex' Existenzberechtigung.

Evaluator- und Memory-Schichten. Anthropic liefert "Outcomes" aus: ein zweites LLM, das Agent-Output gegen eine Rubrik bewertet und loopt, bis es besteht. Google liefert Lifecycle-Hooks (post_tool_call, post_turn) aus, die im Wesentlichen dieselbe Rolle spielen, deterministische Checkpoints innerhalb einer probabilistischen Schleife. Anthropic liefert "Dreaming" für Langzeit-Memory-Konsolidierung zwischen Sessions aus. Google liefert automatische Kontext-Kompaktierung bei etwa 135K Token mit Beibehaltung von "kritischen Zustandsvariablen" aus. Unterschiedliche Mechanismen, derselbe Job: verhindert, dass der Agent sich selbst vergisst und selbstbewusst Müll abliefert. (Opus performt übrigens merklich besser als Sonnet bei den Evaluator-Loops. Berücksichtigt das in eurem Model-Routing, bevor ihr euch auf ein Tier festlegt.)

Die 3-Achsen-Abrechnungs-Falle

Die meisten Builder springen direkt zu den Sandbox-Docs. Die Abrechnungsseite ist wo sich die Architektur offenbart.

Vorher: beide Plattformen verwendeten einfache Pro-Million-Token-Preise. Ihr konntet eure monatliche Rechnung auf einer Serviette schätzen. Euer FinOps-Team war relativ entspannt.

Nachher: beide Unternehmen gaben Token-only-Abrechnung zum exakt gleichen Moment auf und beide ersetzten sie durch 3 simultane Zähler:

• Verbrauchte Token (Input und Output, mit aggressiven Cache-Rabatten auf wiederholten Kontext)
• Aktive Runtime-Sekunden: Anthropic rechnet etwa $0.08 pro Stunde Container-Zeit ab, während status = running. Google rechnet Container-Stunden im Wesentlichen genauso über Vertex/AI Studio ab, wobei der Zähler während idle Waits auf User-Input pausiert.
• Spezifische Tool-Aufrufe: Web-Suche abgerechnet mit Bruchteilen eines Cents pro Query, zusätzlich zu allem anderen.

Idle-Zeit ist in beiden Systemen kostenlos. Warten auf eine menschliche Bestätigung ist kostenlos. Die Uhr läuft nur, wenn der Agent aktiv reasont oder ausführt. Das ist eine bedeutsame Verbesserung gegenüber älteren Container-Stunden-Modellen.

Es gibt einen perversen Zweitordnungseffekt, den beide Preisseiten offenbaren, sobald ihr die Mathematik macht: billigere Modelle können mehr kosten. Ein Haiku- oder Flash-Agent, der 5 Iterationen braucht, um zu lösen, was Opus oder Pro in 1 löst, verbrennt am Ende 5x die Runtime-Sekunden, 5x die Tool-Aufrufe und einen nicht-trivialen Bruchteil der Token-Ersparnisse. Das Optimierungsproblem ist nicht mehr "wählt das billigste Modell." Es ist "findet das Modell, dessen Fehlerrate pro Task niedrig genug ist, dass der Runtime-Zähler eure Ersparnisse nicht auffrisst." Keiner der Anbieter hat ein Dashboard, das euch sagt, welches das für eure Workload ist. Ihr findet es auf der Rechnung heraus. 😅

Wo sie tatsächlich divergieren

3 echte Unterschiede. Das sind die, die eure Wahl beeinflussen sollten.

Compliance-Haltung. Anthropics Managed Agents sind explizit nicht für Zero Data Retention oder HIPAA BAA-Abdeckung in ihrer aktuellen Form berechtigt, weil persistente Checkpoints irgendwo leben müssen, und dieses Irgendwo ist Anthropics Storage. Googles Angebot läuft über Vertex AIs bestehende Compliance-Hülle, die durch GCPs Enterprise-Track-Record breiter ist. Falls ihr im Gesundheitswesen, Verteidigung oder regulierter Finanzbranche seid, ist diese Lücke das Einzige, was dieses Quartal zählt.

Die Self-Hosted-Ausstiegsluke. Anthropic erkannte das Compliance-Problem und lieferte self-hosted Sandboxes im Mai 2026 aus: das Gehirn bleibt in ihrer Cloud, die Hände ziehen zu eurer Infrastruktur über Partner wie Cloudflare, Modal, Vercel und Daytona um. Google hat kein Äquivalent ausgeliefert. Falls die Ausführung innerhalb eures Netzwerk-Perimeters nicht verhandelbar ist, gewinnt Anthropic derzeit.

Die Developer-Oberfläche. Google bündelte eine Desktop-App (Antigravity 2.0), die agy CLI und ein Python SDK in ein einziges Ökosystem mit bidirektionaler Synchronisation. Anthropic liefert eine API aus und lässt das Ökosystem die Oberflächen bauen. Ob das ein Feature oder Bug ist, hängt vollständig davon ab, ob ihr eine polierte vendor-owned IDE oder eine flexible API wollt, die ihr in eure eigenen Tools einpackt.

Alles andere: Sandbox-Modell, Abrechnungsachsen, MCP, Multi-Agent, Evals, Memory, Vault, Checkpoints. Dasselbe Produkt.

Warum sie konvergierten

Das ist kein Zufall. Es ist die natürliche Form des Problems, und das Verstehen dieser Form macht euch zu weniger naiven Käufern.

Falls ihr ein Foundation-Model-Anbieter 2026 seid, ist das Modell selbst die am leichtesten kommoditisierbare Schicht eures Stacks. Kunden routen Haiku für billige Tasks, Sonnet für mittlere, Opus für schwere, Gemini für multimodal, GPT für was übrig bleibt. Sie benchmarken vierteljährlich und wechseln Routen monatlich.

Das Modell, vermietet ihr. Die Runtime akkumuliert Lock-in mit jedem Tool-Aufruf und Checkpoint. Also machten beide Anbieter das Offensichtliche und griffen zur gleichen Zeit nach der Runtime, mit derselben architektonischen Antwort, weil es wirklich nur 1 architektonische Antwort gibt, die funktioniert.

Eigentlich, lasst es mich anders ausdrücken. Die Runtime-Dynamik ist das, was Builder am langsamsten verinnerlichen, und es lohnt sich, einen Moment dabei zu verweilen. Sobald euer Kunde seine MCP-Server in euren Vault verdrahtet, seine Credentials in eurem Key-Management-System gespeichert, seine Agent-Prompts gegen eure Sandbox-Semantik geschrieben, seine Audit-Pipeline gegen euer Event-Schema eingerichtet und 30 Tage Checkpoint-State in eurem Storage-Layer akkumuliert hat, hört das Wechseln von Anbietern auf, wie ein Nachmittag Konfigurationsänderungen auszusehen und fängt an, wie eine Cloud-Migration auszusehen: mehrmonatiges Projekt, funktionsübergreifende Abzeichnung, CFO-Beteiligung, das volle Programm.

Der Kollateralschaden ist das Third-Party-Orchestrierungs-Ökosystem. LangChain, LangGraph, LlamaIndex, CrewAI: diese Frameworks existierten, um eine stateless Model-API mit einer stateful Execution-Umgebung zu verkleben, die ihr selbst bereitgestellt habt. Beide Anbieter absorbierten gerade beide Hälften. Die Klebe-Schicht hat nichts mehr zu verkleben.

Bei der Arbeit mit beiden Ökosystemen in den letzten 6 Monaten war das Muster bereits sichtbar darin, wie beide Unternehmen stillschweigend ihre APIs erweiterten, um mehr vom Stack zu absorbieren. Die Managed-Runtime-Ankündigung war weniger eine Überraschung als eine Formalisierung von etwas bereits Laufendem. Die 2-Wochen-Lücke zwischen den Launches war ein Zufall der Release-Kalender. Die zugrundeliegende Entscheidung wurde Monate früher von beiden Teams getroffen, wahrscheinlich unabhängig, nachdem sie auf dasselbe Whiteboard-Problem gestarrt hatten.

(Kleine Abschweifung, die nichts mit Agenten zu tun hat: eine Bäckerei in der Nähe meiner Wohnung wechselte in 3 Jahren zweimal den Besitzer. Jeder neue Besitzer brachte unabhängig dieselbe Espressomaschine und dasselbe Croissant-Rezept mit. Sie hatten nie gesprochen. Manchmal gibt es nur 1 richtige Antwort, und Konvergenz ist einfach, wie es aussieht, wenn 2 separate Teams sie finden.)

4 Dinge, die ihr vor dem Commit tun solltet

Behandelt die Agent-Runtime als das Migrationsrisiko, das sie ist. Architektiert eure Prompts, Tools und MCP-Server portabel. In dem Moment, wo ihr anfangt, vendor-spezifische Event-Typen oder Orchestrierungs-Primitive ohne Analoga auf der anderen Seite zu verwenden, habt ihr eure Exit-Kosten verdoppelt.

Legt nicht eure einzige Kopie wichtiger States in einen Vendor-Checkpoint. Persistiert, was euch wirklich wichtig ist (Outputs, Audit-Trails, Zwischenartefakte) in Storage, das ihr kontrolliert. Behandelt den Session-State des Vendors als Cache, nicht als Source of Truth.

Messt Runtime-Kosten pro Task, nicht pro Token. Die 3-Achsen-Abrechnung macht Token-Kosten zur am wenigsten informativen Zahl auf eurer Rechnung. Taggt jeden Agent-Run mit einem Task-Typ und einer Model-Wahl, dann beobachtet die Runtime-Sekunden- und Tool-Aufruf-Spalten mehr als die Token-Spalte.

Wählt die Seite mit der Compliance-Haltung, die ihr jetzt braucht, nicht die mit der besseren Demo. Die Demos sind austauschbar. Die Compliance-Docs sind es nicht.

Falls ihr noch herausfindet, wie ihr eure Agent-Prompts strukturiert, bevor ihr euch auf eine Managed Runtime festlegt, ist das Prompt-Contracts-Framework, das ich gebaut habe es wert, zuerst gelesen zu werden. Mit einem strukturierten Ansatz zur Prompt-Architektur reinzugehen macht die Evaluation sauberer: ihr wisst genau, was ihr abgebt.

---

Managed Agents, beide Versionen, ist ein genuines gutes Produkt. Der Produktivitätsgewinn ist real und groß. Vorher: Bereitstellung einer sicheren Sandbox, Verdrahtung von Credential-Rotation, Bau einer debugbaren Event-Pipeline. Wochen von Klempnerarbeit. Jetzt ist es 1 API-Aufruf. Schwer zu argumentieren dagegen.

Der Preis: eure Runtime gehört nicht mehr euch. Die Sandbox gehört ihnen, und so ist alles downstream von diesem ersten API-Aufruf (Credentials, Logs, euer Agent-State, der sich in ihren Checkpoints akkumuliert). In ein paar Jahren werdet ihr zurückblicken und denken, das fühlte sich genau wie Lambda 2019 an: ihr machtet dieselbe Kalkulation, und es war wahrscheinlich die richtige.

Also wählt euren Vendor. Aber wählt mit bereits eingepreistem Lock-in. Das Modell könnt ihr jeden Montagmorgen tauschen. Die Runtime ist eine Cloud-Migration, und das macht ihr nicht zwischen 2 Gläsern Saint-Émilion.

Quellen

• Anthropic Managed Agents Public Beta Dokumentation, April 2026
• Google I/O 2026: Project Antigravity und Gemini Managed Agents Ankündigung
• Anthropic Self-Hosted Sandboxes Ankündigung, Mai 2026 (Cloudflare, Modal, Vercel, Daytona Partnerschaften)

Dieser Post könnte Affiliate-Links enthalten. Falls ihr sie anklickt, verdiene ich möglicherweise eine kleine Provision — kostet euch nichts und hilft mir dabei, weiterhin täglich Qualitätsartikel für euer Lesevergnügen zu liefern.