„” Dieser Satz fällt in fast jedem zweiten Kickoff. Die Ursache ist meist nicht das Modell — es ist die Architektur. Ein einzelner Bot soll alles können: erkennen, entscheiden, abrufen, schreiben, eskalieren. Das funktioniert für FAQ. Für Prozesse nicht.
Das Einzelbot-Problem
Ein Agent, der jede Domäne beherrschen muss, leidet an drei Symptomen:
- Prompt-Inflation — der Systemprompt wird zur Enzyklopädie und das Modell verliert den Fokus.
- Tool-Auswahl wird schwammig — bei 30 verfügbaren Tools trifft das LLM oft die falsche Wahl.
- Keine klare Verantwortung — wenn ein Schritt schiefgeht, ist nicht nachvollziehbar, wer ihn entschieden hat.
Spezialisierte Agenten + Orchestrator
Statt einem Generalisten arbeiten in einem produktiven System vier bis sechs spezialisierte Agenten zusammen. Jeder hat eine eng definierte Aufgabe:
- Klassifikations-Agent — versteht die Absicht und routet an den richtigen Spezialisten.
- Datenabruf-Agent — kennt RAG/CAG-Strategie und Wissensquellen.
- Entscheidungs-Agent — wendet Regeln und Policies an, prüft Genehmigungen.
- Tool-Use-Agent — führt die eigentliche Aktion in ERP, CRM, DMS durch.
- Eskalations-Agent — übergibt an einen Menschen, wenn definierte Kriterien greifen.
Der Orchestrator selbst ist kein „”. Er ist ein dünner Layer (in der Praxis oft LangGraph oder ein eigener State-Machine-Builder), der Hand-Offs, Memory und Eskalationen verwaltet — aber selbst keine fachlichen Entscheidungen trifft.
Hand-Off-Regeln machen den Unterschied
Was ein Multi-Agent-System produktionsreif macht, ist nicht die Anzahl der Agenten — es sind klare Hand-Off-Regeln. Gute Übergaben folgen drei Prinzipien:
Explizit statt implizit: Jede Übergabe enthält den vollen Kontext, der für den Empfänger relevant ist — nicht „”.
Eindeutige Eskalationskriterien: „”, „”, „” — keine Bauchentscheidungen.
Reversibel: Wer übergibt, kann zurücknehmen. Das verhindert, dass Vorgänge in Schwebezuständen verloren gehen.
State-Management ist keine Option
Multi-Agent-Systeme funktionieren nur mit persistentem State. Konversationen erstrecken sich über Tage und Wochen. Ohne Memory wird jeder Übergang zu einer neuen Sitzung — der Endkunde merkt das sofort.
In unseren Implementierungen kombinieren wir typischerweise pgvector (für semantisches Memory), Redis (für kurze Sessions und Locks) und PostgreSQL (für strukturierte Workflow-States). Welche Kombination zum Einsatz kommt, hängt vom Workload ab — nicht von der Lieblings-DB des Entwicklers.
Frameworks — passend zum Use Case
Es gibt kein bestes Agent-Framework. Es gibt nur das passende. Unsere Faustregeln:
- LangGraph für stateful Workflows mit verzweigten Pfaden.
- AutoGen für Konversations-orientierte Multi-Agent-Setups.
- CrewAI für rollenbasierte Teams mit klaren Verantwortlichkeiten.
- LangChain als Tool-Use-Layer — oft kombinierbar mit den anderen.
Fazit
Agent-Teams sind keine technische Spielerei — sie sind die Antwort auf das skalierungsproblem von Einzelbots. Wer Multi-Agent richtig aufsetzt, gewinnt nicht 10 %, sondern den Faktor 2 bis 3 bei Automatisierungsquote und Reaktionszeit.