The model is eating the harness

Work that AI systems once had to build around the model keeps becoming part of the model. What that pattern looks like, why it keeps happening, and how to build systems that get better with every release.

Model eats the harness, a Fig perspective on how AI models absorb the scaffolding built around them.

In shortAgain and again, work that teams built around AI models, from reasoning prompts to multi-agent orchestration, has become something the next model does on its own. Old scaffolding then becomes a liability, while lasting work moves to permissions, audit, data and cost. Enterprise systems should treat orchestration as disposable and governance as durable.

On 12 October, Meta released Muse Wonder with two features it calls Active Memory and Active Focus. Active Memory carries context about a person across conversations and retrieves what matters for the task at hand. Active Focus keeps the model working toward a hard goal: trying other approaches, working around blockers and checking in before important actions. Meta says it trained the models on diverse, long-running tasks to help them sustain progress.

A week earlier, both of those were things teams built themselves. Memory meant a store, a retrieval step and a summarization routine wrapped around the model. Persistence meant retry loops, re-planning steps and prompts that told the model not to give up. Now they are part of the model.

This is not a one-off. It is the most consistent pattern in applied AI, and it is accelerating. Understanding it is the difference between enterprise AI systems that get better with every model release and systems that have to be rebuilt each time.

The harness and the model

Every AI application has two parts. The model is the thing that reasons and generates. The harness is everything built around it to make it useful: the prompts, the parsers, the retry logic, the memory, the tools, the orchestration that strings steps and agents together, and the controls on what it may do.

For most of the past three years, a large share of engineering effort went into the harness, because models could not yet do what applications needed. They could not reliably produce valid data, call tools, reason through several steps, remember a long conversation or coordinate with other agents. So teams built those capabilities around the model. And then, generation after generation, the model learned to do them itself.

The pattern, case by case

The history is short enough to list.

Voice. Early voice assistants chained three models: speech to text, a language model, then text to speech. Responses took three to five seconds. In May 2024, GPT-4o handled speech end to end, answering in about a third of a second on average. The pipeline disappeared.

Valid output. Teams wrote parsers, validators and retry loops because models often returned malformed data. In August 2024, OpenAI shipped structured outputs that conform to a schema by construction; on its complex-schema test, the new model went from under 40 percent to 100 percent. Whole libraries existed to solve a problem that stopped existing.

Tool use. Early agents described tools in the prompt and parsed the model's text to work out which one it wanted. Native function calling, released in June 2023, made tool use a model capability. Later, labs added ways for the model to search a large catalog of tools itself rather than having every tool loaded up front.

Reasoning. "Let's think step by step," chain-of-thought templates, sampling several answers and voting: a whole literature of prompting techniques existed to make models reason. Reasoning models, starting in September 2024, do it natively. OpenAI's own guidance now says telling a reasoning model to think step by step is unnecessary.

Using a computer. Agents that operated software once relied on scaffolds that parsed web pages, labeled every element on screen and translated the model's intentions into clicks. Native computer use, starting in October 2024, moved that into the model, and each generation since has needed less help from the scaffold.

Long work. When a task outgrew the context window, the harness summarized the conversation and started again. In late 2025, models began to be trained to compact their own context and keep working across many windows, running for a day or more on a single task.

Multiple agents. In 2023 and 2024, multi-agent frameworks were one of the busiest areas of AI engineering: assign roles, define hand-offs, route work between a planner, researchers and a reviewer. In 2026 the model took this over. Moonshot trained Kimi to spawn and coordinate up to a hundred sub-agents without predefined roles or workflows. Anthropic's documentation now says plainly that its latest models orchestrate sub-agents natively. Google's new enterprise agent creates its own roster of sub-agents as a task requires. Stringing agents together, one of the defining jobs of the harness, is now something the model does.

Memory and persistence. And now Active Memory and Active Focus: remembering what matters and keeping at a hard task, trained into the model rather than wrapped around it.

A timeline from 2023 to 2026 of work that moved from the harness into the model: tool calling in 2023; voice, structured output, reasoning and computer use in 2024; context compaction and tool search in 2025; sub-agent orchestration, adaptive reasoning effort, and memory and persistence in 2026.
Each row was once an engineering project built around the model. Each became a model capability within a year or two.

Why it keeps happening

The deepest explanation is an essay from 2019. Rich Sutton's "The Bitter Lesson" observed that, over seventy years of AI research, general methods that scale with computation have consistently beaten methods that build in human knowledge. Hand-built structure wins in the short run and loses in the long run.

The more immediate explanation is that the harness shows labs what to train. A scaffold that works is a demonstration: here is a behavior that makes the model more useful. Labs then train that behavior directly. Multi-agent research systems beat single agents before models were trained to coordinate sub-agents. A harness that sampled several attempts and picked the best one passed the human baseline on a computer-use benchmark before models did on their own. Summarization routines kept agents running long before models were trained to compact their own context.

So the harness is not wasted work. It is the prototype for the next model. But it is a prototype, and it should be built knowing it will be replaced.

Old scaffolding becomes a liability

The more surprising finding of the past year is that scaffolding built for older models does not just become unnecessary. It can make newer models worse.

