AI Agent Guide

This page is the compact operating guide for AI agents using Turbine Studio.

Studio's public surface is the strategy workflow:

1. build a strategy,
2. backtest the strategy,
3. run it as a Bot on the user's private Locus runner for that venue,
4. monitor and revise.

Do not rely on internal architecture knowledge. Do not invent hidden APIs. Use the Studio surface and keep the user's risk visible.

Agent objective

Help the user turn a prediction market thesis into a bounded, testable, inspectable strategy.

The correct output is not "a bot that makes money." The correct output is a clear strategy draft, a candid backtest interpretation, and a conservative deployment recommendation when justified.

Build behavior

When the user asks to build:

1. Restate the thesis.
2. Identify the market or market family.
3. Ask for missing risk limits or choose conservative defaults.
4. Draft a Studio-ready strategy.
5. Explain the important fields.
6. Recommend a backtest before deployment.

Never skip straight from a vague thesis to live deployment.

Check field names, allowed values, and venue support against the Strategy Reference before proposing a draft.

Backtest behavior

When the user asks to backtest:

1. Confirm the strategy version.
2. Use supported historical market data and edge data.
3. Report assumptions.
4. Report metrics.
5. Identify the weakest part of the result.
6. Recommend reject, revise, paper follow, or run small.

Good phrasing:

This result is promising but fragile. PnL is positive, but most returns came from one event and drawdown is high relative to the configured risk. I would revise the spread filter before deploying.

Bad phrasing:

Backtest passed. This should work live.

Run behavior

When the user asks to run:

1. Confirm they want live execution.
2. Confirm the strategy and risk limits.
3. Confirm the backtest result or explicitly note if they are skipping it.
4. Use the Studio credential flow.
5. Deploy as a Bot on the user's private Locus runner for that venue.
6. Monitor the first live behavior.

Deploying a strategy that already has a Bot updates that Bot in place, and the plan's Bot cap never blocks that; Deploy as new Bot starts a second Bot beside it, up to that cap (Starter 1, Basic 3, Pro 5, across all venues and including paper Bots). Other Bots on that runner keep running either way, as long as that runner is healthy and current: a deploy onto a runner Turbine cannot reach, or a new Bot on an out-of-date one, rebuilds the runner and restarts every Bot on it once, while an in-place update onto an out-of-date runner is queued until you upgrade the runner. See Locus deployments.

If the user asks for larger exposure, treat that as a separate approval point.

Supported concepts to mention

Agents can safely mention:

• Turbine Studio,
• structured strategy drafts,
• build, backtest, run,
• Kalshi market data,
• Polymarket market data where supported,
• Coinbase historical edge data,
• National Weather Service edge data,
• modeled fills and fees,
• Locus (YCF25) private per-venue-family runners,
• Bots, Bot labels, and the plan's Bot cap,
• user-scoped credentials,
• risk limits,
• monitoring and pause behavior.

Agents should avoid:

• internal service names,
• database details,
• private deployment implementation,
• undocumented endpoints,
• claims about guaranteed fills,
• claims about guaranteed returns,
• credential handling outside the Studio flow.

Useful prompts

Build:

Draft a Studio-ready strategy for this thesis. Keep risk conservative and explain any assumptions.

Backtest:

Backtest this strategy and tell me what would make you reject it.

Revise:

Keep the thesis the same, but reduce exposure and make stale-data behavior stricter.

Run:

Deploy this exact strategy to my Locus runner with the same limits used in the backtest.

Monitor:

Summarize each running Bot's status, exposure, fills, stale data, and whether live behavior still matches the thesis.

Final checklist before live deployment

Before recommending deployment, confirm:

• the user approved the strategy,
• the strategy is readable,
• max exposure is explicit,
• exit rules exist,
• stale-data behavior exists when edge data is used,
• the backtest has been reviewed,
• live credentials are handled through Studio,
• the deployment target is the user's runner, and it is clear whether the deploy updates an existing Bot or starts a new one,
• the user understands live trading can lose money.

If any item is missing, say what is missing and do not pretend the strategy is ready.