Letztes Jahr bauten wir für ein B2B-SaaS-Team einen „All-in-one-Support-Agenten“: ein System-Prompt mit Pre-Sales-, Support-, Angebots- und Troubleshooting-Persona plus zwanzig Seiten FAQ. In Woche eins glänzten die Metriken. In Woche drei jagte er Upsell-Leads in Erstattungstickets und schickte interne Codenamen an Kunden.
Niemand beschuldigte das Modell der Dummheit. Das Problem war schlicht: vier Schreibtische, ein Mitarbeiter. 2026 festigt sich der Konsens—Single Agents sind nicht tot, aber sie passen zu klaren Grenzen und kurzen Tool-Ketten. Sobald Recherche → Spec → Code → Test → Review → Release—also mehrstufige, parallele, sich gegenseitig korrigierende Arbeit—ansteht, lohnt sich eine Multi-Agent-Pipeline.
Kein Agenten-Lexikon, sondern der Migrationspfad aus OpenClaw, IDE-Agenten und internen PoCs. Wer Memory und Kosten schon prüft, lese Agent Memory vs. Chatverlauf und Team-Kosten für Agenten.
Single-Agent-Ära: stark im Rollenspiel, schwach in der Zusammenarbeit
Frühe Agenten-Produkte wetteiferten darum, wessen System-Prompt am expertenhaftesten klang und wessen Persona-Wechsel am smoothesten wirkte. „Senior Architect“, „scharfer Reviewer“, „geduldiger PM“ in Absätzen—das Modell wechselt den Ton in einem Thread. Das ist Single-Agent-Rollenspiel.
Vorteile: ein Deploy, kurze Traces, einfaches Debugging. Cursor, Claude Code und Custom GPTs trieben diese Spur 2024–2025 auf die Spitze.
Die Decke ist ebenso klar:
- Kontextverschmutzung—Notizen, Diffs und Testlogs teilen ein Fenster; spätere Schritte erben Rauschen.
- Unklare Verantwortung—bei Fehlern ist unklar, ob Planung oder Ausführung scheiterte; einzelne Stufen lassen sich nicht gezielt neu starten.
- Keine Parallelität—das Modell denkt linear, Teams recherchieren, implementieren und testen gleichzeitig.
- Schwer trennbare Rechte—Coding-Agent und Produktions-DB-Agent sollen nicht dasselbe Tool-Bundle nutzen; ein Prompt trennt das kaum fein.
Wird aus „eine Frage beantworten“ „einen mergebaren PR liefern“, bringt ein dickerer Prompt kaum noch Rendite. Kein Modellrückschritt—die Aufgabe wird ein Engineering-Problem mit Übergaben, Verträgen und Replay.
Multi-Agent-Ära: vom Ein-Mann-Theater zum Handshake-Protokoll
Multi-Agent-Kollaboration ändert die Metapher: nicht ein Schauspieler mit Masken, sondern mehrere Rollen auf der Bühne, verbunden durch Regie und Drehbuch. Planner zerlegt nur, Coder berührt nur erlaubte Pfade, Reviewer liest Diffs ohne „mal eben zwei Zeilen fixen“.
Abgleich über drei Mechanismen:
- Gemeinsamer Zustand—Pläne, Baum-Snapshots, Testergebnisse, Todos im Graph oder Memory Store, nicht im Chat verstreut.
- Strukturierte Übergaben—JSON, Patches, Checklisten; der Nachfolger konsumiert nur schema-konforme Felder, kein „siehe oben“.
- Abbruch und Schied—fertig, Eskalation zum Menschen, Rollback entscheidet Evaluator oder Regelknoten, nicht der letzte Agent.
Als wir den überladenen Support-Bot in Intent Router, FAQ Retriever, Ticket Writer und Escalation Guard splitteten, fielen Kunden-Mails mit internem Jargon auf null—nicht wegen eines neuen Modells, sondern weil Escalation Guard keine kundenorientierten Tools hatte.
Innenleben eines Agents: ReAct und Schichten
Vor dem Team-Split die Anatomie eines einzelnen Agenten verstehen. LangChain, OpenAI Agents SDK oder Cursor—2026 ähnelt das Skelett:
Von oben nach unten:
- Instruktionsschicht—System-Prompt,
AGENTS.md, Skills übersetzen Ziele in durchsetzbare Regeln. Skills sind wiederverwendbare Subroutinen vor dem Upgrade zur eigenen Node. - ReAct-Schleife—Reason → Tool → Observe. Bash, Browser, MCP, Search—das Herz.
- Tools & Runtime—Filesystem, Git, Sandbox-Grenzen. MCP ist 2026 De-facto-Standard.
- Deterministische Guardrails—Hooks, Middleware, Evaluatoren außerhalb der Schleife.
- Zustand & Speicher—Pläne, Logs, Memory Store speisen die nächste ReAct-Runde mit Realität statt Halluzination.
Multi-Agent wirft das Diagramm nicht weg—es dupliziert Kästen und verdrahtet sie im Graph. LangGraph trennt Thread-Nachrichten und Cross-Thread-Stores (Memory-Konzepte).
Pipeline-Muster: vier Topologien aus der Praxis
„Multi-Agent“ heißt nicht „mehr Köpfe“. Erst Topologie, dann Headcount:
| Topologie | Zusammenarbeit | Typischer Einsatz | Haupt-Risiko |
|---|---|---|---|
| Sequenzielle Pipeline | A → B → C, einseitig | Research → Spec → Code → Tests | Upstream-Fehler erzwingen Komplett-Retry; Checkpoints nötig |
| Supervisor–Worker | Supervisor verteilt, Worker meldet | Parallele Edits, Map-Reduce-Migrationen | Supervisor-Kontext wächst; Merge-Konflikte |
| Debatte / Review | Vorschlag + Kritiker-Runden | Security-Audit, Architekturwahl, Release Notes | Leerlauf-Debatten verbrennen Tokens; Rundenlimit |
| Mensch in der Schleife | interrupt an kritischen Knoten |
Prod-Change, Outbound-Mail, Billing | Zustand muss während menschlicher Wartezeit persistieren |
2026-Trend: deterministische Schritte aus dem LLM werfen. Format, Lint, Tests, Tags in CI oder Hooks; Agenten denken und entwerfen. Auf Cloud Mac läuft xcodebuild isoliert, während Agenten nur Diffs liefern—wie „Devs berühren Prod nicht“.
LangChains Multi-Agent-Konzepte modellieren Supervisor, Swarm und Handoff als Kanten—die Kante schlägt das Modell.
2026-Stack: Harness / Framework / Runtime
Ab drei Knoten in IDE, VPS oder Cron reicht „ein Python-Skript mit Prompts“ nicht. Drei Schichten:
Runtime (LangGraph)—welcher Knoten als Nächstes, wo Zustand liegt, wie Rollback funktioniert. LangGraph als Pregel-Supersteps für globales Scheduling.
Framework (LangChain)—Modelle, Tools, RAG als Bausteine ohne erzwungene Topologie.
Harness (DeepAgents & Co.)—Test, Deploy, Alignment mit Menschen; Wettbewerb 2026: wer liefert in Prod, nicht wer am schlausten klingt.
Landing-Checkliste
Minimum für interne Piloten—herstellerneutral:
- Zustandsgraph, kein Organigramm—Knoten sind Verben, Kanten sind Datenverträge.
- Schema pro Übergabe—JSON Schema für Teil-Retries.
- Minimale Tools pro Knoten—Reviewer read-only.
- Eine Trace-ID end-to-end.
- Speicher schichten—Thread, Session, RAG getrennt.
- Kosten pro Knoten budgetieren—großes Modell plant, kleines formatiert.
Auch Execution splitten: OpenClaw-Gateway auf VPS, xcodebuild und schwere Browser-Automation auf Cloud Mac—nicht ein Rechner als Gehirn und Muskel, der beim Zuklappen offline geht.
Häufige Fragen
Verschwinden Single Agents?
Nein. Kurze Ketten—Recherche, Einzeldatei, Mail-Entwurf—bleiben oft schneller mit einem Agenten plus Skills. Multi-Agent ist für komplexe Lieferung.
MCP und Skills?
MCP standardisiert Tools; Skills sind Module im Single Agent. In der Pipeline wird ein Skill zur eigenen Node, Tools bleiben per MCP geteilt.
Ist OpenClaw Multi-Agent?
Das Gateway kann leicht orchestrieren; volle Graph-Orchestrierung braucht meist LangGraph. OpenClaw glänzt als 24/7-Ausführungsfläche.
Teamarbeit braucht teamfähige Laufzeitumgebungen
Vom Single zum Multi-Agent heißt: unwartbare Prompts in beobachtbare Pipelines zerlegen. Planner, Worker, Reviewer brauchen unterschiedliche Rechte und Laufzeiten—nächster Schritt: Gateway auf VPS, Builds auf Cloud Mac, Memory im Vault.
VPSSpark Cloud Mac mini M4 für Worker mit langen Compiles; Linux VPS für OpenClaw. Schlauere Modelle stabilisieren Lieferung nicht automatisch—erst Architektur teamen, dann Rechenpower.
Erste Multi-Agent-Pipeline? Mac-Cloud-Tarife oder Startseite. Single-Ära trainierte Prompts; Multi-Ära trainiert Übergaben, Verträge, Replay.