← Alle Insights

Multi-Agent-Systems im Trading: orchestrierte KI-Workflows.

Statt einem LLM eine komplexe Aufgabe zu geben, koordinieren mehrere spezialisierte Agenten. Klingt elegant, ist faszinierend zu sehen — und in 2030 für produktives Trading immer noch grenzwertig. Was funktioniert, was nicht, und wo der Hype enttäuscht.

Was Multi-Agent-Systems eigentlich sind.

Ein Multi-Agent-System (MAS) besteht aus mehreren LLM-Instanzen mit jeweils klar definierter Rolle, Prompt, Tools und Verantwortlichkeit. Ein Orchestrator-Layer leitet Aufgaben zwischen ihnen — oft als gerichteter Graph, manchmal frei kommunizierend.

Die Idee dahinter: Spezialisierung reduziert Fehler. Statt ein Modell zu fragen „mach alles", bekommt jeder Agent einen engen Fokus, mit dem er besser umgehen kann. In der Theorie. In der Praxis hängt das stark vom Setup ab.

Vier Rollen, die im Trading-Kontext Sinn ergeben.

  1. Research-Agent: durchforstet News, Filings, Earnings-Transkripte. Liefert strukturierte Zusammenfassungen mit Quellen.
  2. Risk-Agent: bewertet Vorschläge gegen Portfolio-Limits, Korrelationen, Drawdown-Budgets. Hat Zugriff auf das aktuelle Portfolio und Risiko-Modelle.
  3. Execution-Agent: übersetzt Trade-Ideen in konkrete Order-Spezifikationen (Größe, Limit, Timing). Niemals mit Direktzugriff auf Order-APIs.
  4. Critic-Agent: bekommt die kombinierten Outputs der anderen und prüft sie auf Konsistenz, Halluzinationen, fehlende Risiken. Der wichtigste Agent — und der, der am häufigsten weggelassen wird.

In komplexeren Setups kommen weitere Rollen hinzu: ein Macro-Agent, ein Compliance-Agent, ein Documentation-Agent. Meine Erfahrung: ab fünf Agenten wird das System brüchig. Drei bis vier ist der Sweet-Spot.

Frameworks — und warum ich meist eigenen Code schreibe.

Für produktive Setups baue ich meist auf LangGraph oder direkt auf dem Anthropic-Agent-SDK auf — und ergänze um eigene Logging-, Cost-Tracking- und Replay-Module. Die generische Schicht von CrewAI/AutoGen kostet mehr Debugging-Zeit, als sie an Aufbau-Zeit spart.

Konkrete Architektur: ein morgendlicher Pre-Market-Workflow.

Ein realer Workflow, den ich für einen Mandanten implementiert habe — läuft jeden Handelstag um 07:00 Uhr Frankfurter Zeit:

[Orchestrator]
    |
    +-- [Macro-Agent]
    |       Tools: economic calendar API, futures snapshot,
    |              VIX-term-structure feed
    |       Output: Macro-Bias (risk-on / risk-off /
    |               neutral) + 3 Begruendungspunkte
    |
    +-- [Research-Agent] (parallel pro Watchlist-Asset, k=30)
    |       Tools: news feed, SEC EDGAR, earnings transcripts,
    |              RAG ueber eigenes Research-Archiv
    |       Output: pro Asset strukturiertes JSON
    |               (events_24h, sentiment, key_risks)
    |
    +-- [Risk-Agent]
    |       Tools: current positions, factor exposures,
    |              correlation matrix, drawdown stats
    |       Input:  alle Research-Outputs + Macro-Bias
    |       Output: Liste vorgeschlagener Trades mit Sizing
    |
    +-- [Critic-Agent]
    |       Input: vollstaendige Pipeline-Outputs
    |       Aufgabe: Halluzinationen pruefen, Quellen
    |                verifizieren, fehlende Risiken nennen
    |       Output: Freigabe / Aenderungs-Vorschlaege
    |
    +-- [Output]
            Markdown-Briefing per E-Mail an Trader 07:30.
            Mensch entscheidet, ob Trades ausgefuehrt werden.

Wichtig: kein Agent hat Schreibzugriff auf Order-Systeme. Der Output ist ein Briefing, das ein Mensch liest und freigibt. Das ist 2030 immer noch der einzige seriöse Modus für produktiven Einsatz.

Die drei Probleme, die kaum jemand löst.

1. Konsistenz zwischen Läufen.

Derselbe Input morgens und nachmittags liefert leicht unterschiedliche Outputs. Mit Temperature 0 wird es besser, aber nicht deterministisch — sub-token-level Variation bleibt. Für Auditierung und Reproduzierbarkeit ein echtes Problem. Lösung: jeden Lauf mit vollständigem Prompt-State, Modell-Version und Seed-Wert protokollieren.

2. Halluzinations-Kaskaden.

Wenn der Research-Agent halluziniert („Nvidia hat eine Earnings-Guidance gesenkt"), und der Risk-Agent das ungeprüft übernimmt, baut sich der Fehler im Workflow auf. Der Critic-Agent ist hier Pflicht — und auch er kann Fehler übersehen. Ohne strikte Quellen-Verifikation gegen externe Daten ist das System nicht produktionsreif.

3. Kosten und Latenz.

Ein vollständiger Lauf des oben beschriebenen Workflows kostet 3–8 € und braucht 5–12 Minuten. Für einen einmaligen Pre-Market-Lauf akzeptabel. Für intra-day-Wiederholungen wird es schnell teuer und langsam. Wer Multi-Agent in 1-Minuten-Intervallen laufen lassen will, hat den falschen Ansatz gewählt.

Ehrliche Bewertung — 2030.

Multi-Agent-Systems sind faszinierend. Sie zu beobachten, wie sie aufeinander reagieren, Argumente austauschen, Fehler korrigieren, hat etwas Hypnotisches. Aber: für produktives Trading sind sie 2030 noch nicht der Default. Was funktioniert:

Was nicht funktioniert: autonomes Order-Setzen, Echtzeit-Reaktionen auf Markt-Events, irgend etwas, wo Konsistenz und Determinismus zentral sind. Wer das versucht, hat in zwei Jahren eine teure Lektion und ein Compliance-Problem.

Mein Rat: starten Sie mit einem Single-Agent-Setup. Erst wenn der Anwendungsfall wirklich mehrere getrennte Rollen rechtfertigt — und der einzelne Agent an Komplexität scheitert — lohnt der Sprung zu Multi-Agent. Architektur folgt Schmerz, nicht Mode.

Sie überlegen, einen Multi-Agent-Workflow für Research oder Pre-Market-Analysen aufzusetzen? Erstgespräch buchen — wir prüfen, ob Ihr Use-Case wirklich Multi-Agent braucht oder ob ein gut gebauter Single-Agent reicht.