Agent = Model + Harness
One equation, two very different parts
A frontier model on its own is a brilliant mind locked in a dark room. It can reason about code but can't run it, plan a migration but can't touch a database, and forgets everything the moment the conversation ends. Ask it to "fix the failing deploy" and it will produce an excellent essay about deploys.
An agent is what you get when you wrap that mind in a harness: the runtime that assembles context, brokers every tool call, sandboxes execution, persists state, and recovers from failure. The equation is worth keeping literal — Agent = Model + Harness. The model supplies judgment. The harness supplies hands, eyes, and memory.
What a harness actually does: keep the loop running
Strip away the branding and every agent runtime is the same loop. The harness assembles context — the task, the conversation, file contents, previous tool results — and hands it to the model. The model reasons and either answers or asks for a tool. The harness executes that call in a sandbox, appends the observation to context, and goes again.
"Keep working in real-world settings" is the hard part of that sentence. Real environments mean flaky APIs, timeouts, permission boundaries, context windows that fill up mid-task, and processes that die. A production harness retries what's transient, compacts context when it overflows, and persists the session so work survives a restart. This is the unglamorous 80% of agent engineering — and none of it is the model's job.
Anatomy of a modern harness: a kernel and its plugins
The harnesses aging best are the ones built like operating systems: a small kernel, with every capability as a plugin. DeepSeek Harness is the cleanest recent example — its Cordis kernel does exactly three things: it mounts plugins, unmounts them, and resolves the dependencies between them. That's it. The kernel has no opinion about which model you run or what tools exist.
Everything the agent can actually do lives in plugins: models, tools, skills, sessions, sandboxes, storage, loops, scheduling, even the UI. Plugins never import each other directly — they cooperate through kernel services and events, which is what makes any one of them swappable.
Compose with configuration
Because capabilities are plugins, composing an agent stops being a code change. Developers select, swap, or extend any capability in configuration — without touching the harness source. Swapping the model is one line. Adding a tool is a list entry. Moving from a Docker sandbox to a locked-down VM is a key change, not a fork.
This is the property that makes a harness deployable, not just demoable: every environment-specific difference — which model, which tools, which storage, which schedule — lives in config that ops can own, while the harness itself stays a single, upgradable artifact.
Why this matters when agents meet production
When we deploy agents with customers, the model is rarely what decides success. Models are strong and getting stronger; what varies wildly is whether the agent survives contact with a real environment — permissioned data, flaky internal APIs, hours-long tasks, compliance boundaries. That is entirely a harness question. When you evaluate an agent stack, ask about the body, not just the soul:
Loop robustness — what happens on a timeout, a malformed tool result, a full context window?
Isolation — where does tool execution actually run, and who set its permissions?
State — does a session survive a restart? Can a human resume it?
Pluggability — can you swap the model, tools, or sandbox in config, or is it a fork?
Agent = Model + Harness. The model is the soul; the harness is everything that lets it live in your environment. Pick both deliberately.