Multi-Agenten-Systeme: Orchestrierer + Subagenten in der Praxis

Ein einzelner KI-Agent meistert eine enge Aufgabe gut. Wenn das Szenario wächst - Tickets, Dokumente, Code, CRM, Support - beginnt ein „universeller“ Agent, Rollen zu vermischen, den Kontext aufzublähen und bei jedem Schritt teurer zu werden. Ein Multi-Agenten-System löst das anders: Ein Orchestrierer übernimmt das Ziel und koordiniert die Arbeit, während Subagenten enge Rollen mit eigenen Tools und Anweisungen ausführen. Unten - wie das in der Praxis funktioniert, wann sich das Muster lohnt und welche Fehler einen Pilotversuch zunichtemachen.

• Orchestrierer - Plan, Routing, Limitkontrolle und Zusammensetzen des Ergebnisses
• Subagenten - enge Rollen: Research, Code, Review, Schreiben, CRM
• Kontext - jeder Agent bekommt nur das, was er für seinen Schritt braucht
• Kontrolle - Human-in-the-Loop bei kritischen Aktionen
• Start - 2-4 Rollen und ein messbares Szenario, kein „Agenten-Zoo“
• Risiko - Endlosschleifen, Tool-Races und verwischte Verantwortlichkeiten

Was ein Multi-Agenten-System ist

Ein Multi-Agenten-System ist eine Architektur, in der mehrere KI-Agenten unter einem Koordinator gemeinsam eine Aufgabe lösen. Im Gegensatz zu einem Agenten mit „fettem“ Prompt für jeden Fall sind die Rollen getrennt:

Dieselbe Idee kennt man schon aus der Workflow-Automatisierung: Es gibt einen Dispatcher und Worker. Der Unterschied: Schritte und Verzweigungen wählt teilweise ein LLM, nicht nur harte If-Then-Regeln.

Warum Orchestrierer und Subagenten trennen

Ein Agent mit Zugriff auf jede API wirkt praktisch - und wird schnell zum Problem:

• Der Kontext bläht sich auf. In einem Dialog vermischen sich Logs, Mail-Entwürfe, Code-Schnipsel und CRM-Exporte - das Modell verliert den Fokus.
• Die Kosten steigen. Jeder zusätzliche Token im „gemeinsamen“ Chat wird bei jedem Zug bezahlt.
• Die Rechte sind zu weit. Ein Agent, der Code schreibt und dem Kunden mailt, ist riskanter als ein enger Worker.
• Schwerer zu debuggen. Wenn alles in einer Schleife lebt, ist unklar, was kaputtging: der Plan, das Tool oder die Formulierung.

Die Rollentrennung bringt:

1. Einen engen System-Prompt pro Subagent - weniger Halluzinationen „außerhalb der Rolle“.
2. Ein separates Tool-Set - ein Researcher kann nicht versehentlich ein CRM-Geschäft löschen.
3. Parallelität - mehrere Subagenten können gleichzeitig arbeiten (Suche + Entwurf + Fact-Check).
4. Observability - Logs zeigen, wer mit welchem Input und welchem Output aufgerufen wurde.

Basisdesign: Orchestrierer + Subagenten-Pool

Ein praktisches Minimalskelett:

User / trigger
        │
        ▼
   Orchestrator
   (plan, routes, limits)
        │
   ┌────┼────┬────────┐
   ▼    ▼    ▼        ▼
 Research  Coder  Reviewer  Writer
   │    │    │        │
   └────┴────┴────────┘
        │
        ▼
   Summary + artifacts
   (+ human approval on risk)

Was der Orchestrierer tut

• nimmt Ziel und Constraints entgegen (Zeit, Token-Budget, Verbote);
• wählt, welche Subagenten in welcher Reihenfolge aufgerufen werden;
• übergibt jedem ein komprimiertes Briefing, nicht den gesamten Roh-Chat;
• erzwingt Schrittlimits und stoppt Schleifen;
• setzt das Ergebnis im Format zusammen, das das Business braucht (Report, Diff, Deal-Karte).

Der Orchestrierer kann „dünn“ (nur Routing) oder „dick“ (plant und plant selbst um) sein. Für Business gewinnt meist ein dünner Orchestrierer + starke enge Subagenten: leichter zu testen und günstiger unter Kontrolle zu halten.

