Du übernimmst den Kontrollraum eines Multi-Agent-Systems für eine temperaturkritische Pharma-Sendung. Entscheide zunächst selbst – und prüfe danach, ob Traces, Evidenz und Guardrails deine Einschätzung bestätigen. Beobachten. Erkennen. Eingreifen.
Du bist Supply-Chain-Manager im Pharma-Logistik-Team. Dein Monitoring-Board zeigt die aktiven Sendungen – und eine davon verlangt gleich deine Entscheidung. Du tippst die Frage, die dein Multi-Agent-System in Gang setzt:
Vier spezialisierte Agenten gehen an die Arbeit:
Zerlegt die Anfrage, delegiert an die Spezialisten und führt die Ergebnisse zur Entscheidung zusammen.
delegate()synthesize()Untersucht Lieferverträge und Incoterms: Welche Bedingungen gelten für diese Sendung wirklich?
read_contract()Prüft Wetterdaten und operative Terminal-Signale getrennt – inklusive Quelle und Aktualität.
get_weather()terminal_feed()Leitet Eskalationen und Folgehandlungen ein – Umbuchung, Kundeninfo, Versicherungsmeldung.
rebook_air_freight()notify_customer()Drei Szenarien, ein System. Steuere den Run Schritt für Schritt - jeder Span im Trace ist anklickbar und zeigt Input und Output. Links MLflow, rechts Blue Guardrails, und am Ende entscheidest: du.
Die Kette bleibt neutral, bis der Claim gegen die Quelle geprüft wurde.
Der Betrag liegt über dem persönlichen Limit. Die Ausführung bleibt blockiert, bis ein Supply Chain Director bestätigt.
Jetzt wird sichtbar, warum nicht die Aktion, sondern ihre Evidenzlage entscheidet.
Oben im Kontrollraum klickst du durch die Choreografie – hier steht das echte System dahinter: Im Live-Pfad für Szenario B orchestriert pi die Agenten, OpenTelemetry zeichnet jeden Schritt auf, Blue Guardrails prüft kritische Claims und Mailentwürfe gegen die Quellen, das Gate hält Aktionen an – und MLflow macht den gesamten Ablauf sichtbar.
delegate
Sie ist kein weiterer Agent, sondern registriert Lifecycle-Hooks im selben Prozess.
session / agentOpenTelemetry-Spans erzeugenllm / toolModell, Token und Latenz erfassentool_callBlue-Guardrails-Check + Gate-StoppOTLP bedeutet OpenTelemetry Protocol: ein offenes Trace-Format. Die Spans werden direkt an den nativen MLflow-Ingest geschickt – ohne separaten Collector.
OTLP → /v1/traces
BG erhält nicht den OTLP-Trace: Bei Umbuchungen geht die Begründung, bei Kundeninfos der echte Mailentwurf plus Basis zusammen mit Vertrag, Wetter-, Warnungs- und Terminalkontext an die Issue Detection.
POST /v1/evaluate
Label, Erklärung sowie Evaluation-/Conversation-ID kommen mit dem blockierten Tool-Call zum FastAPI-Gate. Die Conversation bleibt mit store=true im BG-Dashboard sichtbar.
POST :8765/api/requests
Die Entscheidung geht an den wartenden tool_call zurück. Danach läuft das Tool – oder der Agent plant neu. Gleichzeitig landet human_gate_decision als Assessment im Trace.
--- name: anwalt tools: read_contract model: deepseek/deepseek-v4-flash --- Du bist der Anwalt … Nenne IMMER den einschlägigen Paragraphen und den konkreten Grenzwert.
orchestrator.run run-b-… · Szenario B ├─ anwalt.run deepseek-v4-flash │ ├─ read_contract contract_4711.pdf │ └─ llm.request 1 842 tok ├─ macher.run deepseek-v4-flash │ └─ rebook_air_freight ⏸ GATE · 18 000 € └─ assessment human_gate_decision = rejected
Autonomie ohne Aufsicht ist keine Effizienz, sondern ein Risiko mit guter Laune. Der Showcase zeigt eine zentrale Governance-Kette für agentische Systeme – ergänzt um Rollen, Limits, Datenqualität, Security und Betriebsprozesse:
Ohne Tracing ist ein Multi-Agent-System eine Blackbox aus LLM-Calls. Verschachtelte Traces zeigen, wer wann was mit welchen Argumenten getan hat – inklusive Tokens, Kosten und Latenz pro Agent.
Der Anwalt-Agent klingt überzeugend – und zitiert eine Klausel, die es nicht gibt. Vor der kritischen Aktion prüft ein separater REST-Call den Claim beziehungsweise Mailentwurf gegen Vertrag und Live-Lage und markiert genau den erfundenen Satz. Ohne Prüfung potenziert sich der Fehler: falsche Schlussfolgerung → falscher Tool-Call.
Detektion allein blockt nicht. Kritische Tools pausieren den Run und verlangen menschliche Freigabe. Die Entscheidung landet als Assessment am Trace – und macht den Eingriff auditierbar.
Die Agenten laufen in pi.dev. OpenTelemetry sendet den Trace-Baum per OTLP an MLflow; parallel prüft ein separater REST-Call den kritischen Claim oder Mailentwurf mit Quellenkontext bei Blue Guardrails. Beide Befunde treffen im Human-Gate zusammen.
fabrication oder context_misattribution/v1/evaluate – kein OTLP-Trace-Fan-outDer Unterschied zwischen Halluzination und belastbarer Antwort liegt oft in einer einzigen Prompt-Zeile. Szenario B läuft mit v12, Szenario C mit v13.
Tracing macht Handlungen sichtbar. Guardrails prüfen Claims. Policies und menschliche Freigaben verhindern, dass ein erkannter Fehler trotzdem zur echten Aktion wird.
Der direkte Vergleich der beiden Challenge-Runs.
Shadow-Simulation des Halluzinationsfalls.
rebook_air_freight(#4711)
Aktion erfolgreich ausgeführt.
Fabrikation in §7 Abs. 3 erkannt.
Der Fehler ist sichtbar – aber die Aktion bereits abgeschlossen.