The Model Is Not Your Agent - why the agent harness is becoming the new application runtime

For the last few years, most AI architecture discussions started with the same question: which model should we use?

GPT. Claude. Gemini. DeepSeek. Qwen. Local models.

That was a reasonable question when the model was doing most of the work. But agentic systems are changing the architecture. The model is increasingly becoming one component inside a much larger runtime responsible for planning, tools, state, execution, permissions, memory, observability and recovery.

And that runtime - the agent harness - may end up being more important to your application architecture than the model itself.

From LLM application to agent runtime

A conventional LLM application is a straight line. Even with retrieval bolted on, the architecture is still fundamentally centred on the model: something assembles a prompt, the model answers, and the request is over.

An agent is different.

The model participates in the loop. It is not the loop.

That distinction becomes increasingly important as agents move from answering questions to performing actual work.

DeepSeek Harness makes the separation explicit

DeepSeek's newly open-sourced agent harness (dsh) is an interesting example of this shift. It is built around an "everything is a plugin" architecture: file editing, shell access, search, planning, goals, subagents and workflows all arrive as plugins rather than as hard-coded features, and its Code mode lets the model combine multi-step tool operations programmatically. It is explicitly labelled a developer preview.

What is interesting isn't simply that DeepSeek released another coding agent. It is where the architectural boundary is being drawn.

Nothing in the harness ties it to DeepSeek's own models - the provider catalogue spans Anthropic, OpenAI, AWS Bedrock, Azure and Google alongside DeepSeek's own endpoint. A company shipped an agent runtime and made the interesting decision that their own model is one of the swappable parts.

That is much closer to an application runtime than a chatbot.

The model should be replaceable

There is a useful architecture test for an agentic application:

How difficult would it be to replace the model tomorrow?

If swapping GPT for Claude, DeepSeek or a local model requires rewriting your application, you probably don't have an agent architecture. You have an LLM application with tools attached to it.

A more durable design puts a seam in a specific place.

The model becomes an implementation choice for particular reasoning tasks rather than the foundation of the entire system.

And once that seam exists, something more interesting follows: different parts of the same agent can use different models.

That is a fundamentally different architecture from send everything to the smartest LLM.

Not every step requires intelligence

This may be the most important change.

Early agents often alternated model and tool on every single hop. Every intermediate result passed back through the model. That means more tokens, more latency, more opportunities for mistakes, and an increasingly polluted context window.

Modern agent runtimes are starting to separate judgement from execution.

OpenAI's GPT-5.6 guidance describes this distinction directly: some tasks require judgement, while others largely involve moving, filtering and combining data. Programmatic tool calling lets that deterministic processing happen in code, rather than forcing every intermediate result back through the model's context window.

The LLM decides what needs judgement. The runtime handles what computers already know how to do reliably.

Deterministic where possible, agentic where necessary

This leads to a design principle I think will become increasingly important:

Use intelligence for uncertainty. Use software for certainty.

Consider an agent processing an insurance claim. It might need to read the claim, identify the policy, retrieve coverage rules, calculate the deductible, check eligibility, detect unusual circumstances, and decide whether human review is required.

Not every step should be an LLM decision.

The best agent architecture isn't LLM everywhere. It is LLM exactly where intelligence adds value.

There is a governance argument here too, not just a cost one. A deductible calculated in code can be unit tested, audited and explained to a regulator. The same number produced by a model is a probability distribution wearing a suit.

The harness becomes the durable asset

Models are moving incredibly quickly. Today you might build around one frontier model. Three months later another model may be cheaper, faster, better at coding, better at tool calling, runnable locally, or simply better for your particular domain.

If your business logic lives inside prompts tightly coupled to one model, every model transition becomes an architecture migration. If the model sits behind the harness, the migration looks very different: you evaluate another model, you change an adapter or a routing rule, and the application remains largely intact.

Model improvements alone aren't the whole story

There is a striking data point in OpenAI's recent engineering guidance.

On one ARC-AGI-3 evaluation, GPT-5.6 Sol scored 13.3% under the official harness - which discarded the model's private reasoning after every move and truncated older history once the conversation grew past a length limit. Rerun through the Responses API with retained reasoning and compaction enabled, the same model scored 38.3%, while using roughly six times fewer output tokens.

Same underlying model. Different runtime behaviour. Roughly triple the score for a fraction of the tokens.

We tend to benchmark model A versus model B. But the more meaningful benchmark for an agentic application is the whole system: model, plus harness, plus tools, plus context strategy, plus execution policy, plus evaluation loop.

Agent performance is a systems problem.

The agent loop is the architecture

A useful abstraction is remarkably small:

while not goal_complete:
    observation = observe()
    state = update_state(observation)

    decision = reason(goal, state, available_actions)
    action = execute(decision)
    result = evaluate(action)

    if result.failed:
        recover()

    if human_approval_required(action):
        request_approval()

Around that simple loop sits most of the engineering that makes an agent production-ready.

These aren't model problems. They are application architecture problems.

The next security boundary is the agent runtime

Look down that table again and notice how many rows are really security rows.

As agents gain shell access, browsers, credentials and the ability to modify repositories, classic application security assumptions start breaking down. The old model assumed code was fixed at deploy time and only data varied at runtime. An agent inverts that: the behaviour is decided at runtime, by a probabilistic component, from input that may be attacker-controlled.

Sandboxing, permission boundaries, tool allowlists, audit trails and human approval stop being optional security add-ons. They become part of the architecture - which is precisely why a runtime like DeepSeek's exposes sandboxing as a first-class part of the harness rather than leaving it to whoever deploys it.

If the harness is where capability lives, the harness is also where containment has to live. Where that containment actually runs is a separate question, and the infrastructure layer is growing primitives for it - Kubernetes is acquiring an isolation primitive built for exactly this.

Your agent architecture should survive the next model

The industry spent the first phase of generative AI asking which model should I build on? The more useful question now might be: what architecture lets me benefit from whichever model is best next?

That doesn't mean models aren't important. They are extraordinarily important. But databases are important too. Operating systems are important. Browsers are important. None of them should contain the entire architecture of your application.

Models should eventually occupy a similar position: a powerful component behind a clearly defined boundary.

That last step is where things get particularly interesting. An agent runtime could decide, per step, whether intelligence is needed at all.

Now the model isn't the application. It is a compute resource selected by the application - much like choosing a database query, a serverless function, a GPU workload or a background job today.

The new application runtime

DeepSeek calling its project a harness is therefore more interesting than it initially sounds. OpenAI's movement toward persisted reasoning, compaction, programmatic tool execution and multi-agent orchestration points in the same general direction: increasingly capable models are being surrounded by increasingly sophisticated execution infrastructure.

The competitive advantage for builders may therefore shift. From who has access to the best model? to who has built the best system around the models?

Your prompts can change. Your models will definitely change. Your tools will evolve. But the architecture responsible for deciding what to do, what to use, what happened, whether it worked and what happens next is likely to remain.

That is the agent harness. And it is starting to look a lot like the new application runtime.

Stop architecting around the LLM. Architect around the agent loop.

The model provides intelligence. The loop provides the system.

This post looks inward, at how a single agent works. Two companion pieces look the other way: MCP gave agents tools, A2A gives agents colleagues is about the boundary between independent agents, and Kubernetes is becoming an AI workload orchestrator is about the infrastructure all of it eventually lands on.