Quantitative signal discovery: a closed-loop multi-agent architecture

Signal discovery is the core loop of quantitative trading: propose a hypothesis about what predicts returns, express it as code, test it against real data, and keep what survives. Most of that work is repetitive, and most proposed signals fail. That makes it a good fit for an agentic system — provided the system can check its own work.

This paper describes an architecture we built for that loop. The emphasis is on the architecture, not the model. A closed loop of three specialized agents does the mining, coding and testing; a small, efficient reasoning model with strong tool-calling drives each one. The design does not depend on a frontier model. A compact open model is sufficient, and you can run it either way: self-hosted on a single modern GPU, or through a hosted inference endpoint with no local GPU at all.

1. Why a closed loop

One-shot generation asks a model to produce a good trading signal in a single pass. It cannot work reliably. The model has no feedback: it never sees whether its code runs, whether the backtest is profitable, or whether an apparent edge is statistical noise. It guesses, and the caller inherits the guess.

A closed loop replaces the guess with evidence. Each proposed signal is turned into executable code, run against historical data, and scored by a statistical test. The result — success, failure, or a specific error — is fed back to the agents, which adjust and try again. The system converges on signals that actually hold up, because it discards the ones that do not before a human ever sees them. The loop is the product; the model is a component inside it.

2. The three agents

2.1 Signal agent

The signal agent identifies candidate alpha signals from real market data — price and volume series for a universe of instruments. It proposes a hypothesis in plain terms: a relationship it expects to predict forward returns, such as a momentum, mean-reversion or volume-imbalance effect. It works from what the data affords rather than inventing signals in the abstract, and it uses the evaluation history to avoid re-proposing ideas that have already been ruled out.

2.2 Code agent

The code agent translates a signal description into executable Python. It writes the feature computation over the data (pandas and NumPy), runs it, and reads back what happened. When the code raises — a shape mismatch, a missing column, a lookahead in the windowing — it does not stop. It reads the error, corrects the code, and runs again. This iterative self-correction is what makes generated code trustworthy: the agent ships a program that executes cleanly, not a plausible-looking snippet.

2.3 Evaluation agent

The evaluation agent runs the backtest and decides whether the signal is real. It computes the signal's relationship to forward returns and applies a statistical test — rank (Spearman) correlation between signal and return, a t-test on the effect, and the associated p-value. A signal that only looks good by chance is rejected. The agent then feeds a structured verdict back into the loop: what worked, what did not, and which direction to push the next proposal. That feedback is what turns three agents into a search rather than a batch of independent attempts.

3. The loop in operation

The three agents run continuously: mine → code → test → refine. The signal agent proposes, the code agent implements and self-corrects, the evaluation agent backtests and scores, and the verdict returns to the signal agent to shape the next hypothesis. Over many passes the system explores the signal space under statistical discipline, keeping what survives and discarding the rest.

An orchestration layer coordinates the hand-offs and holds shared state — the data, the running history of proposals, and their scores. Tracing and observability sit across the whole loop, so every proposal, generated program, backtest and score is recorded. That matters twice over: it lets a researcher see why a signal was kept or dropped, and it exposes where the loop spends its time so bottlenecks can be found and removed.

Backtesting is the hot path, since every proposed signal is evaluated over the full history. GPU-accelerated data-science libraries carry that work, so the loop can test many candidates per hour instead of a handful.

4. Key capabilities

• Autonomous multi-agent orchestration. The three agents coordinate through a shared loop with no human in the inner cycle.
• Self-correcting code generation. Signal logic becomes executable Python with error handling and iterative refinement, not one-shot output.
• Statistical gatekeeping. Rank correlation, t-tests and p-values decide what survives, so noise is filtered before review.
• Accelerated backtesting. GPU data-science libraries make full-history evaluation fast enough to run the loop at scale.
• Observable experimentation. End-to-end tracing records every proposal, program and score, and surfaces bottlenecks.
• Portable deployment. The same architecture runs self-hosted or against a hosted inference endpoint, on-prem, hybrid or at the edge.

5. Requirements

The stack is deliberately modest. Components are named by role, so any implementation that fills the role works.

6. Where the pattern generalizes

Nothing here is specific to finance. The shape is a research loop: propose a hypothesis, implement it, test it against evidence, and refine from the result. Signal discovery happens to have a clean scoring function — a backtest with a p-value — which is what lets the loop run without a human in the middle. Any domain with an executable test admits the same architecture: feature engineering, model search, scientific simulation, or any setting where candidates can be generated as code and scored automatically. The contribution is the closed loop, and it transfers wherever proposals can be checked.