Perspectives

Research harness

  • Application

Tools, context, and harnesses: the engineering that determines how far research can be relied on.

A model is one part of a research system. The rest is engineering: which tools the model can call, what those tools return, how a run is controlled, and how its output is checked. That surrounding structure is often called a harness. Set up for a research task, we call it a research harness: which data and tools the models get, how runs are bounded and checked, and how results reach people and AI apps.

State of the field

The harness often matters as much as the model. Optiver found that most failures in its agentic engineering work “came from gaps in the surrounding workflow rather than from the model itself”, and that improving context, tooling, and verification “had as much impact as improving the model”. Its answer was to take the judgment of success away from the agent: “The agent will tell you it succeeded even when it hasn’t” (Optiver, 2026 (external site)). Anthropic reports the same lever, separating the agent doing the work from the agent judging it, and notes that every component of a harness “encodes an assumption about what the model can’t do on its own” (Rajasekaran, 2026 (external site)).

Context is the other half. At OpenAI, Ryan Lopopolo puts the constraint simply: for an agent, “anything it can’t access in-context while running effectively doesn’t exist” (Lopopolo, 2026 (external site)). How tools are described changes how well they are used: Anthropic reports that “even small refinements to tool descriptions can yield dramatic improvements”, and that precise refinements took Claude 3.5 Sonnet to state-of-the-art performance on SWE-bench Verified (Aizawa, 2025 (external site)). The Model Context Protocol was introduced as an open standard for connecting AI systems with data sources (Anthropic, 2024 (external site)); through it, research tools can reach professionals inside the AI apps they already use.

Principles

A research harness deserves the same care as research. The same contract should govern how a system is evaluated and how it is improved, an agent should have only the access its task requires, and the data and tools it relies on should be described as carefully as any interface for people. It is better to start simple and add complexity only when it is needed.

Our approach

Our research harness runs our models over point-in-time data from the same store the Tauric API serves, with usage budgets, output limits, run status, and cancellation, and delivers results through the API and MCP server. We aim to build evaluation into each research task from the start.

References