Welche Infrastruktur brauchen Sie, um KI-Agenten in Produktion zu bringen?

Die meisten Teams unterschätzen, was zwischen einem funktionierenden Prototyp und einem produktiven Agenten steht. Hier ist der Stack – Schicht für Schicht – und was jede Komponente wirklich tut.

Für CTOs, VP Engineering und IT-Verantwortliche · 14 Min. Lesezeit

Die Lücke zwischen Prototyp und Produktion

Ein KI-Agent, der in einem Notebook oder Demo-Umfeld funktioniert, braucht im Wesentlichen nur eines: ein LLM und ein paar Tool-Definitionen. Das reicht, um einen Raum zu beeindrucken.

Ein KI-Agent in Produktion braucht deutlich mehr. Nicht, weil der KI-Teil schwieriger wäre – ist er nicht –, sondern weil die Produktion Anforderungen mitbringt, die nichts mit dem Modell zu tun haben: Parallelität, Zustandsverwaltung, Fehlerbehandlung, Kostenkontrolle, Sicherheit, Compliance und Auditierbarkeit.

Zur Komplexität der Infrastruktur

Entwickler finden sich häufig dabei wieder, sechs oder sieben separate Services zusammenzustecken, nur um einen einfachen produktiven Agenten zum Laufen zu bringen: eine Vektordatenbank für Speicher, Objektspeicher für Dateien, einen Server für Tool-Ausführung, eine Orchestrierungsschicht, ein Queuesystem, Monitoring und ein Gateway. Das Stack-Problem ist real – und der Grund, warum viele Agenten nie über die Pilotphase hinauskommen.

Dieser Artikel kartiert den vollständigen Infrastrukturs-Stack, der für einen KI-Agenten in Produktion nötig ist, erklärt, was jede Schicht tut und warum sie wichtig ist, und beleuchtet die praktischen Trade-offs zwischen Eigenbau und Nutzung einer gemanagten Plattform.

Die fünf Infrastrukturschichten

Ein produktiver KI-Agent sitzt auf fünf miteinander verknüpften Schichten. Jede kann zum Engpass werden. Keine ist optional.

1. Modelle & Routing
2. Orchestrierung
3. Speicher & Daten
4. Serving & Skalierung
5. Governance & Observability

1. Modelle & Routing

Aufgabe
Zugriff auf ein oder mehrere LLMs bereitstellen und Anfragen an das passende Modell routen – nach Aufgabentyp, Kosten- oder Latenzanforderungen.

Beispiele: OpenAI GPT-4o, Anthropic Claude, Mistral, Gemini – plus Routinglogik, um zwischen ihnen umzuschalten.

Multi-Modell-Routing

Die Modellwahl ist weniger entscheidend, als viele Teams denken. 2026 liefern GPT-4o, Claude, Mistral und Gemini auf den meisten Enterprise-Aufgaben vergleichbare Qualität. Die wichtigere Architektur-Entscheidung ist, ob Ihr Stack das Modell als austauschbar behandelt.

Multi-Modell-Routing ist in reifen Deployments Standard. Prinzip: Unterschiedliche Aufgaben haben unterschiedliche optimale Modelle. Ein schnelles, günstiges Modell übernimmt Klassifikation und Intent-Routing. Ein leistungsfähigeres Modell kümmert sich um komplexes Reasoning. Ein spezialisiertes Modell übernimmt Code. Dynamisches Routing zwischen diesen Modellen senkt Kosten, ohne die Qualität auf den kritischen Tasks zu verschlechtern.

Fallback-Logik

Fallback ist in Produktion Pflicht. Wenn ein Modell-Provider eine Störung hat oder Ihr Konto rate-limitiert, brauchen Sie ein automatisches Failover auf ein Zweitmodell. Ohne das fällt Ihr Agent zusammen mit dem Provider aus.

Vendor-Lock-in-Risiko

