← Alle Insights

Agenten-Orchestrierung am Research-Desk Spezialisten statt Alleskönner.

Der Reflex, einen einzigen großen Prompt zu bauen, der „alles kann“, ist verständlich — und führt im Research selten zu guten Ergebnissen. Ein Mega-Prompt, der gleichzeitig Fundamentaldaten interpretieren, News einordnen, Makro-Kontext liefern und daraus ein Urteil ableiten soll, wird unübersichtlich, schwer zu testen und liefert mittelmäßige Antworten auf jeder Teilaufgabe. Die Alternative ist eine Architektur aus spezialisierten Agenten: einer für Fundamentals, einer für News, einer für Makro, dazu ein Koordinator, der die Teilergebnisse zusammenführt. Jeder Agent hat einen engen Auftrag, einen passenden Werkzeugkasten und einen Prompt, der nur seine Aufgabe betrifft — und ist dadurch besser, testbarer und kontrollierbarer. Dieser Beitrag erklärt, wie eine solche Orchestrierung am Research-Desk aufgebaut wird: wie Handoffs zwischen Agenten funktionieren, wie geteilter Speicher und Eskalation organisiert sind, welche Kosten und Latenzen realistisch sind — und wo die Komplexität eines Multi-Agent-Systems den Nutzen wieder auffrisst.

Warum ein Spezialisten-Team den Alleskönner schlägt.

Ein Sprachmodell mit einem klar umrissenen Auftrag arbeitet zuverlässiger als dasselbe Modell mit einem überladenen. Das hat mehrere Gründe. Ein enger Prompt lässt weniger Raum für Abschweifungen und Halluzinationen. Ein spezialisierter Agent kann mit genau den Werkzeugen und Datenquellen ausgestattet werden, die seine Aufgabe braucht — der Fundamental-Agent mit Zugriff auf Bilanzdaten, der News-Agent mit einer Nachrichten-API. Und jeder Agent lässt sich einzeln testen und verbessern, ohne das ganze System zu destabilisieren.

Der Vergleich zum menschlichen Research-Desk liegt nahe und ist treffend: Auch dort sitzt nicht eine Person, die alles macht, sondern ein Team aus Spezialisten, das ein Koordinator zusammenführt. Die Agenten-Architektur bildet diese bewährte Arbeitsteilung nach.

Der Preis dieser Klarheit ist Komplexität an anderer Stelle: Mehr Teile bedeuten mehr Schnittstellen, mehr Fehlerquellen, mehr Latenz. Ob sich der Aufwand lohnt, hängt von der Aufgabe ab — für eine simple Zusammenfassung ist ein einzelner Agent fast immer besser.

Die Rollen am Desk.

Eine bewährte Aufteilung für ein Research-System umfasst drei bis fünf spezialisierte Agenten plus einen Koordinator. Die genaue Zahl hängt von der Tiefe ab, die gefragt ist.

AgentAuftragTypische Werkzeuge
FundamentalBilanzen, Kennzahlen, Bewertung einordnenFinanzdaten-API, Berechnungstools
Newsaktuelle Meldungen sammeln, einordnen, gewichtenNachrichten-API, Datums-/Quellfilter
MakroZinsen, Konjunktur, Sektor-Kontext liefernMakrodaten, Kalender
KoordinatorTeilergebnisse zusammenführen, Widersprüche markieren, Frage beantwortenZugriff auf alle Agenten-Outputs

Entscheidend ist, dass der Koordinator nicht selbst recherchiert. Seine Aufgabe ist die Synthese: Er fragt die Spezialisten, sammelt deren Befunde, erkennt Widersprüche und formuliert die Antwort. Diese Trennung — Recherche bei den Spezialisten, Urteil beim Koordinator — hält das System sauber.

Handoffs — wie Agenten Arbeit übergeben.

Der heikelste Teil jeder Orchestrierung ist die Übergabe zwischen Agenten. Wird sie schlampig gebaut, gehen Informationen verloren, oder die Agenten reden aneinander vorbei.

Es gibt zwei Grundmuster. Beim orchestrierten Ansatz steuert der Koordinator zentral: Er ruft die Spezialisten gezielt auf, übergibt jedem einen präzisen Teilauftrag und sammelt die Ergebnisse ein. Das ist kontrollierbar und nachvollziehbar — und für Research meist die richtige Wahl. Beim autonomen Ansatz übergeben Agenten direkt aneinander, je nachdem, was sie für nötig halten. Das ist flexibler, aber deutlich schwerer zu kontrollieren und zu debuggen.

