KI-Agenten: Vom Prototyp zum Produktivbetrieb

Die KI-Agenten-Demo kommt im Stakeholder-Meeting gut an. Der CEO ist begeistert, der Produktmanager schreibt bereits an der Pressemitteilung. Nur das Jupyter Notebook hält dem ersten Kontakt mit echten Nutzern nicht stand.

Zwischen „lokal funktioniert es“ und „es funktioniert samstags um 3 Uhr für 10.000 Nutzer“ liegen zahlreiche betriebliche Anforderungen. Dieser Leitfaden beschreibt, wie sich diese Lücke schließen lässt, ohne den Produktivbetrieb zum ständigen Debugging-Projekt zu machen.

Die Lücke zwischen Prototyp und Produktivbetrieb

Ein KI-Agent-Prototyp hat üblicherweise diese Einschränkungen:

• Single-Thread-Ausführung (eine Anfrage nach der anderen)
• Keine Fehlerbehandlung (bei einem Fehler muss das Notebook neu starten)
• In Zellen hartcodierte API-Keys
• Kein Logging (Print-Ausgaben reichen nicht aus)
• Unbegrenzte Timeouts (das Notebook bleibt einfach hängen)
• Keine Kostenüberwachung (überraschende OpenAI-Rechnungen über 500 US-Dollar)

Für Demos reicht das aus, für den Produktivbetrieb nicht.

Checkliste für den Produktivbetrieb

Diese Anforderungen müssen erfüllt sein, bevor ein Agent auf echte Nutzer trifft. Fehlt eine davon, beginnt das Debugging im laufenden Produktivbetrieb.

1. Isolierte Ausführungsumgebungen

Jede Ausführung eines Agenten muss vollständig isoliert sein. Gemeinsam genutzter Zustand oder globale Variablen dürfen das Ergebnis einer späteren Anfrage nicht beeinflussen.

2. Wiederholungslogik mit exponentiellem Backoff

LLM-APIs fallen aus, Rate-Limits greifen, Netzwerke haben kurze Störungen. Ein Agent muss damit sauber umgehen können, statt abzustürzen.

version: "1.0"
name: resilient-agent
description: "A resilient assistant with retry handling"
model: connic/gpt-5.6-terra
system_prompt: |
  You are a helpful assistant.
retry_options:
  attempts: 3      # Total attempts, including the first (1-10)
  initial_delay: 10
  max_delay: 30    # Max seconds between retries

Eine passende Wiederholungskonfiguration fängt vorübergehende Fehler automatisch ab und vermeidet unnötige Alarme für den Bereitschaftsdienst.

3. Timeout-Behandlung

Für zu lange Agentenausführungen braucht der Produktivbetrieb ein definiertes Verhalten. Ein Prototyp wartet häufig einfach weiter.

• •Anfrage-Timeout: Maximale Zeit für die gesamte Ausführung (verhindert ausufernde Kosten)
• •Tool-Timeout: Maximale Zeit für einzelne Tool-Aufrufe
• •Umgang mit Fehlern: Teilergebnisse statt gar nichts zurückgeben

4. Parallelitätssteuerung

Greifen 100 Nutzer gleichzeitig auf einen Agenten zu, entstehen ohne gesteuerte Parallelität mehrere Probleme:

• →Rate-Limits greifen sofort
• →Der Arbeitsspeicher ist erschöpft
• →Unvorhersehbare Antwortzeiten
• →Kostenspitzen

Produktivsysteme benötigen Parallelitätsgrenzen pro Agent, Warteschlangen für Anfragen und eine faire Ablaufplanung.

5. Observability (nicht verhandelbar)

Ohne Einblick in das Verhalten eines Agenten beruht die Fehlersuche auf Vermutungen. Im Produktivbetrieb lassen sich solche Probleme nicht vollständig vermeiden.

Zur Observability im Produktivbetrieb gehören:

• •Ausführungsverlauf: Jede Ausführung mit Status, Dauer und Trigger-Quelle
• •Ausführungs-Traces: Schrittweise Aufschlüsselung von LLM- und Tool-Aufrufen sowie Schlussfolgerungen
• •Token-Erfassung: Eingabe- und Ausgabe-Token pro Ausführung und LLM-Aufruf
• •Fehlerkategorisierung: Tool-Fehler, Rate-Limit, Timeout oder ungültige Eingabe?

Skalierbare Integrationsmuster

Auch die Art des Triggers bestimmt die Skalierbarkeit eines Agenten. Die folgenden Muster eignen sich für hohe Last.

Asynchrone Architektur

