Multi-Agent-Systeme in Produktion: Verträge, Gates und menschliche Eskalation

Multi-Agent-Architektur ist sinnvoll, wenn ein Workflow tatsächlich unterschiedliche Verantwortlichkeiten, Verträge oder Review-Kriterien besitzt. Unnötig ist sie, wenn eine deterministische Pipeline oder ein begrenzter Modellaufruf reicht. Mehr Agents bedeuten mehr Koordination, Kontext, Latenz, Kosten und Fehlerbilder; diese Komplexität muss sich rechtfertigen.

Mit Rollenverträgen beginnen

Definiere jede Rolle über Input-Schema, erlaubte Tools, Output-Schema, Stop-Bedingung und Eskalationsregel. Ein Researcher liefert belegte Kandidaten, ein Planner einen begrenzten Plan, ein Executor ruft nur eine Allowlist von Tools auf. Rollen sollten keinen undifferenzierten Gesprächsverlauf teilen, wenn ein typisierter Übergabewert reicht.

Der Orchestrator verantwortet Zustandsübergänge, nicht die Agents. Er protokolliert Rolle, Vertragsversion, Evidenz und den Grund für den nächsten Schritt. Ein Vertragsfehler ist ein behandelbarer Workflow-Zustand – kein Anlass, einen weiteren Agenten still improvisieren zu lassen.

Context Engineering und Tools

Kontext wird für die Rolle zusammengestellt, nicht aus dem gesamten Verlauf kopiert. Stabile Instruktionen, Task-Zustand, abgerufene Evidenz und frühere Entscheidungen bleiben getrennt. Provenance und Aktualität werden dort mitgegeben, wo sie die Entscheidung beeinflussen. Zusammenfassungen sollten gegen den zugrunde liegenden Zustand prüfbar bleiben.

Tools sind Fähigkeitsgrenzen. Nutze enge Schemata, Least-Privilege-Credentials, explizite Validierung, Idempotenz und bei folgenreichen Aktionen Bestätigung. Tool-Ergebnisse sind untrusted Input; Prompt Injection kann aus Dokumenten, Web-Inhalten oder API-Antworten kommen. Der Security-Service beschreibt passende Controls.

Evaluation, Retries und Trade-offs

Evaluiere den gesamten Workflow und jede kritische Rolle. Fälle umfassen Normalpfade, fehlende Evidenz, widersprüchliche Quellen, Tool-Fehler, wiederholte Retries und menschliche Eskalation. Deterministische Gates prüfen Schema, Berechtigungen, Quellen und Zustandsübergänge; Human Review bewertet Urteil und Nützlichkeit.

Retries brauchen Budget und Grund. Eine Schema-Reparatur kann sicher wiederholt werden; eine fehlgeschlagene Geschäftsaktion braucht eventuell Review. Begrenze Turns, Tokens, Laufzeit und Kosten. Miss, ob ein zusätzlicher Agent die Baseline so stark verbessert, dass Latenz und Komplexität gerechtfertigt sind. Ein Fallback auf eine einfachere Pipeline ist oft verlässlicher als ein weiterer autonomer Zweig.

Observability und Übergabe

Trace den Workflow über Rollen, Retrieval, Tools, Validierungen und Reviewer-Aktionen. Erfasse Prompt- und Vertragsversionen, Modell, Latenz, Tokens, Kosten und Fehlerklasse unter Beachtung von Redaction und Aufbewahrung. Dashboards sollten zeigen, wo Arbeit stoppt – nicht nur, wie viele Requests erfolgreich sind.

Produktionsreife umfasst ein Runbook für festgefahrene Zustände, Provider-Fehler, unsichere Vorschläge und Teilabschluss. Human Escalation braucht Queue, Kontext, Entscheidungsbegriffe und eine Möglichkeit, den Zustand fortzusetzen oder zu schließen. Der This-Site-Case zeigt dieselbe allgemeine Disziplin getrennter Rollen und Gates, ohne ein universelles Verfahren zu behaupten.

Ein begrenztes Referenzmuster

Nutze Orchestrator mit explizitem Zustand, wenige Rollenverträge, typisierte Artefakte, Allowlists, Eval-Gates, Retry-Budgets und Human Escalation für folgenreiche oder mehrdeutige Ergebnisse. Halte einen Single-Agent- oder deterministischen Fallback bereit. Neue Rollen kommen erst hinzu, wenn ein gemessener Workflow-Mangel sie rechtfertigt.

Das Ergebnis ist keine Produktbehauptung über „Autonomie“, sondern ein System, dessen Fähigkeiten und Grenzen überprüft, getestet, betrieben und bewusst geändert werden können. Der Engineering-Service ist ein sinnvoller erster Scoping-Schritt.

Architektur erklärbar halten

Das einfachste nützliche Diagramm zeigt Zustand, Rollengrenzen, Tools, Gates und menschliche Ausgänge. Wenn ein Team nicht erklären kann, warum eine Rolle lief, welche Evidenz sie nutzte oder wo ein Fehlerzustand liegt, ist die Architektur für Produktion zu implizit. Beginne mit wenigen Verträgen und verdiene zusätzliche Autonomie durch beobachtetes Verhalten, statt vorsorglich weitere Zweige anzulegen.