Die meisten Fehler in Multi-Agenten-Systemen, die ich gesehen habe, entstehen nicht in einem Agenten. Sie entstehen zwischen zweien.

Wird die Übergabe zwischen zwei Agenten als lose strukturiertes JSON oder als impliziter gemeinsamer Zustand behandelt, ist die Schnittstelle unterspezifiziert, und unterspezifizierte Schnittstellen scheitern leise.

Eine Übergabe im Produktivbetrieb sollte wie jeder andere API-Vertrag behandelt werden:

  • ein explizites Eingabeschema;
  • ein explizites Ausgabeschema;
  • Pflicht- und optionale Felder;
  • fachliche Bedingungen, nicht nur gültiges JSON;
  • ein klarer Weg für Ablehnung und Rückfall.

Ein konkretes Beispiel

Ein Recherche-Agent sollte einem Bewertungs-Agenten kein unstrukturiertes Objekt übergeben. Er sollte etwas liefern, das der Bewerter tatsächlich validieren kann:

class ResearchResult(BaseModel):
    subject_id: str
    evidence: list[EvidenceItem] = Field(min_length=1)
    source_count: int = Field(ge=1)
    confidence: float = Field(ge=0, le=1)

Der Bewerter läuft erst, nachdem dieses Ergebnis die Validierung bestanden hat. Diese Schranke ist der entscheidende Teil.

Probabilistische Ausgabe, folgenreiche Aktion

Die Ausgabe eines LLM ist probabilistisch. Ein Datenbankeintrag, eine externe Nachricht oder eine geschäftliche Entscheidung ist eine Aktion. Diese beiden Schritte sollten nicht direkt gekoppelt sein.

Setzen Sie dazwischen eine deterministische Prüfung:

  1. Die Modellausgabe parsen.
  2. Schema und Geschäftsregeln validieren.
  3. Bei fehlgeschlagener Validierung ablehnen, erneut versuchen, zur Prüfung weiterleiten oder den Zweig beenden.
  4. Die Aktion nur auf Grundlage eines akzeptierten Vertrags ausführen.
  5. Die Version der Übergabe und das Validierungsergebnis protokollieren.

Warum das das Fehlerverhalten verändert

Ohne Vertrag wird aus einem fehlenden Feld ein Nullwert, aus dem Nullwert eine irreführende Bewertung und aus der Bewertung eine falsche CRM-Aktualisierung. Das Symptom zeigt sich mehrere Schritte von der Ursache entfernt, und bis dahin ist die Spur kalt.

Mit Verträgen ist derselbe Fehler lokalisiert: ResearchAgent -> ScoringAgent, Feld source_count, Validierungsregel verletzt.

Das ist mehr als defensive Programmierung. Es ist Architektur für Softwaresysteme, deren interne Schritte nicht deterministisch sind.

Staff Engineers erhalten unabhängig testbare Grenzen, Principal Engineers können die Kopplung zwischen Teams und Agenten verringern, und Architektinnen, Architekten und CTOs bekommen eine klarere Grundlage, um über Kompatibilität, Verantwortung und Wiederherstellung nachzudenken.

Die Regel

Jeder probabilistische Schritt, der in eine folgenreiche Aktion mündet, braucht eine explizite Validierungsschranke. Typisierte Verträge sind ein wirksamer Weg, diese Grenze festzulegen.

Innerhalb der Grenze darf das Modell kreativ sein. Die Grenze selbst sollte es nicht sein.

Wo hat sich in Ihren Agenten-Workflows ein Vertrag als besonders wertvoll erwiesen: zwischen Agenten, zwischen Agent und Werkzeug oder vor der finalen Aktion?