Agentic AI · Architecture · Module 11

Multi-Agent Trading Architectures Explained

Three published research frameworks divide the trading decision across agents in structurally different ways — a debate hierarchy, a scored contest allocator, and a layered-memory single agent. This page diagrams each one using the same source material cited on LLM Trading Research Landscape, and calls out the honest tradeoffs of each pattern rather than picking a winner.

Part of the Agentic AI module: Build an LLM Trading Agent (the from-scratch architecture guide) · LLM Trading Research Landscape · Do LLM Trading Agents Actually Work? · Commercial Agentic Trading Products.

Pattern 1 — Debate & Approval Hierarchy (TradingAgents)

TradingAgents (arXiv 2412.20138) structures its agents like a trading desk's org chart, with a built-in adversarial check: a bull researcher and a bear researcher argue opposite cases before any decision is made.

Hierarchy diagram: Analyst Team feeds both a Bull Researcher and a Bear Researcher, which converge into a Trader Agent, which feeds a Risk Management Team, which feeds a Fund Manager as final approval
Illustrative, from the TradingAgents paper's architecture description — not a measured backtest. Sequence: Analyst Team → Bull/Bear Researcher debate → Trader Agent → Risk Management Team → Fund Manager.

Tradeoff: the debate structure directly captures opposing viewpoints before synthesis, which a single-pass agent cannot do without being explicitly prompted to argue against itself. The cost is real: five distinct agent roles means five (or more) LLM calls per trading decision, and neither the paper nor its project site publishes an independently verified cost or latency figure for running the full pipeline live.

Pattern 2 — Scored Contest & Capital Allocation (ContestTrade)

ContestTrade (arXiv 2508.00554) takes a different approach: instead of one hierarchy producing one decision, multiple research paths run in parallel, and capital shifts toward whichever paths have the best recent track record.

Loop diagram: Data Team feeds Research Team, which feeds both a Quantify stage and a Predict stage, both of which feed an Allocate stage, which loops back with a curved arrow underneath to Research Team
Illustrative, from the ContestTrade paper's architecture description — not a measured backtest. The “Quantify-Predict-Allocate” loop: Data Team → Research Team → Quantify (score vs. outcome) + Predict (utility from past scores) → Allocate → back into the next Research Team cycle.

Tradeoff: allocating capital toward the currently-strongest-scoring agent is a meta-learning-style approach that can adapt as conditions change, but scoring only after outcomes resolve is inherently backward-looking — the same time-lag problem that affects any human portfolio manager reallocating capital toward a “hot hand.” A regime change can fool the allocator exactly as it can fool a human, right up until enough new outcomes accumulate to re-score the agents.

Pattern 3 — Layered Memory, Single Agent (FinMem)

FinMem (arXiv 2311.13743) is architecturally simpler than the other two: one agent, not a committee, with the sophistication concentrated in how it remembers rather than in how many agents check its work.

Loop diagram: Profiling feeds Layered Memory, which feeds Decision-Making, which loops back with a curved arrow underneath to Layered Memory
Illustrative, from the FinMem paper's architecture description — not a measured backtest. Profiling (agent character) → Layered Memory (hierarchical market context) → Decision-Making, with outcome feedback closing the loop back into Memory.

Tradeoff: a single agent is cheaper and lower-latency to run than a five-role hierarchy, but it has no built-in adversarial check the way TradingAgents' bull/bear debate does, and no capital-reallocation mechanism the way ContestTrade does — the memory design has to do all the work of avoiding a one-sided view. FinMem's reference implementation has not been updated since 2024-08-18, worth knowing before treating it as a maintained starting point rather than a research artifact.

What These Patterns Share With AlgoDrill's Own Build Guide

All three research patterns keep something structurally separate from raw LLM signal generation: TradingAgents has its Risk Management Team and Fund Manager sign-off, ContestTrade has its allocation mechanism, and FinMem leans most heavily on the LLM itself with the fewest built-in checks of the three. AlgoDrill's own Build an LLM Trading Agent guide teaches a single-agent pattern structurally closer to FinMem's simplicity, but adds a layer none of these three papers names as a distinct architectural component: hard, code-level guardrails (max position size, daily loss circuit breaker, confidence floor) that run after the LLM proposes a trade and before any order reaches the execution layer — the same agent-loop diagram referenced there shows guardrails as their own gating stage, not folded into the LLM's own reasoning.

What this page does not cover: a head-to-head performance comparison of these three architectures (none exists publicly as of this verification), and no diagram here is a reproduction of a measured backtest — each is illustrative, drawn from the cited paper's own architecture description. For what live benchmarks actually measured, see Do LLM Trading Agents Actually Work?.

Frequently Asked Questions

Which multi-agent trading architecture is best?
No public head-to-head benchmark compares TradingAgents, ContestTrade, and FinMem directly as of this page's verification. The closest available evidence is indirect: the When Agents Trade / Agent Market Arena benchmark found that agent architecture (single-agent versus multi-agent, with versus without memory) affected trading outcomes more than which LLM backbone powered the agent -- see Do LLM Trading Agents Actually Work? for the full finding. That supports 'architecture matters' as a general claim, not a ranking of these three specific designs.
Does adding more agents improve trading performance?
Not automatically, and none of the three papers on this page claim it does in isolation. More agents means more LLM calls per decision (cost and latency both scale with agent count), and a debate structure like TradingAgents' bull/bear researchers only helps if the debate actually surfaces information a single agent would have missed -- none of the three papers publish a controlled ablation isolating agent count from architecture design, so 'more agents' and 'better architecture' are not the same claim.
What is FinMem's cognitive span?
It is FinMem's term for how the Memory module's layered message processing is scoped -- the paper describes the memory design as aligning with the cognitive structure of human traders, with an adjustable span controlling how much hierarchical financial context the Decision-making module draws on for a given call. FinMem's reference GitHub implementation has not been updated since 2024-08-18, so treat the architecture as a citable research design rather than a maintained, ready-to-run tool.
Do any of these architectures place real trades?
TradingAgents, ContestTrade, and FinMem are research architectures evaluated in backtests and, for some benchmark papers built on similar designs, live paper-style evaluations -- none of the three papers describes a production live-brokerage deployment. For commercial products that do connect an agent to a real account today, see Commercial Agentic Trading Products. For a from-scratch architecture you build and run yourself against your own paper account, see Build an LLM Trading Agent.

See what independent live benchmarks found when they actually tested agents like these — or build the from-scratch, code-guardrailed version yourself.

Do They Actually Work? →   Build Your Own →