Typische Subagenten in Business- und Dev-Szenarien

Am ersten Tag braucht man nicht jede Rolle. Für einen Pilot reichen meist nur Orchestrierer + 2-3 Subagenten.

Wann sich das Muster wirklich lohnt

Multi-Agenten-Design lohnt sich, wenn mindestens zwei Punkte zutreffen:

• die Aufgabe ist zusammengesetzt (mehrere Skills: Suche + Synthese + Aktion);
• Sie brauchen unterschiedliche Zugriffsrechte auf Systeme;
• das Kontextvolumen ist groß - ein Agent „passt“ ohne Qualitätsverlust nicht;
• Sie brauchen einen separaten Reviewer, nicht die Selbstprüfung des Autors;
• das Szenario wiederholt sich und lässt sich als rollenbasiertes Pipeline beschreiben.

Praktische Beispiele

1. Support: Orchestrierer → Research (Wissensbasis/RAG) → Writer (Antwort) → Mensch genehmigt den Versand.
2. Leads und CRM: Qualifizierung → Anreicherung → Schreiben ins CRM → Aufgabe für den Manager; kritische Felder prüft ein Mensch oder eine Regel.
3. Entwicklung: Orchestrierer in Cursor / Agent-Runtime → Explore-Subagent → Coder → Reviewer; Deploy nur nach Freigabe.
4. Content und GEO: Themen-Research → Writer → Fact-Check-Subagent → Veröffentlichen nach Checkliste.
5. Operations: Eingehende Mail parsen → klassifizieren → Aktionen über n8n/API → Ausnahmen an einen Menschen eskalieren.

Ist die Aufgabe ein einfaches If-Then („Formular abgeschickt → Deal anlegen“), sind Multi-Agenten Overkill: besser native Automatisierung oder n8n.

Rollen an einem Tag designen

Eine kurze pragmatische Checkliste:

1. Happy Path auf Papier beschreiben: Input → 3-6 Schritte → Output-Artefakt.
2. Rollen nach Verben benennen: „finden“, „prüfen“, „schreiben“, „ins CRM schreiben“ - nicht „smarter Agent #3“.
3. Pro Rolle festlegen: Input, Output (Schema/JSON), Tools, Verbote.
4. Entscheiden, wer orchestriert: LLM-Planner oder deterministischer Graph (oft Hybrid: Graph + LLM in den Nodes).
5. Human-in-the-Loop dort einbauen, wo Fehler teuer sind.
6. Stoppbedingungen setzen: max. Schritte, max. Kosten, Timeout, „wenn unsicher - eskalieren“.

Ein Subagenten-Vertrag schlägt einen „schönen Prompt“

Ein guter Vertrag:

• Input: { task, constraints, sources[] }
• Output: { status, summary, artifacts[], confidence, needs_human }
• Verbot: „keine URLs erfinden“, „Prod nicht ändern“, „Kunden nicht direkt mailen“

Dann kann der Orchestrierer Antworten zuverlässig mergen und entscheiden, wen er als Nächstes aufruft.

Orchestrierungsmuster, die funktionieren

Für KMU reichen meist Pipeline + Dispatcher. „Agenten-Debatten“ wirken in Demos stark und werden in Production ohne hartes Token-Budget teuer.

Kontrolle, Sicherheit und Kosten

Ein Multi-Agenten-System ohne Guardrails wird schnell zu einem teuren chaotischen Bot.

Mindestens nötig:

• Separate API-Keys und Rechte pro Rolle (Least Privilege).
• Limits: Schritte, Tokens, Parallelität, Timeouts.
• Idempotente Aktionen (ein Retry darf nicht 5 Deals anlegen).
• Audit-Log: wer → mit welchem Input → welches Tool → welcher Output.
• Secrets außerhalb des Prompts: Vault, Env - nicht „Token in die System Message kleben“.
• menschliche Freigabe für irreversible Aktionen: Zahlungen, Löschen, Mailings, Prod-Deploy.

Bei den Kosten zählen Sie nicht den „Modellpreis“, sondern den Kettenpreis: Orchestrierer × N Subagenten-Aufrufe × Retries. Manchmal ist ein starker Call mit gutem Kontext günstiger als fünf schwache, die JSON hin- und herschieben.

