Ein Agent, der unter Last umfällt, ist schlimmer als kein Agent — er verschiebt das Problem, ohne es zu lösen. Resilience-Patterns sind kein Add-on, das man am Ende drüberlegt. Sie sind die Grundlage dafür, dass aus einem PoC ein Live-System wird, das morgens um 9:00 Uhr unter Volllast funktioniert.
Vier Resilience-Patterns, die zur Pflicht gehören
Circuit Breaker
Wenn ein nachgelagertes System (LLM-Provider, ERP, DMS) wegbricht, soll der Agent nicht in Endlosschleifen-Retries laufen. Ein Circuit Breaker zählt Fehler, öffnet nach einer Schwelle, gibt der nachgelagerten Komponente Zeit zum Erholen und schließt nach erfolgreichen Halbprobeläufen wieder.
Praktisch: ein Wrapper um jeden Tool-Call mit konfigurierbarer Fehlerschwelle (z. B. „”). Bibliotheken wie opossum (Node) oder pybreaker (Python) liefern das Pattern fertig.
Rate Limiting
LLM-Provider haben Quoten. Wer 1000 Anfragen parallel feuert, wird gedrosselt — oder ausgesperrt. Ein eigenes Rate-Limit (z. B. Token-Bucket pro Service-Account) schützt vor unkontrollierten Kostenspitzen und vor 429-Kaskaden.
Für die Praxis: nicht nur das Outbound-Limit bedenken, sondern auch Inbound-Limits — wie viele parallele Konversationen kann das System sicher tragen, ohne dass Latenzen aus dem Ruder laufen?
Dead Letter Queue (DLQ)
Manche Aufträge lassen sich nicht ad-hoc verarbeiten — fehlende Daten, ein anderer Agent nicht erreichbar, ein Tool dauerhaft offline. Statt sie zu verlieren, landen sie in einer Dead Letter Queue: persistent, mit Kontext, manuell oder automatisch re-droppbar.
Eine gut betriebene DLQ ist das beste Diagnoseinstrument für Agent-Systeme — sie zeigt Muster, die im normalen Log untergehen.
Human-in-the-Loop (HITL)
Nicht jede Aktion soll autonom durchlaufen. Ab einer bestimmten Größenordnung oder bei niedriger Konfidenz übergibt der Agent an einen Menschen — über ein klar definiertes Approval-UI (z. B. in Slack/Teams oder einem eigenen Dashboard).
Wichtig: HITL ist nicht „”. HITL ist „”. Die Genehmigungsfälle fließen idealerweise in eine Feedback-Schleife zurück (Reflect.-Phase).
Beobachtbarkeit ist kein Add-on
Ohne strukturierte Audit-Logs ist Resilience eine Behauptung. Wir loggen pro Agent-Schritt:
- Eingaben (Hash, falls sensibel) und Auswahl-Entscheidungen.
- Tool-Aufrufe mit Request/Response und Latenz.
- Confidence-Werte und Eskalationsentscheidungen.
- Modell-Version, Prompt-Version, Workflow-Version — für Reproduzierbarkeit.
Empfehlung: OpenTelemetry-basierte Tracing-Backbone (Tempo, Jaeger oder LangSmith), kombiniert mit strukturierten Logs in PostgreSQL. So entstehen Audit-Trails, die für DSGVO-Anfragen ebenso taugen wie für die nächste Fehleranalyse.
Governance: was wirklich in die Pipeline gehört
Ein Agent, der schreibend tätig ist, braucht governance by design — nicht als nachträgliches Audit. Drei konkrete Elemente:
- Approval-Schwellen pro Aktionstyp (z. B. Buchungen > 5 000 € immer mit HITL).
- Versionierung von Prompts und Workflows (kein „” im Produktivsystem).
- DSGVO-Compliance pro Tool — welche Daten verlassen den EU-Raum, welche nicht?
Compliance-Realität: TLS, Audit-Logs, kein US-Egress
DSGVO-konform heißt für uns konkret: TLS 1.3 überall, verschlüsselte Speicher (sowohl At-Rest als auch in PostgreSQL-Spalten für PII), Audit-Logs pro Datenfluss, Webhook-Signaturprüfung. Daten verlassen die EU nicht — LLM-Provider mit EU-Endpoints oder lokale Modelle als Fallback.
Fazit
Resilience ist die unsichtbare Hälfte eines guten Agent-Systems. Sie wird erst sichtbar, wenn etwas schief geht — und dann entscheidet sie darüber, ob das System weiterläuft oder steht. Wer diese Patterns von Anfang an mitdenkt, baut nicht „” — er liefert direkt produktionsreif.