Modell-Provider bauen aktiv proprietäre Plattformen, die einen Wechsel möglichst schmerzhaft machen sollen. Entwerfen Sie Ihre Modellsicht so, dass sie wirklich austauschbar ist – über eine Abstraktionsschicht oder ein Multi-Provider-Gateway – bevor Sie sich tief in ein Ökosystem eingraben.

2. Orchestrierung

Aufgabe
Mehrstufige Workflows steuern: Agentaktionen sequenzieren, Tool-Aufrufe ausführen, Retry-Logik anwenden, Aufgaben zwischen spezialisierten Subagenten routen und den Workflow-Zustand verwalten.

Beispiele: LangGraph, AutoGen, CrewAI, Temporal (für langlebige Workflows).

Die Orchestrierung ist dort, wo die meisten Produktionsprobleme entstehen. Ein einstufiger Single-Agent-Workflow ist einfach. Mehrstufige, Multi-Agent-Workflows bringen kumulative Komplexität: Jeder Schritt hängt von vorherigen Outputs ab, Tool-Aufrufe können fehlschlagen oder unerwartete Ergebnisse liefern, und der Agent muss das robust handhaben.

Was die Orchestrierungsschicht leisten muss

• Sequenzverwaltung – Schritte in der richtigen Reihenfolge mit dem richtigen Kontext ausführen
• Zuverlässige Tool-Aufrufe – fehlgeschlagene Tool-Calls mit Backoff erneut versuchen, statt den gesamten Workflow scheitern zu lassen
• Zustandsspeicherung – bei langen Workflows den Zustand so sichern, dass ein Crash in Schritt 7 nicht wieder bei Schritt 1 beginnt
• Human-in-the-loop-Gates – Ausführung pausieren, um vor kritischen Aktionen menschliche Freigabe einzuholen
• Abbruchbedingungen – Endlosschleifen verhindern, in denen der Agent fehlgeschlagene Operationen endlos wiederholt
• Fehlerpropagation – entscheiden, wann erneut versucht, wann eskaliert und wann sauber abgebrochen wird

LangGraph ist das derzeit am weitesten verbreitete Orchestrierungsframework für komplexe stateful Agenten. Temporal ist der Standard für langlebige Workflows mit robusten Ausführungsgarantien (Workflows können Stunden oder Tage pausiert und exakt an der gleichen Stelle fortgesetzt werden). AutoGen eignet sich, wenn Compliance-Anforderungen auf private LLM-Deployments drängen, etwa auf Azure.

3. Speicher & Daten

Aufgabe
Agenten Kontext geben – sowohl kurzfristig (Session-State) als auch langfristig (Knowledge Bases, vergangene Interaktionen, strukturierte Geschäftsdaten).

Ein Agent ohne Speicher ist ein zustandsloser Request-Prozessor. Für einfache Lookups ist das okay, aber die meisten realen Workflows brauchen Kontext – aus dem bisherigen Gespräch, aus früheren Interaktionen mit demselben Nutzer oder aus Unternehmenswissen.

Drei Arten von Speicher

1. Session-Speicher: Gesprächsverlauf während einer aktiven Session. Redis ist der Standard: schnell, mit automatischer Expiration und gut geeignet für die Lese/Schreib-Patterns. Speichern Sie nicht alles – definieren Sie, welchen Kontext der Agent wirklich braucht, und seien Sie selektiv.

2. Semantischer Speicher: Zugriff auf unstrukturierte Informationen – Dokumente, Richtlinien, alte Tickets, Produktspezifikationen. Vektordatenbanken (Pinecone, Weaviate, ChromaDB) speichern Embeddings, mit denen der Agent Inhalte nach Bedeutung statt nach exakten Keywords findet. Das ist die Grundlage von RAG (Retrieval-Augmented Generation).

3. Zugriff auf strukturierte Daten: Anbindung an bestehende Systeme – CRM, ERP, Ticketing, HR-Plattformen. Das erfordert Connectors oder APIs für jedes System sowie klare Data Governance: Welcher Agent darf welche Daten lesen, und unter welchen Bedingungen schreiben?

Datensouveränität