Für ein produktives Research-System, bei dem Nachvollziehbarkeit zählt, ist der orchestrierte Ansatz fast immer vorzuziehen. Jeder Handoff sollte ein definiertes Format haben: Was wird übergeben, in welcher Struktur, mit welcher Quellenangabe. Lose, freitextliche Übergaben sind die häufigste Ursache für Qualitätsverlust in Multi-Agent-Systemen.

Geteilter Speicher und Quellentreue.

Agenten, die zusammenarbeiten, brauchen einen gemeinsamen Kontext — aber nicht jeden Kontext für jeden. Ein geteilter Speicher, in dem Zwischenergebnisse mit Quellenangabe abgelegt werden, hat sich bewährt. Jeder Agent schreibt seine Befunde dort hin, der Koordinator liest sie aus.

Entscheidend ist die Quellentreue über die ganze Kette. Wenn der Fundamental-Agent eine Kennzahl meldet, muss die Quelle mitgeführt werden, sodass der Koordinator und am Ende der menschliche Nutzer nachvollziehen können, woher die Zahl stammt. Geht die Quelle bei einem Handoff verloren, entsteht eine Aussage ohne Beleg — und damit eine ideale Brutstätte für unbemerkte Halluzinationen.

Praktisch heißt das: Jeder Befund im geteilten Speicher trägt eine Herkunft. Der Koordinator gibt am Ende nicht nur ein Urteil aus, sondern eine belegte Argumentation. Genau das unterscheidet ein vertrauenswürdiges Research-System von einem, das überzeugend klingende, aber unbelegte Texte produziert.

Eskalation und das Eingeständnis von Unsicherheit.

Ein gutes Agenten-System muss wissen, wann es nicht weiterweiß — und das sagen. Drei Eskalationspfade sind wichtig.

Der häufigste Fehler bei Multi-Agent-Systemen ist falsche Zuversicht: Das System liefert eine glatte, überzeugende Antwort, obwohl die zugrundeliegenden Daten dünn oder widersprüchlich waren. Eine ehrliche Eskalationslogik ist das wichtigste Gegenmittel.

Kosten, Latenz und der Komplexitätspreis.

Ein Multi-Agent-System ist teurer und langsamer als ein einzelner Aufruf. Jeder Agent ist ein eigener Modellaufruf, oft mehrere pro Aufgabe; der Koordinator kommt obendrauf. Für eine durchschnittliche Research-Frage summieren sich schnell fünf bis fünfzehn Modellaufrufe.

In der Praxis bedeutet das: Eine Anfrage, die ein einzelner Agent in Sekunden beantwortet, kann im orchestrierten System eine bis mehrere Minuten dauern und ein Vielfaches kosten. Für ein interaktives Tool, das eine Antwort in Echtzeit erwartet, ist das relevant; für eine vorbereitende Analyse über Nacht spielt es kaum eine Rolle.

Der ehrliche Rat: Bauen Sie nicht mehr Agenten, als die Aufgabe braucht. Jeder zusätzliche Agent erhöht Kosten, Latenz und Fehlerfläche. Viele Aufgaben, die nach einem Multi-Agent-System rufen, lösen sich mit zwei gut gebauten Agenten genauso gut wie mit sieben. Die Architektur sollte der Komplexität der Aufgabe folgen, nicht dem Reiz des technisch Möglichen.

Einstieg und schrittweiser Ausbau.

Ein sinnvoller Start ist nicht das vollständige Desk, sondern ein einzelner gut funktionierender Spezialist — etwa ein Fundamental-Agent, der eine konkrete, wiederkehrende Aufgabe verlässlich erledigt. Erst wenn dieser sauber läuft und getestet ist, kommt der zweite Agent dazu, dann der Koordinator.

Dieser inkrementelle Aufbau hat einen praktischen Grund: Multi-Agent-Systeme sind schwer zu debuggen, weil Fehler sich durch die Kette fortpflanzen. Wer alles auf einmal baut, weiß bei einem schlechten Ergebnis nicht, welcher Agent versagt hat. Wer Stück für Stück erweitert, behält die Kontrolle.

Realistisch dauert es einige Wochen bis wenige Monate, bis ein orchestriertes Research-System produktiv nutzbar ist — der Großteil der Zeit fließt nicht in die Agenten selbst, sondern in Handoff-Formate, Quellenführung, Eskalationslogik und Tests. Genau diese unscheinbaren Teile entscheiden, ob das System dem Analysten wirklich Arbeit abnimmt oder nur eine beeindruckende Demo bleibt.

Sie überlegen, Ihr Research mit einem Team spezialisierter KI-Agenten zu unterstützen, statt mit einem unübersichtlichen Mega-Prompt? Unverbindlich anfragen — wir entwerfen eine Orchestrierung, die zu Ihren Datenquellen passt, mit sauberen Handoffs, Quellentreue und ehrlicher Eskalation.