Die Frage kommt in fast jedem Projektgespräch: „Können wir das nicht einfach selbst aufsetzen? Es gibt doch Agentic-AI-Frameworks, die sind Open Source." Die Antwort ist ja — und genau das ist der Anfang des Problems, nicht das Ende. Ein Framework für Durable Execution oder Orchestrierung zu installieren dauert einen Tag. Daraus eine Plattform zu machen, die produktiv Schreibzugriffe ausführt, dauert Monate — und hört danach nicht auf.
Dieser Artikel ist der siebte einer Serie zu Agentic-AI-Infrastruktur. Er beantwortet die Frage, die am Ende jeder technischen Diskussion steht: Was kostet der Eigenbau wirklich, im Vergleich zu einer Managed Agent Platform — und wann ist er trotzdem die richtige Entscheidung?
Vorab: Dieser Artikel vergleicht Bauweisen, keine Firmen. Wo Werkzeugkategorien genannt werden — eine Workflow-Engine im Temporal-Stil, ein Graph-Framework im LangGraph-Stil, ein OpenTelemetry-Collector —, geht es um die Funktion, die diese Kategorie erfüllt, nicht um eine Kaufempfehlung für ein bestimmtes Produkt.
Was „ein Agenten-Framework einführen" tatsächlich bedeutet
Ein Agent, der eine Aufgabe zuverlässig zu Ende bringt, braucht mehr als ein Sprachmodell mit Tool-Zugriff. In der Praxis entstehen mindestens sechs eigenständige Bausteine, sobald ein Agent produktiv wird:
- Durable-Execution-Layer: Eine Workflow-Engine im Stil bekannter Open-Source-Projekte für langlaufende, zustandsbehaftete Prozesse — sie merkt sich, wo ein Lauf stand, wenn ein Prozess abstürzt, ein LLM-Aufruf timeoutet oder ein externes System nicht antwortet. Ohne sie beginnt jeder Fehler wieder bei Schritt eins. Warum dieser Baustein bei Agenten so viel wichtiger ist als bei klassischen Batch-Jobs, erklärt der erste Artikel dieser Serie, Durable Execution für KI-Agenten.
- Orchestrierungsschicht: Ein Graph-Framework im Stil verbreiteter Agenten-Bibliotheken, das Abläufe zwischen mehreren Agenten oder Teilschritten als gerichteten Graphen modelliert — mit Verzweigungen, Wiederholungen und Abbruchbedingungen.
- Tool-Gateway mit Policy Engine: Die Schicht, über die jeder MCP-Server-Aufruf läuft — Schema-Validierung in beide Richtungen, Rate-Limits, ein Policy-Entscheid pro Aufruf und ein sanitisiertes Audit-Log. Das ist nach unserer Erfahrung der aufwendigste Teil des gesamten Vorhabens.
- Trace-Pipeline: Ein OpenTelemetry-Collector oder vergleichbares Werkzeug, das jeden Denkschritt, Tool-Aufruf und jede Zwischenantwort protokolliert — und ein Backend, das diese Traces durchsuchbar und über Läufe hinweg vergleichbar macht.
- Eval-Harness: Ein Testrahmen, der bei jedem Deployment prüft, ob der Agent auf einem festen Satz von Aufgaben noch die erwartete Qualität liefert — ohne den merkt man Regressionen erst beim Kunden.
- Rufbereitschaft: Ein Mensch, der erreichbar ist, wenn ein Lauf mit Schreibrechten in einer Schleife hängt oder ein Tool-Aufruf unerwartet reagiert. Kein Softwareprodukt, aber der teuerste Baustein im laufenden Betrieb.
Jeder dieser sechs Bausteine existiert einzeln als ausgereiftes Werkzeug. Was fehlt, ist die Integration zwischen ihnen — und genau die Integration ist die eigentliche Arbeit. Details zur Trace-Pipeline und zum Gateway haben wir in den Artikeln zu Observability für KI-Agenten und MCP in Produktion vertieft; hier geht es um die Gesamtrechnung.
Rechenbeispiel: Personentage für den Aufbau
Die folgende Aufstellung ist ein Rechenbeispiel auf Basis von Erfahrungswerten aus Projekten mit mittelständischen Kunden — keine Zusicherung und kein Angebot. Sie unterstellt ein Team mit soliden Grundkenntnissen in verteilten Systemen, aber ohne tiefe Vorerfahrung mit Durable-Execution-Frameworks.
| Baustein | Personentage (Annahme) | Größte Unsicherheit |
|---|---|---|
| Durable-Execution-Layer aufsetzen und betreiben | 10–18 | Cluster-Betrieb, Versionierung von Workflows |
| Orchestrierung / Graph-Logik für 1–2 Agenten | 8–15 | Fachliche Modellierung der Abläufe |
| Tool-Gateway mit Policy Engine | 15–30 | Schema-Validierung, Rate-Limits, Audit-Log robust genug für Produktion |
| Agent-Identity / Least-Privilege-Modell | 8–15 | Kurzlebige Credentials je Lauf, Bindung an Zielsysteme |
| Trace-Pipeline inkl. Backend | 8–12 | Aufbewahrungsdauer, Suchbarkeit über viele Läufe |
| Eval-Harness | 6–10 | Repräsentative Testfälle definieren |
| Integration, Tests, Dokumentation | 10–20 | Wird in der Praxis fast immer unterschätzt |
| Summe (Annahme) | 65–120 |
Bei einem internen Tagessatz von 700 bis 900 Euro (Vollkosten, nicht Gehalt) entspricht das einer Investition von grob 45.000 bis 108.000 Euro, bevor der erste Agent produktiv einen einzigen Vorgang abschließt. Das ist der Teil, der in Entscheidungsvorlagen meist fehlt — weil er auf „wir nehmen das bestehende Backend-Team dazu" wegdefiniert wird.
Rechenbeispiel: laufender Betriebsaufwand
Der Aufbau ist die sichtbare Kostenstelle. Der laufende Betrieb ist die, die in Business Cases regelmäßig fehlt. Auch hier: Annahme, kein Preis.
| Position | Monatlicher Aufwand (Annahme) |
|---|---|
| Infrastruktur (Workflow-Engine-Cluster, Datenbank, Observability-Stack) | 400–1.200 € |
| Patches, Versions-Upgrades, Sicherheitsfixes | 1–2 Personentage |
| Gateway- und Policy-Pflege bei neuen Tools | 1–3 Personentage |
| Trace-Auswertung, Eval-Läufe nach jedem Deployment | 1–2 Personentage |
| Rufbereitschaft (anteilig, nicht exklusiv) | 1–2 Personentage |
| Summe Personentage/Monat (Annahme) | 4–9 |
Bei denselben Tagessätzen sind das grob 2.800 bis 8.100 Euro Personalkosten pro Monat, plus Infrastruktur — noch bevor ein zweiter oder dritter Agent hinzukommt. Zur Einordnung: Unsere Betriebspauschalen für die Agent Runtime liegen bei 690, 1.490 oder ab 3.900 Euro pro Monat zzgl. USt. (je nach Umfang), dazu nutzungsabhängige Komponenten je Lauf, je Tool-Aufruf und je Million Token — Letztere sind aktuell noch Platzhalter und nur als Rechenbeispiel zu verstehen, keine Preisliste. Details dazu stehen auf der Preisseite.
Ehrlich: Bei einem einzigen produktiven Agenten mit überschaubarem Tool-Katalog schneidet der Eigenbau selten günstiger ab als die mittlere Betriebspauschale — selbst wenn man die Aufbaukosten über drei Jahre abschreibt. Der Vorteil des Eigenbaus liegt nicht im Preis, sondern in Kontrolle und Anpassbarkeit.
Das Wissensrisiko: ein Kopf, eine Plattform
In der Praxis baut in mittelständischen Unternehmen selten ein Team die Agenten-Plattform, sondern eine einzelne, überdurchschnittlich motivierte Person — oft neben dem eigentlichen Tagesgeschäft. Das funktioniert, solange diese Person da ist. Die eigentliche Frage ist eine andere: Was passiert, wenn sie krank wird, kündigt oder für drei Wochen in Elternzeit geht?
Gateway-Policy-Logik, Retry-Strategien für bestimmte Fehlerklassen, die Konvention, wie Traces benannt werden, die Gründe, warum ein bestimmter Workflow-Parameter genau diesen Wert hat — all das steht selten in einem Wiki, sondern im Kopf einer Person. Fällt dieser Kopf aus, steht nicht die Technik still, sondern das Verständnis dafür, warum sie so gebaut ist, wie sie gebaut ist. Reparaturen werden dann zu Archäologie.
Das ist kein Totschlagargument gegen Eigenbau — größere Unternehmen mit einem echten Plattformteam haben dieses Risiko strukturell gelöst. Für die meisten Mittelständler mit 50 bis 500 Mitarbeitenden ist es aber der Punkt, der in der Kalkulation am häufigsten fehlt, weil er sich nicht in Personentagen ausdrücken lässt.
Praxisbeispiel: zwei Wege zum selben Ziel
Nehmen wir ein realistisches Szenario, wie es in Gesprächen häufig vorkommt: Ein Fertigungsbetrieb mit 180 Mitarbeitenden will einen Agenten für die automatisierte Vorprüfung eingehender Rechnungen einführen, angebunden an ERP und Dokumentenmanagement, mit einem Genehmigungsschritt für Beträge über 2.000 Euro.
Weg 1, Eigenbau: Ein Entwickler aus dem IT-Team richtet in Woche 1–2 eine Workflow-Engine ein, in Woche 3–5 folgen Gateway und Policy-Regeln für ERP- und DMS-Zugriff, in Woche 6–7 die Trace-Pipeline, in Woche 8 erste Tests. Nach rund zwei Monaten läuft ein Prototyp. Bis zur Produktionsreife mit Monitoring, Eval-Harness und Rufbereitschaftsregel vergehen erfahrungsgemäß weitere sechs bis zehn Wochen — macht in Summe drei bis fünf Monate, je nach Auslastung des Entwicklers durch das übrige Tagesgeschäft.
Weg 2, Managed Runtime: Durable Execution, Gateway und Tracing kommen fertig aus der Plattform. Das Fertigungsunternehmen definiert Agent und Policy-Regeln für die konkreten ERP-/DMS-Zugriffe; Integration und erste Testläufe dauern zwei bis vier Wochen. Details zur technischen Architektur dahinter stehen auf der Architektur-Seite.
Der Unterschied liegt nicht darin, dass Weg 1 „schlechter" wäre — die entstehende Lösung kann technisch gleichwertig sein. Der Unterschied ist die Zeit bis zum ersten produktiven Nutzen und die Frage, wer in Monat 14 den Patch für eine neue Sicherheitslücke im Workflow-Framework einspielt. Eine durchgerechnete Kostenperspektive für genau diesen Use Case liefert der Artikel zur Kosten je erfolgreichem Task.
Ein Detail aus diesem Beispiel wird in der Praxis oft zur eigentlichen Nagelprobe: Was passiert, wenn der Agent bei einer Rechnung über 2.000 Euro unsicher ist, ob die Kostenstelle korrekt zugeordnet wurde? Beim Eigenbau muss das Genehmigungs- und Eskalationsverhalten — wer wird benachrichtigt, über welchen Kanal, mit welcher Frist, bevor automatisch eskaliert wird — komplett selbst konzipiert und getestet werden. Bei einer Managed Runtime ist dieses Muster meist als konfigurierbarer Baustein vorhanden, weil es in praktisch jedem Anwendungsfall mit Schreibrechten wiederkehrt. Wie ein solches Freigabemodell sauber aufgesetzt wird, vertieft der Artikel Human-in-the-Loop: Freigaben und Limits.
Eigenbau, Managed, Hyperscaler, Agent-SaaS im Vergleich
Vier grundsätzlich unterschiedliche Bauweisen stehen zur Wahl. Keine ist per se falsch — die Achsen entscheiden, welche zur eigenen Situation passt.
| Achse | Eigenbau | Managed Runtime | Hyperscaler-Dienst | Agent-SaaS |
|---|---|---|---|---|
| Kontrolle | Vollständig | Hoch, innerhalb der Bauform des Anbieters | Mittel, an Plattform-API gebunden | Gering, fertige Bausteine |
| Datenresidenz | Vollständig selbst bestimmbar | Deutsches Rechenzentrum vertraglich zusicherbar | Abhängig vom Hyperscaler-Standort, oft außerhalb der EU | Abhängig vom Anbieter, häufig außerhalb der EU |
| Time-to-Value | 3–6 Monate | 2–4 Wochen | Wenige Tage bis Wochen | Wenige Tage |
| Laufender Aufwand | Hoch, dauerhaft eigenes Personal | Gering, Betrieb liegt beim Anbieter | Mittel, API-Pflege und Kostenkontrolle | Gering, aber wenig Einfluss auf Änderungen |
| Exit | Uneingeschränkt, alles ist eigen | Vertraglich zugesicherter Export der Artefakte | Aufwendig, tiefe API-Kopplung | Meist am schwierigsten, proprietäre Formate |
Ein Hyperscaler-Agentendienst punktet bei Reichweite und Integration in ein bestehendes Cloud-Ökosystem, bringt aber häufig eine Datenresidenz außerhalb der EU und AGB mit, die sich schwer verhandeln lassen. Agent-SaaS ist am schnellsten startklar, tauscht dafür aber Kontrolle über Daten und Tool-Zugriffe gegen Geschwindigkeit — mehr dazu im Vergleich zu Hyperscaler-Diensten und zu Agent-SaaS.
Wann der Eigenbau die bessere Wahl ist
Es gibt drei Situationen, in denen wir vom Eigenbau nicht abraten würden — im Gegenteil:
- Ein eigenes Plattformteam existiert bereits. Wenn Rufbereitschaft, Deployment-Pipelines und ein Trace-Backend ohnehin betrieben werden, ist eine Agenten-Runtime ein weiteres System auf funktionierendem Fundament — der Grenzaufwand ist deutlich niedriger als bei einem Team, das bei null anfängt.
- Agenten sind das eigene Kernprodukt. Wer KI-Agenten nicht intern nutzt, sondern selbst als Produkt verkaufen will, muss die Fähigkeit zwangsläufig aufbauen — ein Dienstleister wäre hier ein Umweg, nicht eine Abkürzung.
- Die Anforderungen weichen strukturell ab. Extreme Latenzvorgaben, ein bestehendes Workflow-System mit eigener Semantik oder regulatorische Vorgaben, die keine Standardlösung erfüllt — hier kostet jede Plattform, auch eine gemietete, mehr Anpassung als der native Aufbau.
In allen drei Fällen ist die Entscheidung keine Preisfrage, sondern eine Frage der strategischen Ausrichtung: Wird die Fähigkeit „Agenten betreiben" Teil dessen, was das Unternehmen ausmacht — oder ist sie ein Werkzeug für einen bestimmten Zweck?
Wann sich das nicht lohnt / Grenzen
Umgekehrt gibt es klare Signale, dass der Eigenbau in der jetzigen Situation die falsche Wahl wäre:
- Ein einzelner Agent, ein überschaubarer Tool-Katalog. Für einen produktiven Anwendungsfall lohnt sich der Aufbau eines vollständigen Sechs-Bausteine-Stacks in den seltensten Fällen — die Fixkosten des Fundaments übersteigen den Nutzen des einen Agenten.
- Keine dedizierte Betriebsverantwortung. Wenn niemand explizit für Rufbereitschaft, Patches und Trace-Auswertung eingeplant ist, wird die Plattform faktisch von niemandem betrieben — bis sie ausfällt.
- Ein einziger Kenner im Haus. Siehe oben — das Wissensrisiko ist real und wird in Entscheidungsvorlagen fast nie mit einem Euro-Betrag versehen, obwohl es einer ist.
- Enger Zeitrahmen. Wer in acht Wochen ein Ergebnis zeigen muss, sollte nicht gleichzeitig eine Workflow-Engine produktionsreif machen. Details zum realistischen Zeitplan liefert der Artikel Vom Prototyp in Produktion in 90 Tagen.
Grenzen gelten auch für gemietete Plattformen: Eine Managed Runtime löst das Betriebsproblem, nicht die fachliche Modellierung. Wer nicht weiß, welche Entscheidung ein Agent treffen darf und welche nicht, braucht zuerst diese Klärung — keine Software ersetzt sie.
Die Mischform, die in der Praxis am häufigsten trägt
Ein reiner Alles-oder-nichts-Vergleich wird der Realität selten gerecht. In den meisten Projekten, die wir begleiten, entsteht eine Aufteilung: Das Unternehmen baut die Agenten, Prompts und Graphen selbst — das ist der fachlich wertvolle Teil mit Domänenwissen, den niemand von außen besser kennt. Die Betriebsschicht darunter — Durable Execution, Tool-Gateway, Traces, Rufbereitschaft — kommt von einem Dienstleister.
In der Praxis: Diese Aufteilung ist keine Kompromisslösung, sondern meist die wirtschaftlich sinnvollste. Die Fachlogik bleibt Eigentum des Unternehmens, das Betriebsrisiko liegt extern — und die eigene IT-Mannschaft muss nicht nebenbei zur Plattform-Truppe werden.
Diese Aufteilung lässt sich unterschiedlich weit fassen. Wer nur die Agenten-Runtime extern haben möchte, bleibt bei der Betriebspauschale ab 690 Euro pro Monat. Wer die komplette KI-Betriebsverantwortung — Modelle, Agenten, Infrastruktur — abgeben will, findet das in unserem Angebot KI Managed Services. Und wer aus regulatorischen oder Datenschutzgründen keine Verarbeitung außerhalb der eigenen Räume will, prüft KI on-Premise als dritte Variante — mit denselben Bausteinen, aber auf eigener Hardware im eigenen Rechenzentrum betrieben. Einen vollständigen Überblick über alle Bausteine von Basis-Infrastruktur bis Anwendungsebene liefert KI Full-Stack Providing.
Die Lock-in-Frage ehrlich beantwortet
Wer eine Managed Runtime mietet, gibt zwangsläufig einen Teil der Kontrolle ab. Die entscheidende Frage ist nicht, ob das passiert, sondern was im Ernstfall möglich ist. Drei Kriterien sind dafür relevant:
- Export der Artefakte: Lassen sich Agenten-Definitionen, Policy-Konfigurationen und Traces in offenen Formaten exportieren — oder liegen sie in einem proprietären Binärformat, das nur der Anbieter lesen kann?
- Standardkomponenten unter der Haube: Läuft die Runtime auf austauschbaren Open-Source-Bausteinen oder auf einer komplett geschlossenen Eigenentwicklung? Ersteres macht einen späteren Eigenbetrieb realistisch, Letzteres praktisch nicht.
- Vertragliche Zusicherung: Steht der Exit-Anspruch im Vertrag oder nur in der Marketing-Broschüre? Details zu unserer Zusicherung stehen auf der Trust-Seite.
Ehrlich: Auch bei bester vertraglicher Absicherung ist ein Wechsel nie kostenlos — Migrationsaufwand entsteht immer. Der Unterschied zwischen einem seriösen Anbieter und einem Lock-in-Anbieter ist, ob dieser Aufwand aufwendig, aber machbar ist, oder faktisch unmöglich. Einen Überblick über alle Schichten der Runtime bietet die interaktive Systemkarte auf der Agentic-AI-Übersicht.
Einordnung: Regulatorik verändert die Rechnung nicht grundsätzlich
Ob Eigenbau oder Managed Runtime — die regulatorischen Pflichten bleiben gleich. Nach dem Digital Omnibus vom Mai 2026 gelten die Verbote des EU AI Act seit dem 02.02.2025, die Pflichten für GPAI-Modelle seit dem 02.08.2025; die Hochrisiko-Pflichten wurden auf den 02.12.2027 beziehungsweise 02.08.2028 verschoben. Wer DSGVO-relevante Daten verarbeitet, muss unabhängig von der Bauweise ein Verzeichnis der Verarbeitungstätigkeiten führen und Auftragsverarbeitung sauber regeln. Eigenbau verschiebt diese Pflicht nicht auf einen Anbieter — sie bleibt beim Unternehmen, das den Agenten betreibt.
Ausführlich behandelt der Artikel EU AI Act und DSGVO für KI-Agenten diese Fragen. Für die Bauentscheidung selbst gilt: Eine gute ISO-27001-Basis und dokumentierte Prozesse erleichtern beide Wege, ersetzen aber keine der beiden Entscheidungen.
Ein Nebeneffekt des Eigenbaus wird in Business Cases regelmäßig übersehen: Wenn die offizielle Agenten-Plattform Monate braucht, bauen einzelne Fachabteilungen in der Zwischenzeit oft eigene, ungenehmigte Lösungen mit frei zugänglichen KI-Werkzeugen — Schatten-KI. Das Risiko ist real und unabhängig davon, ob am Ende Eigenbau oder Managed Runtime gewählt wird; wie man dem begegnet, beschreibt der Artikel KI-Agenten-Sicherheit und Schatten-KI. Wie sich Agenten-Infrastruktur insgesamt in eine bestehende IT-Systemlandschaft einfügt, behandelt Agentic AI und Systemintegration.
Häufige Fragen
Was baut man wirklich, wenn man „nur ein Agenten-Framework" einführt?
Mindestens sechs Bausteine: einen Durable-Execution-Layer für Zustand und Retries, ein Orchestrierungs-Framework, ein Tool-Gateway mit Policy-Entscheid, eine Trace-Pipeline, eine Eval-Harness und eine Rufbereitschaft, die das alles nachts trägt. Das Framework selbst ist der kleinste Teil der Arbeit.
Wie viele Personentage kostet der Eigenbau einer Agenten-Plattform?
Rechenbeispiel aus Projekterfahrung: 60 bis 120 Personentage für ein produktionsreifes Fundament mit ein bis zwei produktiven Agenten, verteilt über drei bis sechs Monate. Ohne Vorerfahrung mit Durable Execution und Observability ist eher die obere Hälfte bis das Doppelte realistisch.
Was kostet der laufende Betrieb einer selbst gebauten Agenten-Plattform?
Rechenbeispiel: 400 bis 1.200 Euro Infrastruktur pro Monat, dazu 3 bis 8 Personentage für Pflege und Rufbereitschaft — bei Vollkostenrechnung schnell 3.000 bis 8.000 Euro monatlich, ohne dass ein zusätzlicher Agent produktiver arbeitet.
Wann ist der Eigenbau einer Agenten-Plattform die bessere Wahl?
Wenn ein Plattformteam mit Betriebsverantwortung bereits existiert, wenn Agenten das eigene Kernprodukt werden sollen, oder wenn die Anforderungen strukturell von Standardlösungen abweichen.
Was ist das größte unterschätzte Risiko beim Eigenbau?
Das Wissensrisiko: In den meisten Mittelstandsprojekten baut eine einzelne Person die Plattform auf. Fällt sie aus, steht der Betrieb, weil Policy-Logik und Konventionen nirgends dokumentiert sind außer in ihrem Kopf.
Was unterscheidet Eigenbau, Managed Runtime, Hyperscaler-Dienst und Agent-SaaS?
Eigenbau bietet maximale Kontrolle bei maximalem Aufwand. Ein Hyperscaler-Dienst ist schnell nutzbar, bindet aber technisch und oft datenschutzrechtlich. Agent-SaaS ist am schnellsten startklar bei geringster Kontrolle. Eine Managed Runtime liegt dazwischen: volle Kontrolle über Agenten und Daten, Betrieb extern, mit zugesichertem Exit.
Lohnt sich eine Mischform aus Eigenbau und Managed Runtime?
Ja — das Unternehmen baut Agenten und Graphen selbst, die Betriebsschicht kommt vom Dienstleister. Das ist die Aufteilung, die wir am häufigsten empfehlen.
Was bedeutet Lock-in bei einer gemieteten Agenten-Plattform konkret?
Entscheidend ist, ob Agenten-Definitionen, Konfigurationen und Traces in offenen Formaten exportierbar sind und ob die Runtime auf Standardkomponenten läuft. Ein seriöser Anbieter sichert den Export vertraglich zu.