Managed vs. selbst gehostete Agent-Runtime: Die echten Kompromisse

Eine Managed Agent Runtime ist ein vom Anbieter betriebener Dienst, der den Loop Ihres AI-Agenten für Sie ausführt: Sie schreiben die Prompts und Tool-Definitionen, der Anbieter übernimmt Orchestrierung, Retries und Skalierung. Beim Selbst-Hosting betreiben Sie diesen Loop eigenständig. Die richtige Wahl hängt weniger von den Kosten ab als davon, wer Zugriff auf Ihre Daten benötigt und wie viel Kontrolle Sie über das Fehlerverhalten brauchen.

Die meisten Gründer denken überhaupt nicht über die Runtime nach – bis etwas schiefläuft: Ein Tool Call hängt, ein Retry-Sturm verdreifacht über Nacht die LLM-Rechnung, oder ein Kunde fragt, wo seine Gesprächsprotokolle gespeichert werden. Das ist meist der erste Moment, in dem „Managed vs. Self-Hosted" zur echten Entscheidung wird und nicht mehr nur zum Standard.

Was die Runtime tatsächlich leistet

Abseits des Marketings übernimmt eine Agent-Runtime vier Aufgaben:

• State-Management zwischen den Schritten, damit der Agent weiß, was er bereits versucht hat
• Tool-Execution, also das Aufrufen Ihrer APIs, Datenbanken oder externer Dienste
• Retry- und Timeout-Logik, wenn ein Schritt fehlschlägt oder hängt
• Observability, also das Protokollieren, was der Agent getan hat und warum

Eine Managed-Plattform (LangGraph Cloud, das gehostete Angebot von CrewAI, verschiedene vertikale Agenten-Plattformen) liefert alle vier Punkte direkt mit, üblicherweise inklusive Dashboard. Beim Selbst-Hosting konfigurieren oder bauen Sie jede dieser Komponenten selbst – häufig auf Basis einer Queue (SQS, Redis) und eines Worker-Prozesses, den Sie kontrollieren.

Worauf Sie in jedem Fall verzichten

Bei einer Managed Runtime verzichten Sie auf:

• Einblick in die genaue Implementierung von Retries und Timeouts – relevant, wenn ein Agent stillschweigend eine nicht-idempotente Aktion wiederholt (eine Karte zweimal belastet, eine doppelte WhatsApp-Nachricht sendet)
• Garantien zur Datenhaltung, da Prompts und Tool-Outputs in der Regel über die Server des Anbieters laufen – ein echtes Problem für Kunden im Gesundheitswesen oder der öffentlichen Verwaltung, die eine Verarbeitung innerhalb der Region voraussetzen
• Kalkulierbare Preise, denn die meisten Anbieter berechnen pro Ausführung oder pro weitergereichtem Token zusätzlich zu Ihrer LLM-Rechnung

Beim Selbst-Hosting verzichten Sie auf:

• Zeit. Zuverlässige Retry-Logik, Dead-Letter-Handling und Observability auf Step-Ebene zu bauen ist ein mehrwöchiges Projekt, kein Konfigurations-Flag
• Das SLA des Anbieters. Wenn Ihr Worker-Prozess um 2 Uhr nachts abstürzt, liegt der Bereitschaftsdienst bei Ihnen
• Fertige Debugging-Tools. Anbieter liefern Step-by-Step-Replay-UIs mit, deren Nachbau echten Aufwand bedeutet

Keine Seite ist kostenlos. Die Frage ist, welche Kosten Sie gerade tragen können.

Wo es Gründer in der Praxis trifft

