ADR-0003: Multi-Agent-Architektur

Status
Proposed
Datum
2026-05-15
Decider
Malte (mit Claude)
Supersedes
Verwandt
ADR-0004 (Framework), ADR-0005 (Provider), ADR-0006 (Tools), ADR-0010 (Backtesting), ADR-0011 (Risk), ADR-0012 (Observability)
Tags
architecture, agents, core

Kontext

mvest ist ein AI Investment Research & Recommendation Assistant. Das System soll Aktien/ETFs (v1) und später Derivate (v2) recherchieren, quantitativ analysieren, Strategien vorschlagen und die Vorschläge auf Risiko bewerten. Es führt keine Trades aus — Outputs sind Reports, Empfehlungen und Backtests, die der Nutzer in einer Web-UI konsumiert und selbst entscheidet, ob er sie umsetzt.

Die Recherche- und Analyse-Pipeline besteht aus mehreren qualitativ unterschiedlichen Schritten (qualitative News-Recherche, quantitative Auswertung, strategische Synthese, kritisches Review, Risiko-Bewertung). Diese Schritte unterscheiden sich in benötigten Tools, akzeptabler Latenz, sinnvoller Modell-Wahl und Verifikationsstrategie. Ein einzelner monolithischer Agent würde diese Heterogenität nicht abbilden.

Eine zentrale Anforderung ist Output-Verifikation: LLMs halluzinieren, und im Investment-Kontext sind halluzinierte Zahlen oder erfundene News besonders gefährlich. Die Architektur muss deterministische und probabilistische Verifikations-Schichten einbauen können.

Entscheidungstreiber

Betrachtete Optionen

Option A — Single-Agent (Monolith)

Ein einziger LLM-Agent erhält die ganze Aufgabe ("recherchiere Tesla, analysiere quantitativ, schlage Strategie vor, prüfe Risiko") und produziert das Endresultat in einem Aufruf.

Simpel: ein Prompt, ein Modell, eine Antwort.

Keine Verifikations-Stufen, kein klar abgegrenzter Output pro Schritt, schwer auditierbar.

Keine Modell-Diversität — gleiches Modell entscheidet und prüft sich selbst.

Alle Tools beim selben Agent → Least-Privilege-Verletzung.

Kein Screener-Schritt → API-Kosten skalieren linear mit Universum-Größe.

Option B — Coordinator orchestriert DAG aus spezialisierten Sub-Agents

Ein Coordinator nimmt einen Trigger entgegen (Cron oder On-Demand), wählt die passende Workflow-DAG und ruft Sub-Agents in definierter Reihenfolge (teils parallel) auf. Jeder Sub-Agent hat eine klare Verantwortung, eigene Tools und ggf. eigenes Modell. Alle Outputs sind typisiert (Pydantic-Schemas) und landen im Decision-Log.

Klare Trennung von Concerns — jeder Schritt ist isoliert testbar und verifizierbar.

Modell-Diversität: Critic-Agent läuft auf anderem Provider/Modell als Strategy-Agent.

Tool-Permissions pro Agent durchsetzbar (Research darf Web-Search, Strategy nicht).

Erweiterbar — neue Agents werden als DAG-Knoten hinzugefügt.

Decision-Log fällt natürlich ab: jeder Agent-Output wird persistiert.

Mehr API-Calls insgesamt → höhere Kosten pro Lauf (insb. mit Critic).

Höhere Latenz pro Lauf — relevant für On-Demand-Trigger.

Erfordert ein Agent-Framework mit ordentlicher Multi-Agent-Unterstützung (Thema von ADR-0004).

Option C — Pub/Sub / Blackboard-Architektur

Agents abonnieren Events und posten Ergebnisse auf einen geteilten Blackboard-State; jeder Agent reagiert autonom, wenn seine Trigger-Bedingung erfüllt ist.

Sehr flexibel, Agents sind voneinander entkoppelt.

Reaktivität: ein neuer Event kann neue Pipelines auslösen.

State-Management wird komplex (wer schreibt was wann, wer liest was).

Schwer zu debuggen — keine offensichtliche Reihenfolge mehr.

Overkill für v1 — wir haben einen klaren Workflow, kein chaotisches Event-System.

Entscheidung

Wir wählen Option B: Coordinator orchestriert eine DAG aus spezialisierten Sub-Agents. Die Architektur balanciert Verifizierbarkeit, Modell-Diversität, Tool-Isolation und Auditierbarkeit und vermeidet gleichzeitig die Komplexität einer vollwertigen Event-Bus-Architektur.

Sub-Agents und Verantwortlichkeiten (v1)

