Strategy research workflow
A Case Study is the saved home for a strategy investigation. Research runs organize its experiments; candidate versions, trials and evidence records let you inspect what happened and decide what to do next.
Use this guide for the overall sequence. For the controls on the study cards, see Research overview.
The flow
Section titled “The flow”Open the diagram at full size · Download the Mermaid source
This is a decision flow, not a promise that every study reaches validation or forward testing. The protocol and current evidence determine which operations are eligible.
1. Choose a way to work
Section titled “1. Choose a way to work”| Path | How to begin | Who drives the next action |
|---|---|---|
| Internal Algo Agent | Open Algo Lab and describe your goal in the Algo Agent. | The agent can perform a multi-step loop within its configured tools, budget and stopping rules. |
| Your own MCP client | Connect a supported AI client through the MCP connection page. | Your client reasons about the task and calls the platform’s research tools. |
The internal agent requires an eligible account and available AI credits. MCP requires MCP access. Market-data availability depends on your configured integrations. See Algo Agent, MCP setup and account integrations.
If you have no studies, Research overview offers Start with Algo Agent and, when available to your account, Connect MCP. Opening an empty chat does not submit a prompt or start research.
2. Bind the study and review its history
Section titled “2. Bind the study and review its history”Create or select the Case Study and establish the intended symbol and timeframe. Review existing runs, versions and evidence before requesting another measurement. Pine strategies must use Pine Script v6.
Disclose observations that may have influenced the idea, including charts or research viewed outside this account. The platform records reads it observes and uses selection declarations and lineage to account for research history.
3. Define the experiment before measurement
Section titled “3. Define the experiment before measurement”Record a hypothesis and an experiment protocol: what is being tested, which data scope is allowed, what comparison will be used, and what would count as support or failure. Include costs and the study’s applicable risk policy. Declare the planned scopes and prior observations before market reads; protect reserved slices according to the protocol.
For MCP work, follow the tool-provided research guidance and current decision state. The protocol and tool responses determine eligibility; this guide does not replace those rules. See MCP tools and workflows.
4. Establish context and evaluate candidates
Section titled “4. Establish context and evaluate candidates”Inspect the permitted market context and baseline diagnostics, then evaluate a candidate in the declared scope. Keep the benchmark, testing dates, cost assumptions and strategy configuration visible when interpreting a comparison.
Save candidate versions and trials so later checks can be traced back to the tested source. Preserve unsuccessful experiments as part of the investigation. A positive return alone does not establish that a candidate improves on its benchmark or is eligible for confirmation.
Longer operations may return a background job. Check its status and retrieve its result; distinguish queued, running, failed and completed work. A completed job is not a passing research gate.
5. Inspect evidence and obey the decision boundary
Section titled “5. Inspect evidence and obey the decision boundary”Use the current research state to select the next permitted check. Depending on the protocol and earlier results, the workflow can include statistical analysis, stress tests, walk-forward checks, cost sensitivity and other diagnostics. Some checks are blocked until earlier requirements are met.
| What you see | How to respond |
|---|---|
| No result or not run | Check prerequisites before requesting the measurement. |
| Analysis saved, conclusion unavailable | Inspect the underlying evidence; the saved record alone does not establish a pass. |
| Failed | Read the failure and its scope. Revise within the protocol, make an explicit decision or stop. |
| Passed | Verify that the evidence applies to this candidate and scope before continuing. |
| Partial, stale or incompatible evidence | Respect the stated limit. Do not reuse it as an unqualified result for another configuration. |
Do not loosen thresholds, change the question after seeing the result or treat a new run as a way to erase earlier trials. If the evidence is insufficient, an inconclusive outcome is a valid stopping point.
6. Continue from Research overview
Section titled “6. Continue from Research overview”Open a study’s research stage or select a Research gates chip to inspect its checks. The overview distinguishes recorded results, passed checks and failed checks. A card’s saved backtest may refer to a different version or configuration from a research reading; inspect the underlying records.
Inside an expanded gate:
- Continue with Algo Agent opens a fresh chat with a study-, run- and gate-specific draft. Review and send it yourself. Opening the chat does not run a test.
- Copy request for agent copies a request for your own research client. Review it in the context of the current study before running tools.
- Evidence shows the number of saved research records and explains how to interpret that count. It is not a trade count or a pass result.
7. Review changes and keep forward testing separate
Section titled “7. Review changes and keep forward testing separate”When the Algo Agent stages candidate source changes, review the diff before accepting or rejecting them. The research workflow does not automatically place brokerage orders.
Historical validation and forward testing answer different questions. Use Backtest vs Alerts to compare historical events with captured alerts, and Alerts vs Fills to inspect execution records when available. Those comparisons need their own data and setup; a historical pass does not complete them automatically.
A useful first request
Section titled “A useful first request”Help me structure this strategy as a Case Study. Review its existing evidence and prior observations, clarify the hypothesis and permitted scope, and propose the next eligible experiment. Ask me for missing decisions before running paid tests.
Give the agent the actual strategy and your constraints. A request to plan is not evidence that the plan has been recorded or a test has run; check the resulting study state and tool responses.