AI research agents as platform citizens

Once a quant team has had the same conversation about LLMs twice (“can we let it propose strategies?” / “we tried, it cited papers that didn’t exist”) the question stops being about the model and starts being about the platform. A frontier LLM in 2026 is still going to hallucinate; the design problem is what can’t happen when it does.

This is a short post about that design problem. It’s not about prompting, RAG, or the latest agentic framework. It’s about the four or five seams a research platform needs in order to admit an AI agent as a first-class actor without the agent’s mistakes reaching anything that matters.

The frame: agents are a second operator kind

A research platform already has one operator: the human. Every existing assumption — “the operator declares a strategy”, “the operator promotes a model”, “the operator approves a live deploy” — implicitly references that one type. The cheapest way to admit an agent is to name a second operator kind with the same gates.

Concretely:

@dataclass(frozen=True)
class Operator:
    kind: Literal["human", "agent"]
    identifier: str         # human: 'clai'; agent: 'claude-opus-4-7/<run_id>'
    model_artifact: str | None
    prompt_template: str | None

Everything that used to read “the operator did X” now reads “operator(kind, identifier) did X”. The promotion gate still requires a human approver; agents propose. Every row the agent authors carries the agent’s identifier — exactly like every row the human authored carried the human’s. The audit trail unifies.

This is a small change in the type system and a big change in the platform’s posture. It says: an agent isn’t a special integration; it’s another operator, subject to the same rules.

The four seams the platform already owned

The interesting thing — the thing that makes this not just “another LLM tool” — is that a research platform built well already has every defence an agent needs. The work is naming the seams, not building new ones.

1. Citation refusal at the data boundary

A strategy that cites a paper the platform doesn’t know about should fail at registration, not at deploy. If you already have a writing manifest with stable slugs, the gate is one query: does this slug resolve? Apply it to agents identically. The most common hallucination shape — fabricated source attribution — gets refused by the type system, not by a model.

2. Bitemporal floor at the data layer

A backtest at t=2024-09-30 that uses a feature whose knowledge_time > 2024-09-30 is leakage, regardless of who authored the backtest. If your feature store already enforces point-in-time semantics — refuses any read whose as_of exceeds knowledge_time for the requested data — then an agent cannot peek into the future. Not because we asked it not to. Because the data layer refuses.

3. Bounded discovery, not unbounded search

A typed factor-mining search with hard caps (max_depth=3, n_candidates=200, keep_top=50) is a different shape from “the agent generates Python and we run it”. The agent picks parameters inside a known search space; the platform decides what the search space is.

This is the seam that distinguishes “agent as researcher” from “agent as code-execution layer”. The former is bounded by declarative specs; the latter is bounded by sandboxing and prayer.

4. Promotion as a human-only gate

The agent’s job ends at the leaderboard. The platform’s promotion contract — “to promote, you need a named human approver, a signed eval report, and a strategy hash that matches the registered artifact” — is unchanged. An agent that proposes 100 candidates is doing exactly what the platform was built for; it’s just doing it faster than the human alone could.

The promotion gate is the load-bearing piece. Without it, every other defence is a layer of latex paint on a leaky pipe.

The fifth seam: cost

A platform engineer who hasn’t read a cloud bill recently might be surprised by what a single agent run costs. A planning step + 20 tool calls + a synthesis step on an Opus-tier model can be $1–2 per run on 2026 prices; a hundred such runs in a research session is real money.

The cost-ceiling design is not different from any other resource cap: per-run token budget, per-day operator budget, per-phase model routing (cheap model for tool dispatch, expensive model for planning). The point is to name the budget. Without it, a runaway loop is a four-figure invoice that nobody pre-approved.

What none of this is about

It’s not about prompting. The system prompt for an agent that operates on this platform can be three paragraphs long — most of the constraints come from the platform, not from the prompt.

It’s not about choosing the “right” model. Sonnet, Opus, Haiku, GPT-4o, an open-weights model — the constraints are the same. The platform doesn’t know or care.

It’s not about a magic agent framework. Most of what people call “agent frameworks” today are loops + tool dispatch + retries. None of that is the interesting part. The interesting part is whether the platform you point the loop at can refuse the bad inputs.

The substrate is the differentiator

Many people have tried “AI proposes trading strategies” in the last ten years. Quantopian had bots; Numerai is, in effect, crowdsourced ML; AgentQuant and similar 2024–2025 projects automated the hypothesise-search-backtest loop with LLM-generated parameter proposals. None of them shipped a research firm’s actual book.

The pattern that doesn’t work: a bare LLM, a Python interpreter, a backtest library, and a prompt that says “be careful.” The agent generates code that overfits, cites strategies it half-remembers, peeks at future data through innocent-looking joins, and produces a leaderboard that looks great until promotion.

The pattern that does work: a platform where the data layer refuses lookahead, the registry refuses uncited strategies, the promotion path requires a named human, and the discovery loop is bounded by a declarative spec. The agent operates inside this substrate. Its mistakes have nowhere to go.

That’s the platform decision. The model is downstream.