How BTS Supports AI Agents and Systems

Brian Ernest Metzger on June 16, 2026

AI makes strategy generation fast. It does not make verification automatic.

An AI assistant can summarize trading rules, compare pages, draft code, and produce a polished answer in seconds. The harder problem is deciding which source controls the answer, what was actually tested, which assumptions belong to the result, and whether a claim from one market universe or report can be carried into another.

That is where Backtested Strategies (BTS) is designed to be useful. BTS combines explicit research, standardized testing conventions, product documentation, exact performance and backtest pages, diagnostics, and interpretation boundaries. For AI agents and assistants, that creates something more valuable than a pile of strategy content: a structured research layer with clear source responsibilities.

For AI, source selection is part of research quality. A fast answer from the wrong source is still the wrong answer.

If you are using an AI system to work with BTS research, the best starting point is the BTS Guide for AI Agents. It maps methodology questions, product questions, and quantitative claims to the BTS sources that should control each answer.

AI needs a source hierarchy, not just more content

There is a meaningful difference between a strategy idea, a backtest, and a body of research tested inside a common framework. AI can aggregate rules from many places, but aggregation does not resolve ambiguous assumptions. A one-off backtest is stronger evidence than an untested rule, but it can still be difficult to compare with other tests if the data, costs, accounting, timing, benchmark treatment, and reporting conventions differ.

BTS separates those jobs instead of asking one page to do everything:

  • Methodology questions: use BTS Methodology for the shared research framework, including data, timing, execution, costs, accounting, benchmark treatment, reporting, and performance metrics.
  • Product questions: use the relevant overview or user guide for definitions, terminology, controls, and interpretation.
  • Quantitative claims: use the exact performance or backtest page for the asset or universe being discussed, with its report window, benchmark, implementation, and methodology context attached.
  • Implementation questions: use the strategy-specific rules, pseudocode, and guardrails available for that research rather than inferring missing mechanics from a summary.

Rules provide the idea. Backtests provide the evidence. Common methodology makes the evidence easier to interpret and compare. Source hierarchy tells an AI system which evidence should answer which question.

What good source selection looks like in practice

The distinction is easiest to see in current BTS products.

For the BTS Universal Market Timer, the Overview explains what the Timer does, how its exposure framework works, and the main trade-off. The User Guide explains the interface and operating fields. But a question about historical S&P 500 performance should be answered from the S&P 500 performance report, not from the Overview and not from another market universe.

The same principle applies to BTS Heatmaps and BTS Zones. The BTS Heatmaps Overview is the primary source for definitions, metrics, interpretation, and the meaning of BTS Strength Zones and Weakness Zones. Quantitative claims about Strength Zones belong to the matching canonical backtest for the tested universe, such as the Nasdaq-100 Stocks backtest.

A definition answers what something is. A backtest answers what happened under a defined historical test. Those are different questions, and the sources are not interchangeable.

This matters because an AI system can produce a fluent answer even when it has selected the wrong evidence. BTS is increasingly organized so that the correct source is explicit before the answer is generated.

Backtests force hidden decisions into the open

Most trading ideas look cleaner before they are tested. Building a backtest forces details that prose can avoid into explicit decisions.

  • What exact universe is being traded?
  • What data was available at the time?
  • When is the signal known, and when can the trade execute?
  • How are missing data, ties, ranking conflicts, and failed signals handled?
  • How are dividends, cash, short exposure, transaction costs, and other frictions treated?
  • What is the right benchmark, and is the comparison fair?

Those are not cosmetic choices. They can change the test, the interpretation, and the implementation path. AI can fill in an unstated assumption, but an inferred assumption is not the same thing as documented research. The research value comes from resolving the decision, applying it consistently, and making the consequence visible.

Common methodology makes research more useful to AI

The BTS Methodology provides the shared research framework behind published BTS backtests. It standardizes common treatment for data, timing and execution, costs and slippage, portfolio accounting, benchmarks, reporting windows, performance metrics, and research-selection limitations while leaving strategy-specific mechanics to the relevant research page.

