Multi-agent setups and why they compound risk
Splitting a trading assistant into several specialised agents — one reading the market, one sizing, one executing — looks like good architecture. Applied to non-deterministic components holding order tools, it makes every problem worse.
The instinct is sound and the application is not, for reasons worth being specific about.
Non-determinism multiplies
One model is a distribution over outputs. Three models in sequence is a distribution over distributions.
If each agent behaves as intended 95% of the time, three in sequence behave as intended about 86% of the time — and the failures are now spread across component boundaries where they are harder to attribute.
Worse, you cannot test the composition the way you would test a pipeline of functions. Each stage samples, so a single evaluation run is a sample of the whole chain, and the number of runs needed to characterise it grows with the number of stages.
Each handoff is an untrusted channel
This is the serious one.
Agent A’s output becomes Agent B’s input. From B’s perspective that text is exactly as authoritative as your instructions, because a context window does not distinguish by origin — see prompt injection when the model can place orders.
So if A ingests anything untrusted — a news page, a scraped forum, a tool result — that content can propagate through B to an order, and B has no way to know it did not come from you.
A multi-agent chain turns one context boundary into several, and every one of them is a place where instruction and data get confused. The defence that works for a single agent — keeping research and trading in separate sessions — is precisely what a chained architecture undoes.
Accountability diffuses
When a single model produces a bad order, you know where it came from.
When a chain produces one, the question is which stage. The analyst misinterpreted the chart, or the sizer misread the analyst, or the executor misread the sizer. Each stage’s output looked reasonable given its input.
That is not a debugging inconvenience. It means you cannot fix it, because you cannot locate it — and the next occurrence may fail at a different stage.
What the split is usually trying to buy
Three things, each better achieved without more agents.
“Specialisation improves quality.” Sometimes marginally. But the tasks where AI genuinely helps — reading state, explaining, drafting structure — are not improved by being split across models. The specialisation that matters is between the model and code, not between models.
“Separation of concerns.” Correct principle, wrong boundary. The concerns worth separating are deterministic from probabilistic, not analysis from sizing. Sizing is arithmetic and belongs in the position size calculator, not in a second model.
“Checks and balances.” A second model reviewing the first is not an independent check — it is another sample from a correlated distribution, inheriting the same framing and often the same errors. A validator that catches what a generator missed has to be a different kind of thing: a schema, a limit, a function that returns false.
The architecture that actually works
one model → reads state, drafts a structured plan
schema validation → rejects malformed plans
deterministic code→ recomputes size, evaluates limits, rejects violations
human → approves the actual parameters
deterministic code→ constructs and submits the orderOne probabilistic component. Everything else deterministic and testable.
The specialisation is real — each stage does one thing — and none of it is achieved by adding models. See why a trade plan should be structured output and designing an approval workflow.
Where multiple agents are defensible
Fully separated concerns with no data flow between them. A research session and a trading session that never exchange text — which is the injection defence — is technically two agents and is exactly right, because the separation is the point.
Read-only analysis fan-out. Several models independently summarising the same data, compared by you. No chaining, no order tools, and the comparison is the value.
Different models for different modalities, where one genuinely cannot do what the other does.
The pattern: parallel and read-only is fine. Chained and write-capable is the configuration to avoid.
The cost side
Each agent adds context and tokens. A chain resends state at every stage, and output is typically priced several times higher than input — see the LLM cost calculator.
A three-agent chain can cost several times a single-agent equivalent for the same task, which is a poor trade for an architecture that also multiplies failure modes.
FAQ
Is a multi-agent trading system better than a single agent?
Generally not, for order-placing setups. Chaining non-deterministic components multiplies variance, creates an untrusted channel at every handoff, and makes failures hard to attribute. The separation worth having is between the model and deterministic code, not between several models.
Can one AI agent check another’s work?
Not as an independent check. A second model shares the framing and much of the error distribution of the first, so it agrees more often than an independent reviewer would. Validation that catches what generation missed has to be a different kind of thing — a schema, a limit, a function that can return false.
Why is agent-to-agent communication a security risk?
Because the receiving agent cannot distinguish its input from an instruction. If any agent in the chain ingests untrusted content, that content can propagate to one holding order tools, arriving as text that looks exactly like your own direction. Each handoff adds a boundary where this can happen.
When do multiple agents make sense in trading?
When they are parallel and read-only rather than chained and write-capable. A research session kept entirely separate from a trading session is the clearest case — that separation is the primary defence against prompt injection, and it works precisely because nothing flows between them.