In regulierten Branchen wird es immer schwerer, Unternehmensdaten über öffentliche KI-APIs zu schicken – Stichworte DSGVO, HIPAA, EU AI Act. Sovereign Deployment – bei dem die gesamte Agenteninfrastruktur in Ihrem eigenen Cloud-VPC oder on-prem läuft – ist für Unternehmen mit sensiblen Daten der einzig realistische Weg. Entwerfen Sie die Datenschicht von Anfang an mit diesem Ziel.

4. Serving & Skalierung

Aufgabe
Parallele Anfragen handhaben, Last verteilen und sicherstellen, dass der Agent unter realem Traffic verfügbar bleibt.

Ein Prototyp läuft in einem einzelnen Prozess. Ein Agent in Produktion muss mehrere Benutzer gleichzeitig bedienen, Instanzfehler überstehen und mit der Nachfrage skalieren. Diese Schicht ist klassische Engineering-Infrastruktur – die gleichen Muster wie bei jedem Webservice, angepasst auf KI-Workloads.

Containerisierung zuerst

Docker ist der Startpunkt. Wenn Sie Agent und Abhängigkeiten in ein Image packen, läuft er in Entwicklung, Staging und Produktion identisch. Skalierung und Deployment-Automatisierung werden deutlich einfacher.

Stateless vs stateful Agents

Stateless Agents
Jede Anfrage ist unabhängig. Kein Sitzungszustand zwischen Calls. Einfacher zu skalieren – mehr Instanzen reichen.

Geeignet für: FAQ-Bots, Klassifikation, einfache Lookups.
Deployment: Serverless-Plattformen (AWS Lambda, Google Cloud Run) für variablen Traffic mit nutzungsbasierter Abrechnung.

Stateful Agents
Halten Kontext über mehrere Interaktionen. Komplexer – brauchen Persistenzspeicher und saubere Zustandsverwaltung.

Geeignet für: mehrstufige Konversationen, lange Workflows, Agenten mit Gedächtnis.
Deployment: Container-Orchestrierung (ECS, Kubernetes) für dauerhafte Workloads mit Load Balancing.

Die meisten produktiven Systeme nutzen beide Muster. Eine Support-Plattform kann stateless Agents für einfache FAQs und stateful Agents für längere Supportfälle einsetzen.

Queues für asynchrone Workloads

Nicht jede Agentenaufgabe braucht eine synchrone Antwort. Für komplexe Workflows – Recherche, Dokumentenerstellung, Datenanalyse – ist das Async-Pattern richtig: Der Nutzer erhält sofort eine Bestätigung, der Agent arbeitet im Hintergrund, und das Ergebnis wird nachgeliefert. Message Queues (Redis, AWS SQS, RabbitMQ) trennen Scheduling und Ausführung und erlauben Worker-Pools, mehrere Jobs parallel zu verarbeiten, ohne die Oberfläche zu blockieren.

5. Governance & Observability

Aufgabe
Jede Ausführung nachverfolgen, Berechtigungen steuern, Policies durchsetzen und die Audit-Trails liefern, die für Compliance nötig sind.

Diese Schicht wird in frühen Deployments oft vernachlässigt – und entscheidet in Enterprise-Setups über Erfolg oder Scheitern. Governance ist keine Option, die man später hinzufügt. Wenn sie gebraucht wird, ist es meist zu spät (und zu teuer), sie nachzurüsten.

Was Governance praktisch bedeutet

• RBAC (Role-Based Access Control) – Welche Nutzer oder Systeme dürfen welche Agenten starten, auf welche Daten zugreifen und welche Aktionen freigeben? Ein Sales-Agent sollte keine HR-Daten sehen. Ein Agent, der E-Mails versenden kann, braucht in Produktion Freigabeprozesse.
• IT-Validierung vor Produktion – ein formaler Gate, an dem Security/IT Agentenkonfigurationen prüft und freigibt, bevor sie live gehen. Standard in regulierten Umgebungen, zunehmend üblich darüber hinaus.
• Vollständiges Audit-Log – jede Agenten-Ausführung mit: Modellversion beim Run, vollständigem Input/Output, Tool-Calls und Ergebnissen, menschlichen Freigaben, Nutzeridentität und Timestamp. Das ermöglicht Compliance-Audits und die Beantwortung der Frage „Warum hat der Agent das getan?“.
• Datenresidenz einhalten – für EU-Unternehmen: DSGVO-konforme Verarbeitung und oft die Anforderung, dass Daten in EU-Infrastruktur bleiben. Unter dem EU AI Act gelten für Hochrisiko-Systeme zusätzliche Dokumentations- und Aufsichtspflichten.

