Building an AI Trading Agent From Market Data to Orders

A strategy in four parts

You might already know the question you want to ask: is this news meaningful, does the market support it, and is there still a sensible price to enter? Turning that question into a strategy should be a matter of connecting context, a decision, an execution plan, and a test.

This is a preview of that workflow. Recurring AI decision blocks are currently paused in the staging release. The combined AI-to-execution path needs to be enabled and validated before it can be used as a live trading or AI-backtesting walkthrough.

Choose the context your decision needs

Quant Fun’s feed catalog spans market data and real-world events. Each Studio exposes compatible sources; a feed’s presence in the wider catalog does not mean it can be attached to every AI block. The configured AI block accepts up to eight named evidence feeds. Start with the few that can actually answer your question.

• Crypto: Binance, Coinbase, and Bybit spot quotes; Polymarket outcome order books; Chainlink benchmarks. Trade and volume feeds also drive dedicated numerical conditions alongside the AI decision.
• X: full posts and metadata from selected public accounts through the official stream, rather than an assumption that the model has read all of X.
• Weather: forecasts from Open-Meteo, NWS, and MET Norway, plus supported marine and probabilistic weather data.
• Stocks: supported stock-linked perpetual market data in Perpetual Studio. This is not a general cash-equity feed, and those perpetual feeds are not currently direct inputs to the AI block.
• Memecoins: social-token workflows can provide an exact token-address candidate for assessment. They have their own execution routes and currently do not support spot-token backtesting.
• More context: matched Kalshi quotes, tracked trader activity, private numeric signals, and sports data are available in their compatible workflows. The source selector determines what belongs in a particular decision.

Give the AI a clear decision

Name the attached feeds, then refer to those names in the prompt. For a crypto idea, you might attach X posts as @posts and the Polymarket book as @market. A useful prompt could be:

“Using @posts, decide whether there is a concrete, credible development that supports buying the outcome being evaluated. Use @market to assess the available quote and liquidity. Return true only if the evidence is sufficient; return false for promotion, conflicting claims, or missing context.”

The intended output is a yes/no gate. Add numerical price, liquidity, and exposure conditions where you need precise limits. An instruction such as “do not pay too much” becomes much more useful when the execution path also has an explicit price constraint.

Give the AI its own clock

Configure a fresh decision every five minutes, for example. The interval setting supports one to sixty minutes, and there is also a once-per-market option. The design caches each decision for its configured interval and market candidate, so a market tick does not automatically become another paid AI call.

That creates two clocks: AI reviews the opportunity periodically, while the execution algorithm manages its orders on its own schedule. A yes permits the configured path; position limits and re-entry cooldowns control repeated exposure. A later no does not automatically cancel an existing order: cancellation and exit rules need to be part of the strategy too.

Give the opportunity an execution plan

An AI approval says the idea is worth acting on under your rules. The order still needs a plan. On supported venues, the execution blocks offer several approaches:

Choose according to how long you expect the opportunity to last and how much liquidity is available. The aim is better control over price, urgency, and market impact. No algorithm guarantees the best price: waiting can miss a move, and immediate execution can cost more.

• Post-only or pegged placement: seek a passive fill; a pegged order can follow the best passive quote within its configured timeout.
• TWAP: divide the total quantity into timed slices, carrying unfilled quantity forward within a bounded execution window.
• VWAP: size slices using an available historical trade-volume profile; complete source coverage is required.
• IOC with retry: attempt an immediate fill within the configured price bound, then retry only the unfilled remainder for a limited number of attempts.

Test the whole path

The research loop is straightforward: choose a supported market and recorded period, run the strategy, inspect the report, then change one part. Keep the prompt fixed while comparing execution methods, or keep execution fixed while testing a different decision interval.

The existing replay engine models order-book depth, partial fills, fees, and order timing for supported strategies. Look at fills, drawdown, fees, and data coverage as well as P&L. A promising decision can still make a poor trade if execution consumes the opportunity.

For a complete AI backtest, the model must evaluate the evidence available at each simulated decision time. Historical AI evaluation still needs validation in this combined workflow; spot-token backtests are not available yet.

AI calls have a budget

AI calls in backtests are limited according to your subscription. The current access policy reserves AI-block backtesting for Professional and charges authorized calls against the monthly Strategy AI allowance. It is a usage budget, not an unlimited number of evaluations; the model, prompt size, attached context, and output all affect cost.

More markets, more AI blocks, a longer test, or a shorter decision interval can mean more calls. One candidate checked every five minutes over six hours has 72 scheduled decision points, before adding other candidates or blocks. That is an illustration of cadence, not a promised bill or a universal call quota.

Check the current plan and remaining allowance in Settings → Billing. When the allowance cannot cover another authorized call, the billing layer refuses it. Once AI replay is available, start with a focused recorded window and expand after the idea earns further testing.

The useful part is how the pieces fit

Feed adapters, context selection, structured decisions, scheduling, partial fills, retries, and risk controls each take work to build and maintain. The point of the building-block approach is to make that work reusable.

The workflow becomes easy to describe: these are my sources, this is my question, this is how often I ask it, and this is how I want to trade a yes. Then test whether those choices work together. That leaves more of your attention for the idea itself.