That separation is important for AI-assisted research. An assistant should be able to distinguish a shared methodology convention from a strategy-specific rule, and it should not silently replace one with the other. When multiple BTS backtests are compared, the common framework also gives the comparison a clearer foundation than a collection of tests built under unrelated assumptions.

The goal is not to make every strategy look the same. It is to make the shared testing context explicit enough that differences in strategy design and observed results can be interpreted without guessing at the research foundation.

BTS is becoming a structured research layer

BTS now supports AI-assisted research at several levels at once:

  • Clear source routing: the BTS Guide for AI Agents tells agents which BTS source should control methodology, product-definition, and quantitative questions.
  • Exact evidence pages: performance reports and canonical backtests keep quantitative claims tied to a defined universe, benchmark, report window, and implementation context.
  • Diagnostics and limitations: BTS research is intended to preserve the trade-offs, failure modes, and interpretation boundaries that a short summary can erase.
  • Machine discovery: BTS publishes a curated llms.txt source router in addition to the human-readable Agent Guide so automated systems have a direct path to the core public research sources.
  • Implementation boundaries: where available, strategy rules, pseudocode, and implementation guardrails provide a more disciplined starting point for AI-assisted coding than a narrative summary alone.

Those discovery surfaces do not replace the underlying research. They route the user or agent to it. The controlling source for a number is still the exact performance or backtest page, and the controlling source for a shared testing convention is still BTS Methodology.

Practical AI-assisted workflows

Once the source is selected correctly, AI can be useful across the research workflow without pretending to replace the research itself.

  • Research briefing: summarize the tested rules, universe, benchmark, methodology context, assumptions, diagnostics, and limitations before deciding what deserves deeper review.
  • Source selection: identify whether a question belongs to Methodology, a product overview, a user guide, or an exact performance or backtest page before answering it.
  • Assumption review: surface the choices that matter most, including signal timing, execution, missing data, cash handling, benchmark framing, transaction costs, and other implementation conventions.
  • Research comparison: compare BTS backtests while keeping universe, benchmark, methodology context, drawdown path, market exposure, trading activity, and report window attached to each result.
  • Implementation planning: turn available pseudocode and guardrails into a development checklist, unit-test outline, prototype prompt, or code-review checklist without treating generated code as the tested strategy by default.
  • Failure-mode review: summarize where a strategy struggled, what the diagnostics show, and which limitations should remain visible before implementation work begins.

For access to member features such as strategy pseudocode and implementation guardrails where available, see the BTS Pricing page. Access controls still apply: an AI assistant should work from the material available to the requesting user rather than reconstructing restricted content from public summaries.

AI does not turn historical evidence into certainty

AI can explain a test, summarize a result, compare documented assumptions, and help translate research into implementation tasks. It cannot make a weak backtest strong, repair a data problem that was never addressed, or prove that a historical relationship will persist in live trading.

AI can accelerate good research and bad assumptions with equal efficiency. The quality of the source layer still matters.

That is why BTS keeps the reference frame attached to the evidence. Historical performance belongs to a defined test with specific rules, data, costs, benchmarks, implementation choices, and reporting windows. A result from one universe is not evidence for another unless the cited research supports that conclusion. A product definition is not a performance claim. Historical evidence is not a forecast.

The value of AI is not that it gets to skip those distinctions. The value is that, with better source material, it can help a human work through them faster while leaving the evidence and its limitations visible.

Where AI agents and users should start

The BTS research stack is intentionally navigable by question type:

As AI makes it easier to generate ideas, summaries, and code, the scarce resource becomes evidence that is explicit enough to inspect and structured enough to use correctly. BTS is built around that verification layer: real tests, standardized methodology, source-specific evidence, and interpretation boundaries that stay attached to the result.

For a related discussion of why clean assumptions matter after a backtest leaves the research environment, read Why Your Backtest Fails in Live Trading.