Build vs Buy: ehrliche Trade-offs

Sie können alle fünf Schichten aus Open-Source-Komponenten selbst bauen. Technisch machbar. Die Frage ist, ob es die beste Nutzung Ihrer Engineering-Kapazität ist.

Inhouse bauen

Vollständige Kontrolle über jede Schicht. Kein Vendor-Lock-in. Optimierbar für sehr spezifische Anforderungen.

Realität: meist 3–6 Monate bis zu einem produktionsreifen Stack. Erfordert DevOps-Expertise über alle Schichten. Jede Komponente muss mit der sich schnell ändernden Tool-Landschaft Schritt halten.

Sinnvoll für: sehr spezielle Anforderungen, stark regulierte Umfelder, große Engineering-Teams.

Gemanagte Plattform

Infrastruktur out-of-the-box. Schneller in Produktion. Governance und Observability inklusive.

Realität: weniger Flexibilität in Edge-Cases. Lock-in-Risiko, wenn die Plattform keinen echten Modell-Wechsel zulässt.

Sinnvoll für: Teams, die sich auf Agentenlogik statt Infrastruktur konzentrieren wollen. Die meisten Enterprise-Deployments.

Die Kernfragen bei der Bewertung einer Plattform: Bietet sie Datensouveränität (Deployment in Ihrem VPC oder on-prem), Modellflexibilität (Modelle wechseln ohne Codeänderung) und echte Audit-Fähigkeit (Logs für Compliance exportierbar)?

Vor dem Deployment: Infrastruktur-Checkliste

• Modellschicht – Multi-Modell-Routing konfiguriert, Fallback-Provider definiert, Modellschicht abstrahiert für spätere Wechsel
• Orchestrierung – Abbruchbedingungen gesetzt, Retry-Logik mit Backoff, Zustands-Persistenz für lange Workflows
• Speicher – Session-Speicher eingerichtet, Knowledge Base indexiert und auf Retrieval-Qualität getestet, Datenzugriffsrechte definiert
• Serving – containerisiert, Lasttests durchgeführt, Health Checks konfiguriert, Skalierungsstrategie definiert
• Governance – RBAC-Rollen definiert, IT-Freigabeprozess etabliert, Audit-Logs aktiv, Datenresidenzanforderungen erfüllt
• Observability – Traces für jede Ausführung, Kosten-Monitoring pro Request, Qualitäts-Evaluierungen auf Sample-Traffic
• Security – SSO konfiguriert, Secrets-Management vorhanden, keine Hardcoded API-Keys

Alle fünf Schichten – von Tag eins an bereit

Origin 137 bündelt Modelle, Orchestrierung, Governance und Observability in einer Plattform – als Managed Cloud, Private Cloud oder on-prem. Sie bringen Ihren ersten Agenten in Tagen, nicht in Monaten, in Produktion.

Kostenlos starten – keine Karte erforderlich

---

Quellen: Shakudo, The Enterprise AI Agent Infrastructure Stack, Explained, 2026 · Madrona, The AI Agent Infrastructure Stack — Three Defining Layers, Feb. 2025 · Machine Learning Mastery, Deploying AI Agents to Production: Architecture, Infrastructure, and Implementation Roadmap, 2026 · Netguru, The AI Agent Tech Stack in 2025: What You Actually Need to Build & Scale, Nov. 2025 · Fast.io, Top AI Agent Infrastructure Stacks for Developers, 2025\n