Start/Stimmung/Debatte/Die Agenten funktionieren, die Koordinations-Schicht nicht
10. April 2026

Die Agenten funktionieren, die Koordinations-Schicht nicht

Am 10. April 2026 erscheinen zwei Texte, die denselben Befund zuspitzen. Sreenivasa Reddy Hulebeedu Reddy (ehemals AT&T) veröffentlicht bei InfoWorld den Kommentar "AI agents aren't failing. The coordination layer is failing". Parallel spricht Shane Hastie im InfoQ Engineering Culture Podcast mit Sam Bhagwat (Mitgründer von Mastra) über "Tiger Teams, Evals and Agents: The New AI Engineering Playbook". Gemeinsame These: Die einzelnen Agenten liefern. Was scheitert, ist die Infrastruktur dazwischen -- Koordination, Evaluation, operative Disziplin. Wer Agent-Systeme unter Last fahren will, repariert nicht die Modelle, sondern die Schicht darum herum.

Was die Koordinations-Schicht leisten muss

Reddys Ausgangspunkt ist ein reales Enterprise-Deployment: Inquiry-, Scheduling- und Document-Agent, jeder isoliert stabil. In Produktion dann das Chaos. Der Scheduling-Agent buchte Termine, während der Inquiry-Agent noch Anforderungen sammelte. Der Document-Agent arbeitete mit Kontext aus einer Konversation, die sich zwei Turns weitergedreht hatte. Die End-to-End-Latenz stieg von 200 Millisekunden auf 2,4 Sekunden, weil Agenten über Ad-hoc-API-Calls aufeinander warteten.

Reddys Diagnose: Agenten wie Microservices über Point-to-Point-Calls zu verdrahten skaliert quadratisch. Fünf Agenten brauchen 10 Verbindungen, zehn 45, zwanzig 190 -- jede ein Failure-Point. Weil Agent A den Zustand von Agent B kennen muss, entstehen genau die Kopplungen, die Spezialisierung eigentlich eliminieren sollte.

Seinen Gegenentwurf nennt er "Event Spine":

Reddys Zahlen nach dem Umbau: Latenz zurück auf 180 Millisekunden, Agent-bezogene Produktionsvorfälle um 71 Prozent reduziert, Agent-CPU-Last um 36 Prozent gesunken. Aus einem Einzelbericht nicht generalisierbar, aber die strukturelle Aussage ist konsistent: Race Conditions und Context-Staleness sind keine Modellprobleme, sondern Koordinationsprobleme.

Das neue Engineering-Playbook

Der InfoQ-Podcast liefert das komplementäre Bild auf Team- und Prozess-Ebene. Bhagwats These: AI-Engineering folgt dem Adoptionsmuster von DevOps oder Data-Engineering, nur drei- bis viermal schneller. Drei Elemente stechen hervor:

Evals als eigene Tool-Kategorie. Tracing und Evals sind laut Bhagwat "10x wichtiger" als im klassischen Engineering, weil agentische Anwendungen nicht-deterministisch sind -- zwei identische Inputs können zwei gleich valide Antworten produzieren. Generische Evals (Toxicity, Tool-Calling-Accuracy) sind Baseline, der Wert entsteht dort, wo Teams gegen eigene, nicht öffentliche Daten und Domain-Regeln testen. Typisches Vorgehen: Subject Matter Expert liefert einen Fragekatalog, das Team baut Referenzantworten, klassifiziert Failure-Modes und "burnt systematisch Fehlerquellen ab".

Tiger Teams als cross-funktionale Einheit. Die nötigen Skills mappen nicht auf bestehende Org-Strukturen: Data Scientists mit Gefühl für statistische Unsicherheit, aber ohne Production-Erfahrung; Software-Engineers mit Production-Denken, aber ohne Intuition für P95/P99 in Qualitätsmaßen; Produktmanager, die Failure-Modes klassifizieren. Kommando-Kontroll-Organisationen scheitern strukturell daran. Bei erfolgreichen Projekten übernimmt teils der CTO persönlich den Lead -- weil Agent-Projekte derzeit "high risk, high value" sind.

Staged Rollouts mit Feature-Flags. Kein Big-Bang-Release, sondern wochenlanger Rollout: Beta, 1 Prozent, 5, 10, 50. Klassische SRE-Infrastruktur, angewandt auf Agenten. Zusammen mit Tracing-Daten lassen sich Fehlermodi statistisch klassifizieren.

Reddy betont die technische Infrastruktur zwischen Agenten, Bhagwat die organisatorische um sie herum. Beide Ebenen müssen bewusst gebaut werden.

Die Gegenposition

Nicht alle teilen die These. Eine Gegenposition lautet: Viele Fehlermodi sind letztlich Modellschwächen, die bessere Basis-Modelle lösen werden. Der Multi-Agent-Orchestrierungs-Realitätscheck hat argumentiert, dass Scaffolding keine Fähigkeiten erzeugen kann, die das Modell nicht hat. Dazu passt Stella Laurenzos Analyse aus Coding-Agenten in der Zuverlässigkeitskrise: Wenn das Modell Code nicht gründlich liest, hilft kein Event-Bus der Welt.

Die ehrliche Antwort ist wohl: Beides stimmt. Wo ein Agent inhaltlich unfähig ist, hilft Koordination nichts. Aber wo Agenten einzeln funktionieren, verschiebt sich der Flaschenhals nach außen. Context-Staleness, Race Conditions, stille Duplikate und kaskadierende Timeouts sind Symptome fehlender Infrastruktur, nicht schwacher Modelle.

Was Teams heute tun können

Die Debatte ist nicht entschieden, aber der Schwerpunkt verschiebt sich. "Welches Modell ist das beste?" wird abgelöst von "Wie sieht die Infrastruktur aus, die Agenten als System funktionieren lässt?" -- dieselbe Phase, in der Microservices vor zehn Jahren von Service-Calls zu Message-Bussen wechselten. Dass AI-Engineering diese Lektion in Monaten statt Jahren durchläuft, bedeutet vor allem: Man kann schneller falsch abbiegen.

Quellen

Nach oben