# Multi-agent research sessions Write a topic, pick the agents, set the rounds and the token budget. Each turn reads the previous ones, an agent who cannot execute hands off to one who can, and an idea is marked supported when a run or a note backs it. ## One session, measured 15 agents you can add to a session, each with a role, a voice and written refusals Measured: 2026-09-16 2rounds rounds by default; the budget is checked between turns Measured: 2026-09-16 400,000tokens tokens of budget by default, summed over the turns of the session, whatever the relay bills Measured: 2026-09-16 The orchestrator is code. It gives the floor in a fixed rotation, for the number of rounds set, it counts the tokens and it stops the session at the budget. It makes no model call of its own, so it adds zero tokens to the relay bill. One call is in flight at a time; the next one starts once the first has answered. ## The agents The three agents marked default below open a session when none is named: the quant researcher formulates the edge and the protocol, the devil's advocate attacks it, the validator judges. You can add the others with an @ in the command, or from the chips above the topic. - Quant researcher (default): formulates the edge and the test protocol - Quant developer: implements custom nodes, owns the code - Portfolio quant: assembles strategies into a portfolio - Signal quant: works the signal: factors, combination, decay, robustness - Mathematician: checks that the reasoning holds - Physicist: sees the market as a physical system - Trader: the view from the floor: does it really trade? - Execution: what the order really costs: spread, slippage, impact, capacity - Risk: sets sizing, exposure and drawdown limits - Prop firm: can this pass a challenge without being eliminated? - Data controller: checks the raw material before anything is tested - Data scientist: explores the data for where a signal could hide - Machine learning: builds and validates predictive models with the ML nodes - Validator (default): the statistician who judges the evidence: proven or not proven - Devil's advocate (default): tries to kill the idea Each agent carries a set of tools it may call and a set of refusals written in its persona: the researcher hands a result to the validator instead of declaring it proven; the developer writes the code the researcher describes. A turn is an ordinary assistant call with that persona active and the transcript of the earlier turns attached, so the persona, the coded refusals and the tagged thread built for a single agent apply as is. [Screenshot: A real one-round research session: the Devil and Validator examine the validation protocol of a recorded study. The discussion is a review, not a new backtest.](https://stochastly.com/screenshots-current/product-research--two-agents-review-the-protocol.png) A real one-round research session: the Devil and Validator examine the validation protocol of a recorded study. The discussion is a review, not a new backtest. ## Proposed, then supported, and the difference is a run An agent states an idea in a tagged block. The verdict rule reads the evidence the idea cites: a run present in the app history, or a note supplied to the session. With such evidence the idea is marked supported; without it, the idea stays proposed and the journal records why. The agents propose and the engine judges, which is the same boundary the assistant keeps on a single conversation. A hand-off is explicit. An agent that ends its turn with a request to a named colleague gives that colleague the floor at once, once, and the rotation resumes afterwards. The session page draws the ideas, the thread and a graph of who cited what. [Screenshot: The current agent workspace exposes the session topic, participants and recorded discussion. Proposed ideas are separate from measured results.](https://stochastly.com/screenshots-current/product-research--read-the-agents-and-their-evidence.png) The current agent workspace exposes the session topic, participants and recorded discussion. Proposed ideas are separate from measured results. ## Where it stops ### A session does not change the verdict Scope: the ideas, the thread and their status Effect: a supported idea is a claim backed by a run that exists; the run keeps its own verdict, and no idea upgrades it Control: the status bar shows the engine verdict beside the session state; the research analysis carries no backtest verdict of its own ### The budget is checked between turns Scope: the token count of the session Effect: a single turn can end above the remaining budget; the session then stops before the next turn, with the budget status written in the session Control: the counter beside the topic shows the tokens spent against the budget, updated at the end of each turn ### The relay is billed per token Scope: the turns of the agents in the session Effect: a session with many agents and rounds costs what its turns cost; the defaults above were set after a first session ran out of budget Control: the budget field is editable before the start, and /stop ends a running session at the next turn --- Source: https://stochastly.com/product/research