Den Kompromiss sehen wir am deutlichsten in Ausführungsmustern von Agenten – nicht nur in der Hosting-Entscheidung. Als wir unsere eigene Outreach-Engine gebaut haben, kettete die erste Version mehrere LLM-Aufrufe aneinander: einen zum Extrahieren von Informationen über einen Prospect, einen zweiten zum Verfassen der E-Mail, einen dritten zur Ton-Verfeinerung. Diese Kette über eine Managed-Orchestrierungsschicht laufen zu lassen funktionierte, aber jeder zusätzliche Hop erhöhte die Latenz und schuf einen weiteren Punkt, an dem ein hängender Tool Call eine blockierte Workflow-Instanz erzeugen konnte, die das Dashboard nicht klar erklärte. Den Vorgang in einen einzigen Aufruf zu konsolidieren – der über eine selbst gehostete Firecrawl-Instanz sowohl Fakten extrahierte als auch die E-Mail in einem Durchgang verfasste – senkte sowohl Kosten als auch die Fehleranfälligkeit, weil schlicht weniger Runtime-State zu verwalten war und weniger Transparenz verloren gehen konnte. Die Lehre lässt sich verallgemeinern: Je weniger bewegliche Teile der Loop Ihres Agenten hat, desto weniger spielt es eine Rolle, ob Sie managed oder self-hosted unterwegs sind – und desto mehr spielt es eine Rolle, sobald Ihr Workflow über zwei oder drei Schritte hinauswächst. Das ist eine Variante desselben Kompromisses, der in Single-Call vs. Agent Chains behandelt wird.

Serverless-Self-Hosting hat seine eigene Falle: Wenn die Tool Calls Ihres Agenten lang laufen können (Warten auf eine langsame Dritt-API, das Parsen eines Dokuments, eine menschliche Freigabe), setzt eine Plattform wie AWS Lambda ein hartes Ausführungslimit von 15 Minuten pro Invocation durch – gemäß AWS-Dokumentation. Teams, die das nicht vorab prüfen, stellen es fest, wenn ein Agenten-Workflow, der im Testing einwandfrei lief, in der Produktion unter realen API-Latenzen stillschweigend abbricht.

Ein grober Entscheidungsrahmen

Wählen Sie Managed, wenn:

• Sie gerade validieren, ob der Agent-Use-Case überhaupt funktioniert, bevor Sie Engineering-Zeit einsetzen
• Die verarbeiteten Daten weder reguliert noch kundensensitiv sind
• Sie noch niemanden haben, der Verantwortung für Infrastruktur-Zuverlässigkeit übernimmt

Wählen Sie Self-Hosted, wenn:

• Der Agent Patientenakten, Finanzdaten oder alles berührt, für das Anforderungen an den Datenhaltungsort gelten – ähnlich wie wir empfehlen, ein LLM selbst zu hosten statt eine API zu nutzen, sobald Compliance ins Spiel kommt
• Sie genug Volumen fahren, dass Gebühren pro Ausführung eine echte Kostenposition sind und keine Rundungsdifferenz
• Sie benutzerdefinierte Retry-Semantik benötigen, weil manche Ihrer Tool Calls nicht blind wiederholt werden dürfen (Zahlungen, ausgehende Nachrichten, Datenbankschreibvorgänge)

In jedem Fall sollten Sie die Logik Ihres Agenten (Prompts, Tool-Schemata, State-Definitionen) von der spezifischen SDK-Implementierung der Runtime entkoppeln. Wenn jede Tool-Funktion direkt eine anbieterspezifische Orchestrierungs-API aufruft, bedeutet eine spätere Migration ein Neuschreiben des Agenten – kein reines Redeployment. Das ist dieselbe Due-Diligence-Frage, die wir in unserer Checkliste zur Bewertung von Agent-Anbietern durchgehen: Fragen Sie den Anbieter von Anfang an, was mit Ihrer Logik passiert, wenn Sie wechseln.

Die Wartungskosten, die niemand vorab nennt

Egal, wofür Sie sich entscheiden: Kalkulieren Sie laufende Wartung ein, nicht nur den initialen Aufbau. Managed Runtimes erfordern trotzdem jemanden, der die Kosten pro Ausführung im Blick behält und Prompts aktualisiert, wenn sich Ihr Produkt verändert. Selbst gehostete Runtimes erfordern jemanden, der die Worker-Infrastruktur patcht und Incidents bearbeitet. Was diese laufenden Kosten typischerweise bedeuten, schlüsseln wir in AI-Agent-Wartungskosten auf – auf keinem der beiden Wege sind sie null.

Wenn Sie diese Entscheidung für ein konkretes Produkt abwägen und eine zweite Meinung dazu möchten, wo die Grenze für Ihre Daten und Ihr Volumen liegen sollte, sprechen Sie uns an.