AgentVerantwortungOutputModell-Profil
Coordinator Workflow-Orchestrierung. Nimmt Trigger + Watchlist entgegen, ruft Sub-Agents in der richtigen Reihenfolge auf, persistiert Endergebnis. Run-Summary mit verlinkten Sub-Outputs Mittel — wenig LLM-Aufwand, eher Code
Screener Reduziert große Watchlists/Universen auf eine Shortlist von Kandidaten basierend auf günstigen Filterkriterien (Marktkapitalisierung, Liquidität, simple Indikatoren, jüngste News-Aktivität). Shortlist (Tickers) mit Begründung Klein/günstig (z. B. Haiku / GPT-4o-mini)
Research Qualitative Recherche zu Shortlist-Items: News, Filings (10-K/Q/8-K), Earnings-Calls, Sentiment. Pflicht-Citations für jede Aussage. Research-Report mit Citations pro Item Mittel-Groß
Analyst Quantitative Auswertung: Technische Indikatoren (RSI, MACD, Bollinger), Fundamentaldaten (PE, P/B, Margin-Trends), Volatilitäts-Metriken. Daten kommen aus deterministischen APIs, nicht aus dem LLM. Quant-Snapshot pro Item Mittel (Daten-Aggregation, kein heavy Reasoning)
Strategy Synthetisiert Research- und Analyst-Outputs zu einer konkreten Strategie-Empfehlung (z. B. „Buy on dips below $X with 5% trailing stop"). Muss Backtest-Resultat im Output haben, sonst gilt der Vorschlag als unvollständig. Empfehlung mit Reasoning, Confidence, Backtest-Resultat Groß (z. B. Opus / GPT-4 / Gemini-Pro)
Critic Devil's Advocate gegen Strategy-Empfehlungen. Liest Strategy-Output, sucht aktiv nach Gegenargumenten, Datenlücken, Survivor-Bias im Backtest, Confirmation-Bias im Reasoning. Läuft auf einem anderen Provider/Modell als Strategy, um Halluzinations-Korrelation zu brechen. Critic-Review (Concerns, Counter-Evidence, Vertrauens-Adjustment) Groß, aber anderer Provider als Strategy
Risk-Assessment Bewertet die Strategie-Empfehlung quantitativ: erwarteter Drawdown, Volatilität, Korrelation zu bestehenden Watchlist-Items, hypothetische Positionsgröße. Kein Hard-Gate (es werden keine Trades platziert), sondern Info-Layer im Decision-Log. Risk-Profile als strukturiertes Metadatum Klein bis Mittel (überwiegend Tool-Use auf Daten)

Nicht in v1: Execution-Agent, Portfolio-Monitor (im Trade-Sinn), Broker-Anbindung. mvest gibt Empfehlungen, keine Orders. Diese Komponenten würden in einer späteren Phase (separate ADRs) hinzukommen.

Workflow-DAG

Der Standard-Workflow für einen Watchlist-Lauf:

flowchart TD Trigger["Trigger
(Cron oder UI-Button)"] --> Coord{"Coordinator"} Coord --> WL[("Watchlist
Konfiguration")] WL --> Screen["Screener Agent
Universum → Shortlist"] Screen --> Research["Research Agent
News, Filings, Sentiment
(mit Citations)"] Screen --> Analyst["Analyst Agent
Indikatoren, Fundamentaldaten
(via Daten-API)"] Research --> Strat["Strategy Agent
Empfehlung + Backtest"] Analyst --> Strat Strat --> Critic["Critic Agent
Devil's Advocate
(anderes Modell)"] Strat --> Risk["Risk-Assessment
Drawdown, Vola, Korr."] Critic --> Log[("Decision-Log
SQLite")] Risk --> Log Strat --> Log Research --> Log Analyst --> Log Log --> UI["Web-UI
mvest.malte.io"] classDef agent fill:#f0f3fa,stroke:#1e40af,stroke-width:1.5px,color:#1a1a1a classDef store fill:#f0f7f2,stroke:#15803d,stroke-width:1.5px,color:#1a1a1a classDef trigger fill:#fdf6e9,stroke:#a16207,stroke-width:1.5px,color:#1a1a1a class Screen,Research,Analyst,Strat,Critic,Risk agent class Log,WL store class Trigger trigger

Research und Analyst laufen parallel, da sie keine gegenseitigen Abhängigkeiten haben. Strategy ist der Sync-Punkt. Critic und Risk-Assessment laufen nach Strategy ebenfalls parallel.

Output-Verifikation: Schichten-Modell

Verifikation ist deterministisch wo möglich, probabilistisch nur wo nötig.

SchichtMechanismusGreift bei
1 Structured Outputs via Pydantic-Schemas. Schema-Validation = Format/Typen erzwungen. Jeder Agent, immer
2 Source-Grounding-Pflicht: jede Behauptung braucht Citation (URL, Filing-ID). Code prüft Erreichbarkeit / Existenz der Quelle. Research-Output
3 Quantitative Fact-Checks: alle Zahlen werden gegen Daten-API verifiziert (Analyst sagt „PE=28" → yfinance/Polygon-Check). Analyst-Output
4 Backtest-Forcing: Strategy-Empfehlung gilt nur als gültig, wenn ein Backtest-Resultat angehängt ist, das vom Backtest-Tool (deterministisch, kein LLM) berechnet wurde. Strategy-Output
5 Critic-Agent (anderes Modell): unabhängiges Review, sucht aktiv Gegenargumente. Strategy-Output
6 Risk-Assessment-Layer: bewertet quantitativ; in v1 nur informativ (kein Gate), aber im UI prominent angezeigt. Strategy-Output
7 Decision-Log: Reasoning, Inputs, Quellen, Modelle, Token-Counts persistiert. Audit-Trail. Immer, jeder Agent

Wichtig: Niemals nur LLM-prüft-LLM ohne Code-Anker. Critic ist eine Ergänzung zu deterministischen Checks, kein Ersatz.

State & Persistenz

Trigger & Scheduling (v1)

Konsequenzen

Positiv

Negativ / Trade-offs

Risiken

Offene Fragen / nachfolgende ADRs