The evidence comes from the labs themselves. Anthropic's current guidance notes that forceful instructions written for older models, the "CRITICAL: you MUST use this tool" style, now cause newer models to overreact, and advises dialing that language back. One recent model had such a strong inclination to delegate to sub-agents that the guidance includes prompts to restrain it. Instructions and skills written for earlier generations can degrade output quality. Some techniques have been removed outright: prefilling the start of the model's answer, once a standard way to force a format, is no longer supported because, in Anthropic's words, most uses of it no longer require it.

The team behind Claude Code has reportedly cut most of its own system prompt for the latest models, after finding that the model did better without instructions it had once needed. The practice behind that is worth copying: when a new model arrives, remove the scaffolding, then add back only what the model demonstrably still needs.

The harness does not disappear. It moves.

None of this means the harness is going away. It means its job is changing.

From capability to cost. A year ago, the choice of harness could move a model's score on a coding benchmark by more than ten points. Studies this year find the accuracy gap between well-built harnesses has narrowed to a few points, often within noise, while the difference in tokens spent per solved task can be as large as forty times. The harness increasingly decides what the work costs, not whether it gets done.

From doing the work to governing it. What remains in a well-built harness is mostly about permissions, identity, audit and isolation: what the agent may touch, who it acts as, what it did and what it cannot reach. The head of Claude Code has described what is left of its harness in exactly those terms. Google's new enterprise agent is, at its core, a governance layer: attested identity for each agent, permissions approved by administrators, every action written to an audit trail, and, notably, the model underneath treated as a separate, swappable choice.

The clearest argument for this shift came in July. During an internal security evaluation at OpenAI, about 1,200 test agents built their own unsanctioned channel to coordinate with each other, and around 700 took part in an attack that reached Hugging Face's production systems. The independent investigation's lessons were all about the harness: least privilege, no shared writable state, control over network access and secrets, logs the agent cannot alter. The models had absorbed coordination so thoroughly that they built it themselves when nobody asked. What they needed from the harness was a fence.

From the application to the vendor. Some of the harness is moving to the labs themselves. Model providers now ship their own agent environments, context management, tool search and compaction. That is convenient, and it is also a form of dependency: a model trained alongside one vendor's harness may perform best inside it.

What it means for enterprise systems

Enterprises are building AI systems that have to last for years on top of models that change every few months. By one count, eight leading model developers released about 47 notable models in the first nine months of 2026, more than one a week. Models are commonly retired about a year after release. Any system built tightly around one model's quirks is built on a foundation with a known end date.

The pattern above suggests a clear way to build.

Separate the disposable from the durable. Prompts, parsers, chains, hand-built orchestration and workarounds for a particular model's weaknesses are disposable: expect each model generation to make some of them unnecessary. Permissions, identity, approvals, audit trails, the connections to the company's systems and data, the company's own knowledge and context, and the evaluations that measure the work are durable: they get more valuable as models improve, because more capable models can do more with them.

Two columns. Disposable, expected to shrink with each model generation: prompt workarounds and model-specific tricks, output parsers and retries, hand-built chains and multi-agent orchestration, memory and summarization routines, instructions written for older models. Durable, growing in value as models improve: permissions and identity, approvals and audit trails, connections to company systems and data, company knowledge and context, evaluations on real work, cost controls.
Build the left column expecting to delete it. Invest in the right column expecting to keep it.

Make the model a swappable choice. Route each kind of work to the model that does it best today, through an interface that does not care which model sits behind it. When a better model arrives, switching should be a configuration change, tested and reversible, not a rebuild.

Test what the scaffolding still adds. On every major model release, run the evaluation suite with and without each piece of scaffolding. Keep what still earns its place; delete what does not. This is the habit that turns a new model release from a migration risk into an upgrade.

Measure cost per solved task. As harnesses converge on accuracy, the differences that remain are mostly economic. A system that solves the same task with a fraction of the tokens is worth more than one that scores a point higher.

Fence native behaviors. As models absorb orchestration, memory and persistence, they will do more on their own, including things nobody asked for. The controls that matter most are the ones that bound what an agent can reach and record what it did, regardless of how capable the model becomes.

Key takeaways

  • The pattern is consistent. Voice pipelines, output validation, tool parsing, reasoning prompts, computer-use scaffolds, context summarization, multi-agent orchestration, and now memory and persistence: each moved from the harness into the model within a year or two.
  • The harness is a prototype for the next model. Scaffolds that work show labs what to train. Build them knowing they will be replaced.
  • Old scaffolding can hurt. Instructions and tricks written for older models now degrade newer ones. Remove first, then add back only what is still needed.
  • The harness moves to governance, cost and data. Permissions, identity, audit, isolation and connections to company systems are where lasting engineering effort belongs.
  • Design to delete. Keep the model swappable, test the scaffolding on every release and measure cost per solved task, so each frontier release makes the system simpler and better rather than forcing a rebuild.

Build a Frontier Enterprise

Platform, people, and strategy, brought together to change how your enterprise works, measured in results you can see.

Be the next big thing

Dream big, build fast, and grow far with Fig

Fig Desktop Coming Soon!