Multi-agent quant: separation of powers for a company of one

[Parts one through three](/blog/quant-not-a-gambling-machine) covered the monolith: deterministic engine, dual models, decision memory. A single process can absolutely run — Phases 1 and 2 are designed that way. But past a certain complexity the monolith turns to porridge: the model is researcher, trader, and risk officer all at once, approving its own trades. This post is about an idea taking shape: split the system into multiple agents. Not because multi-agent is fashionable — because separation of powers.

First, why agents at all

The biggest risk in a one-person quant operation is not compute. It is the absence of checks. The model emits a signal — who challenges it? The backtest looks great — who checks for look-ahead bias? The strategy bleeds for three days — who decides between stop and hold? In a monolith the answer to all three is "the same it" — a hothouse for overfitting and confirmation bias. The essence of multi-agent is installing mutually constraining perspectives: the power to propose, the power to veto, and the power to audit, kept apart.

Four layers, eight roles

Along the existing architecture, each layer grows its agents:

Sensors — the Data Agent feeds the BaseDataProvider, aligns timestamps, guards against look-ahead bias, and halts the line when data is dirty. The News Agent scrapes news and filings, scores sentiment, and distills unstructured text into a few lines of Market Context.

Research — the Factor Agent runs the RD-Agent-style generate-backtest-filter loop, endlessly producing candidate factors. The Backtest Agent runs backtests and reports numbers — win rate, expectancy, drawdown. It does not explain, it does not defend. It reports.

Decision — the Strategy Agent merges technicals and Market Context into structured signals with confidence. The Risk Agent holds the veto — position caps, stop discipline, drawdown constraints. Any signal that fails its gate dies there. The proposer does not hold the approval power — that is the single most important line in this design.

Oversight — the Audit Agent writes the decision memory, computes Strategy Health, and grades every AI call right or wrong — including the calls made by the Strategy and Risk agents themselves. The Orchestrator handles task routing, tiered model dispatch, and failover — the tiered-routing scheme from part two is its job description.

Three design principles

One: agents do not chat; they pass structured messages. Market Context, factor vectors, signal JSON — over a Redis bus, every message auditable. Free-form multi-agent conversation sounds seductive, but unauditable collaboration is no collaboration. Two: each agent runs a different model tier. Sensors use cheap or free general models; the Strategy Agent uses a fine-tuned small model (next post); the Risk Agent can even be pure rules plus a small model — checks and balances do not need every link to be clever, they need every link to be reliable. Three: the human is the last agent. Every authorization level (L0 to L5) funnels down to one admin confirmation in the console. The system proposes; the human arbitrates. A company of one has exactly one CEO.

One anti-pattern warning

Do not build this as an Auto-GPT-style free loop — hand the model a goal and let it think, act, and judge on its own. That recipe burns tokens, answers to no one, and produces logs that cannot balance. The agent I want is not an employee with free will; it is an LLM joint in a deterministic pipeline — the skeleton is code, the joints are models. This is why "auditable" in part three was not bravado: with a deterministic pipeline, every joint's output has a log entry.

Seen from above, this architecture diagram is the org chart of a one-person company: I am the CEO; sensors are the intelligence desk; research is the research desk; decision is the trading desk plus the risk desk; oversight is internal audit. What a one-person company lacks was never hands — it is an org structure. Agents are how you compile an org structure into code.

[Next post](/blog/quant-tiny-decision-models) supplies the last missing piece: where the Strategy Agent's brain comes from — which tiny open models suit fine-tuning into decision models, and why the training data is the decision memory itself.