Häufige Umsetzungsfehler

• 10 Subagenten „für später“ anlegen, ohne ein funktionierendes Szenario.
• Allen denselben Zugriff auf alle Tools geben.
• Dem Subagenten das volle Orchestrierer-Log statt eines kurzen Briefings geben.
• Schleifen nicht begrenzen - Orchestrierer und Reviewer streiten ewig.
• Multi-Agenten-Design als Ersatz für den Prozess behandeln: ohne klares Definition of Done imitiert das System Beschäftigungstherapie.
• Mit Vibe Coding verwechseln: „die Agenten sollen das schon klären“ ohne Rollen und Verträge - der Weg in technische Schulden.

Wie man einen 2-3-Wochen-Pilot startet

1. Ein Szenario mit messbarem KPI wählen (Antwortzeit, Fehlerrate, Manager-Minuten).
2. Orchestrierer + zwei Subagenten bauen (z. B. Research + Writer, oder Coder + Reviewer).
3. Input-/Output-Verträge und eine Eskalations-Checkliste für Menschen einfrieren.
4. 20-50 echte Fälle durchlaufen und Fehler nach Typ labeln.
5. Erst dann eine dritte Rolle oder Parallelität ergänzen.

Als Tooling eignet sich ein Agent-Framework (LangGraph, Crew-ähnliche Setups, IDE-Runtime), eine Brücke zu n8n für deterministische Kanten oder custom Python. Die Rollenarchitektur zählt mehr als das Framework-Logo.

Fazit

Orchestrierer + Subagenten ist ein funktionierendes Muster, wenn die Aufgabe größer ist als ein Skill und Sie unterschiedliche Rechte, Kontexte und Qualitätschecks brauchen. Die Stärke liegt nicht in der Zahl der Agenten - sondern in klaren Rollen, engen Tools und harten Stops. Starten Sie mit einer kleinen Schleife und einem messbaren Szenario: so wird ein Multi-Agenten-System zum Hebelfaktor für Tempo, nicht zum teuren Theater der Autonomie.

Häufig gestellte Fragen

Worin unterscheidet sich ein Multi-Agenten-System von einem Agenten mit langem Prompt?

Ein Agent mit langem Prompt versucht, in einem Kontext und einem Rechte-Set „alles auf einmal“ zu sein. Multi-Agenten-Design teilt Rollen: Der Orchestrierer koordiniert, Subagenten arbeiten eng. Das ist leichter zu steuern, bei langen Ketten günstiger in Tokens und sicherer, weil jeder Worker eine kleinere Zugriffsfläche hat.

Braucht man immer einen LLM-Orchestrierer?

Nein. Oft ist ein deterministischer Graph (State Machine / Workflow) besser, und das LLM lebt in den Nodes. Ein LLM-Orchestrierer lohnt sich, wenn der Input unstrukturiert ist und die Route nicht im Voraus hard-codiert werden kann. Hybrid ist die häufigste Production-Wahl.

Wie viele Subagenten sind am Anfang optimal?

Meist 2-4. Ein Orchestrierer plus Research und Writer ist schon eine funktionierende Schleife für Content und Support; Coder und Reviewer - für Entwicklung. Mehr Rollen ergeben erst Sinn, wenn der Pilot KPI zuverlässig trifft und die Logs lesbar sind.

Wie vermeidet man, Token-Budget zu verbrennen?

Briefings komprimieren, „ganzen Dialog nacherzählen“ verbieten, den stabilen System-Prompt cachen, max. Schritte deckeln, nur dort parallelisieren, wo die Wall-Time sinkt - nicht zur Show. Messen Sie die Kosten des End-to-End-Szenarios, nicht einer schönen Demo-Antwort.

Braucht man trotzdem einen Menschen in der Schleife, wenn Agenten „smart“ sind?

Ja, bei Risiken. Ein Modell hebt die Verantwortung für Geld, personenbezogene Daten, rechtliche Formulierungen und Production nicht auf. Human-in-the-Loop ist keine Architektur-Schwäche - sondern die Bedingung, unter der Business Agenten überhaupt an echte Systeme lässt.