Orchestrierung ist in diesem Jahr das am meisten benutzte und am wenigsten verstandene Wort in KI-Projekten. Es klingt nach Kontrolle. In der Praxis bedeutet es: jemand muss sich um die Dinge kümmern, die passieren, wenn ein Agent einen anderen ruft, dieser scheitert, ein dritter wartet und ein Mensch gefragt wäre, der gerade im Meeting sitzt.
Wann Sie überhaupt orchestrieren müssen
Die meisten Vorhaben brauchen keinen Multi-Agenten-Verbund. Ein einzelner Agent mit Werkzeugen erledigt 80 Prozent der Fälle, die tatsächlich Geld sparen. Orchestrierung wird erst nötig, wenn eine Aufgabe mehrere Zuständigkeiten berührt, asynchron laufen muss oder verschiedene Modelle ihre jeweiligen Stärken ausspielen sollen.
| Situation | Ein Agent | Orchestrierung |
|---|---|---|
| Ein klarer Ablauf, eine System | Reicht völlig | Überdimensioniert |
| Mehrere Systeme, klare Reihenfolge | Reicht mit Werkzeugen | Erst bei Ausnahmen nötig |
| Teilaufgaben parallelisierbar | Reihenfolge wird langsam | Sinnvoll |
| Verschiedene Modelle pro Schritt | Unflexibel | Sinnvoll |
| Menschliche Freigabe zwischendurch | Abbrechbar | Sinnvoll mit Zustandsverwaltung |
Die drei Dinge, die jedes System braucht
Sobald ein zweiter Agent ins Spiel kommt, haben Sie ein verteiltes System. Verteilte Systeme ohne die folgenden drei Bausteine werden unzuverlässig – nicht selten, sondern verlässlich unzuverlässig.
- 01Zustand: Jeder Schritt muss fortsetzbar sein, auch nach einem Abbruch. Wer das nicht hat, beginnt nach jedem Fehler von vorn.
- 02Schnittstellen-Verträge: Ein Agent muss wissen, was der andere liefert – nicht hoffen, dass das Format passt.
- 03Abbruch und Rückfall: Ein Timeout, das nicht terminiert, blockiert die ganze Kette. Ein Rückfallpfad ist kein Luxus, sondern die Voraussetzung für Betrieb.
Ein Agent, der wartet, ohne zu melden, dass er wartet, ist kein Agent mehr – er ist ein Problem, das noch niemand bemerkt hat.
Das häufigste Architekturmissverständnis
Teams bauen einen „Supervisor-Agenten“, der alles koordiniert – und geben ihm dann zu viel Verantwortung. Ein Koordinator, der entscheidet, merkt, entscheidet neu und merkt erneut, wird zum Flaschenhals. Besser: Der Koordinator verteilt, die Worker entscheiden selbst in ihrem Rahmen, und ein Mensch sieht nur Abweichungen.
Was im Hackathon spielbar wird
Orchestrierung lernt man nicht aus Architekturdiagrammen, sondern aus dem Moment, in dem der eigene Prototyp steht und die zweite Kette nach einer Stunde noch immer läuft. Genau dieser Moment – zwei bis drei Agenten, die an einem echten Use Case zusammenarbeiten – ist ein hervorragender Hackathon-Inhalt, weil er die Fragen zutage fördert, die in Präsentationen niemand stellt.
- Wann meldet sich ein Agent, wann wartet er schweigend?
- Was passiert, wenn ein Werkzeug länger als 30 Sekunden nicht antwortet?
- Wer bekommt die Rechnung, wenn ein Agent eine falsche Handlung vollzieht?
- Wie sieht der Mensch, dass etwas schiefgelaufen ist – ohne zwanzig Logs zu lesen?
Wer diese Fragen einmal an einem eigenen Prototyp beantworten musste, redet danach anders über Agenten – nüchterner und konkreter. Genau das ist das Ziel.