For two years the conversation was about the model. Which one was smartest, which one wrote the cleanest code, which one topped the benchmark this month. That conversation has quietly ended. By 2026 the frontier models have converged: hand the same hard task to the leading models and the gap between them is small and shrinking. So if the model isn't the differentiator anymore, what is?
The answer is everything around the model: the loop that keeps it working, the tools it can reach for, the memory it carries between sessions, the rules it can't break. That wrapper has a name now, the harness, and learning to build one well has become the most valuable AI skill of the year.
This is the first post in a five-part series on agentic harnesses. In it we'll define what a harness actually is, walk through the four parts every harness shares, and explain why a single blog post by a HashiCorp co-founder turned "harness engineering" into a discipline. The later posts go deep on each part in turn.
From Vending Machine to Workshop
Most people still use AI like a vending machine: type a request, get an answer, done. That works for a one-line question. It falls apart the moment a task spans several steps, several files, or several hours, which is most real work.
A harness changes the shape of the interaction. Instead of a single round-trip, the model sits inside a system that lets it act: run a command, read the result, decide what to do next, and repeat, all while staying pointed at a goal you defined up front. The model supplies the intelligence; the harness supplies the structure that turns it into finished work.
A clean definition, from LangChain's teardown of the pattern:
An agent harness is every piece of code, configuration, and execution logic that isn't the model itself.
The model is the engine. The harness is the car built around it: the wheels, the steering, the brakes, the dashboard. A brilliant engine bolted to nothing goes nowhere.
Three Layers: Prompt, Context, Harness
It helps to see where the harness sits relative to ideas you already know.
- Prompt engineering is about the words you send in a single message: phrasing, examples, the shape of the request.
- Context engineering is about what's in the model's window at the moment it acts: the files, the history, the retrieved snippets, the system instructions.
- Harness engineering is about everything outside a single context window: how work flows across many windows, how state is handed off, which actions are even possible.
Each layer wraps the one before it, a wider scope of control around a narrower one:
The term "harness engineering" was coined by Mitchell Hashimoto, co-founder of HashiCorp and creator of Terraform, in a widely-shared post in February 2026. He described a habit he'd fallen into while working with coding agents: every time an agent made a mistake, he didn't just correct it in the moment. He engineered a permanent fix into the agent's environment so it could never make that mistake again.
Every time an agent makes a mistake, you engineer a solution so it never makes that mistake again.
That single shift, treating the environment as the thing you improve rather than re-explaining yourself every session, is the heart of the discipline. Your harness becomes a record of every lesson learned, and it compounds.
The Four Parts Every Harness Has
Strip any harness down and you find the same four parts. They're necessary and, together, sufficient. Get all four right and you have a system that can do real, multi-step work reliably.
1. The Agent Loop
The beating heart: a loop in which the model reasons, takes an action through a tool, observes the result, and goes again until the goal is met. This is the "agentic" part. Without the loop you have a chatbot; with it you have something that can pursue an objective across dozens of steps. Deciding when to continue, when to stop, and how to recover from a bad step is where a lot of harness craft lives.
2. The Tool Interface
A model on its own can only produce text. Tools are how that text turns into action: reading a file, running tests, querying a database, browsing the web. The most powerful harnesses don't hand the model a fixed menu of pre-built tools; they give it general-purpose access to a shell and a code runtime, so it can assemble whatever it needs on the fly. Where those tools come from, whether MCP servers, CLI commands, or sandboxed code execution, is a design decision with real cost and security consequences.
3. Context Management
A context window is finite, and long tasks overflow it fast. Context management is the set of techniques that keep the model working coherently anyway: summarising and compacting history, offloading bulky tool output to the filesystem, resetting the window and handing off state to a fresh session through a structured artifact. This is where the difference between a toy demo and a system that runs for hours is decided.
4. Control Mechanisms
Left alone, an agent will confidently declare mediocre work finished. Control mechanisms keep it honest: planning steps before acting, a separate evaluator agent that grades the work skeptically, hard quality thresholds that trigger a rework, git history that lets you roll back, and tool-level guardrails that make dangerous actions outright impossible rather than merely discouraged. Verification isn't a nice-to-have here; it's load-bearing.
Why This Matters Beyond the Demo
There's a striking example in Anthropic's own write-up on long-running agents. The same goal, build a small playable game with AI features, was given to a bare single agent and to a full harness. The bare agent produced something non-functional in twenty minutes. The harnessed version took six hours and produced a working application that actually played. The harness naturally cost more to run, but in the end it was the only one that shipped something usable.
As raw model quality stops being a moat, the moat becomes how well you wrap the model: the loops, tools, memory and guardrails that turn a capable model into a dependable colleague. That wrapper is buildable, ownable, and specific to how your team works. It's where the leverage now lives.
How We Think About This at vensas
We don't treat harnesses as a research curiosity. The same instincts run through how we build software with AI day to day: tool-level guardrails that make the wrong action impossible, project conventions in AGENTS.md that travel with every session, reusable skills for the work we do repeatedly, and verification loops that check quality rather than assume it. Much of what we've already written - on spec, verifier and environment, on self-hosted coding agents, on git worktrees for AI workflows - turns out to be harness engineering by another name. This series puts a frame around all of it.
Conclusion
The model stopped being the interesting variable. What separates a flashy demo from software that actually ships is the system built around the model: the harness. It has four parts: a loop that keeps it working, tools that let it act, context management that keeps it coherent, and controls that keep it honest. Master those four and treat your environment as the thing you permanently improve, and you stop re-explaining yourself to the AI every morning and start compounding.