Bei einer synchronen API sendet ein Nutzer eine Anfrage und wartet auf die Antwort. Unter Last entstehen dabei typische Probleme:

• →Die Verarbeitung dauert 30 Sekunden und der Load Balancer läuft in ein Timeout
• →Nutzer laden die Seite neu und erzeugen doppelte Anfragen
• →Webserver sind beim Warten auf LLM-Antworten blockiert

Die Lösung: annehmen → Queue → verarbeiten → Callback.

1. User submits request
   → API returns immediately with request_id

2. Request triggers agent via webhook/queue
   → Agent processes asynchronously

3. Agent completes
   → Results delivered via outbound connector
   → Webhook callback to the originating system
   → Or direct database write

4. User polls or receives push notification
   → Results displayed in UI

Wann synchrone Verarbeitung sinnvoll ist

Synchrone Abläufe eignen sich für diese Fälle:

• •Chat-Oberflächen: Nutzer erwarten sofortige, gestreamte Antworten
• •Einfache Abfragen: Schnelle Vorgänge, die in <5 Sekunden abgeschlossen sind
• •Blockierende Workflows: Abläufe, die erst mit dem Ergebnis fortgesetzt werden können

Dafür eignen sich WebSocket-Verbindungen mit gestreamten Antworten und strengen Timeouts.

Ein vollständiges Beispiel für den Produktivbetrieb

Das folgende Beispiel führt alles zusammen: eine Pipeline zur Dokumentenverarbeitung, die Daten aus hochgeladenen Rechnungen extrahiert.

version: "1.0"
name: invoice-extractor
description: "Extracts structured data from invoices"
model: connic/gemini-3.7-flash
system_prompt: |
  You are an invoice processing specialist. Extract structured
  data from invoice images and documents.

  Always extract: vendor name, invoice number, date, line items,
  subtotal, tax, and total. If a field is unclear, mark it as
  "unclear" rather than guessing.
tools:
  - documents.parse_pdf
  - documents.extract_text_from_image
  - validation.verify_totals
output_schema: invoice  # References schemas/invoice.json

version: "1.0"
name: invoice-pipeline
type: sequential
description: "Complete invoice processing: extract, validate, store"
agents:
  - invoice-extractor
  - invoice-validator
  - invoice-storer

Diese Pipeline:

• 1.Startet, wenn eine Datei auf S3 hochgeladen wird
• 2.Extrahiert strukturierte Daten mit Konfidenzwerten
• 3.Validiert die extrahierten Daten (Rechenprüfungen, Formatvalidierung)
• 4.Speichert Ergebnisse und benachrichtigt nachgelagerte Systeme

Jeder Schritt wird protokolliert und die Token werden gezählt. Vorübergehende Fehler lösen beim betroffenen KI-Modell-Aufruf oder Verarbeitungsschritt eine Wiederholung mit exponentiellem Backoff aus.

Deployment-Strategie

Deployments in den Produktivbetrieb sollten ohne manuelle Schritte auskommen. Das gilt besonders für Änderungen kurz vor dem Wochenende.

Git-basierter Workflow

# Make changes
$ vim agents/invoice-extractor.yaml

# Test locally with hot-reload
$ connic test

# Commit and push
$ git add .
$ git commit -m "Improve extraction accuracy for handwritten invoices"
$ git push origin main

# Deployment happens automatically
# Dashboard shows build progress and deployment status

Rollback in Sekunden

Jedes Deployment ist versioniert. Wenn etwas schiefgeht:

• →Im Dashboard auf „Rollback“ klicken
• →Die vorherige Version ist sofort live
• →Das Problem ohne Zeitdruck im Produktivbetrieb debuggen

Anforderungen an den Produktivbetrieb prüfen

Eine verwaltete Plattform kann die Lücke zwischen Prototyp und Produktivbetrieb schließen. Dazu übernimmt sie folgende betriebliche Anforderungen:

• ✓Isolierte Ausführungsumgebungen (automatisch)
• ✓Wiederholungslogik und Timeout-Behandlung (konfiguriert statt programmiert)
• ✓Parallelitätssteuerung (Grenzen pro Agent)
• ✓Vollständige Observability (vom ersten Tag an integriert)
• ✓Sofortige Rollbacks (per Klick)

Eine Plattform kann den Betrieb übernehmen, damit sich das Team auf die Aufgabe des Agenten konzentrieren kann. Bei der Auswahl hilft der Vergleich der Deployment-Plattformen für KI-Agenten.

Der Quickstart beschreibt die ersten Schritte, während die Observability-Funktionen das Monitoring für den Produktivbetrieb zeigen.