mm.tech
agents··5 Min

Agent-Orchestrierungs-Patterns

Single Agent, sequenzielle Pipeline, Parallel-Fleet, Judge-arbitriert. Trade-offs aus dem Betrieb jeder Variante.

Ich habe im letzten Jahr vier Orchestrierungs-Patterns in Production geshipt. Jedes löst ein anderes Problem. Keines ist die richtige Antwort für jeden Job.

Single Agent: ein Modell-Call, eine Antwort. Keine Orchestrierung. Nimm wenn der Task in einen Prompt passt und das Modell smart genug ist. 90 % der "wir brauchen einen Agent"-Probleme sind das mit Extra-Schritten.

Sequenzielle Pipeline: Modell A produziert, Modell B reviewt, Modell C poliert. State fliesst linear. Nimm wenn jede Stage ein anderes Objective hat und jedes Modell sich spezialisieren soll. Trade-off: Latenzen stacken. Drei Stages à 3 s sind 9 s gesamt. User spüren das.

Parallel-Fleet: N Modelle nehmen das gleiche Problem aus verschiedenen Winkeln, Ergebnisse mergen. Nimm wenn Perspektiven-Diversität die Tiefe eines Einzelmodells schlägt. agent-fleet shipt das für Code-Review (Analyst plus Critic plus Research, alle sehen den gleichen Diff, schreiben drei Reports, ein Synthesis-Pass merged). Kosten stacken, Latenz bleibt Single-Stage. Trade-off: Synthese-Qualität zählt mehr als Einzel-Qualität.

Judge-arbitriert: Kandidaten produzieren, ein Judge ranked. Nimm wenn "best of N" das richtige Framing ist. darwin-agents shipt das für Prompt-Evolution, der Judge ist ein anderes Modell als die Producer. Trade-off: Judge-Bias wird zur versteckten Achse. Wenn dein Judge GPT-5 ist und deine Producer Claude, kriegst du GPT-5-Präferenzen.

Der Fehler den ich in Agent-Startup-Demos immer wieder sehe: Parallel-Fleet auf einem Problem das Single-Agent wollte. Drei Modelle die leicht unterschiedliche Antworten auf "fass diesen Artikel zusammen" geben ist nicht besser als ein Modell. Es ist schlechter weil du sie jetzt mergen musst und der Merge Rauschen einführt.

Cost-of-Orchestrierung-Heuristik: jedes zusätzliche Modell addiert 2x zur Rechnung, 1,5x zur Latenz und einen neuen Failure-Mode. Wenn die einfachere Version funktioniert, nimm die einfachere. Komplexität dann wenn du den konkreten Gewinn benennen kannst.

Das Pattern dem ich bei neuen Problemen am meisten vertraue: starte mit Single Agent, miss wo es kippt, add die minimale Orchestrierung die den Failure-Mode adressiert. Die meisten Projekte bleiben bei Single Agent oder sequenzieller Pipeline. Parallel-Fleet ist für Code-Review, Multi-Perspektiven-Recherche und Debatte-förmige Probleme. Judge-arbitriert ist für Prompt-Quality-Optimierung und Content-Grading.