The Age of Harnesses
For two years, frontier model capability moved only incrementally on the benchmarks our field has been tracking. Yet, many developers attest that the experience of building with coding models improved dramatically.
If the models' pure benchmark performances hardly moved, what did..?
The answer is the emergence of the harness: a term for a specific layer of battle-tested engineering around a model. It has become the dominant determinant of what an LLM-powered system can actually do in production.
But what is a harness, exactly? Why has it become so crucial, and how hard is it to get right? And does it apply to agents other than Claude Code or Codex?
Contents:
What a Harness Is
Claude Code is an example of a harness for coding workflows.
It's the layer that sits between a use case and Anthropic's models, which carefully controls what the underlying language model itself sees every time it's invoked, which tools it can use, how it plans, how it remembers, what it is allowed to assume, and when it should stop.
Importantly, none of this is the model itself. All of it shapes what the model does.
Context Engineering
The foundation for the work a harness does is context engineering: getting the right tokens into the model's context, and, just as importantly, keeping any irrelevant ones out, at every step.
Why is this so crucial? Because when prompts are packed with everything that might be relevant, models degrade. The effect is not subtle and it is not specific to one model; it shows up in every frontier model across the board.
Even more interestingly, it doesn't matter so much whether the prompt is packed with either too little or too much of context. Models will degrade similarly, in both cases, to ungrounded, unaligned outputs.
Intuitively, you can think of it as managing attention for a human. There is such a thing as explaining too much in one breath: you lose the listener, and their execution of your instructions will suffer.
Critically,it turns out that the "right" context is also not constant across turns. It changes turn by turn, tool result by tool result, decision by decision.
This is why a model's context must be managed meticulously, continuously, and dynamically, from turn to turn.
Harnesses Encode Workflows
A harness encompasses an opinionated workflow around an LLM.
It encodes how the agent should approach a class of work, and this structure is baked in at the framework level, so the agent does not have to rediscover it on every turn.
This is also the line between a harness and a toolkit. While the long tail of agent frameworks provide primitives which are useful, general, and intentionally unopinionated, a harness ships with battle-tested "opinions" about how to combine those primitives for a specific kind of work.
As I said before, Claude Code is a harness for coding. Consider what it's actually doing, as understood from reverse-engineered reconstructions.
- A constrained set of file operations (Read, Edit, Write, Grep) that force structured, controlled, and focused changes.
- A
TodoWritetool that turns "the plan" into a first-class artifact the model maintains and is instructed to inspect as it works. - Hooks: shell commands that fire on tool events, so policy is enforced by code rather than by hope that the model re-reads its instructions.
- A system prompt that is less a personality than a protocol: how to communicate with the user, when to ask, what counts as "done."
Critically, the power of these opinionated flows isn't achievable using a clever prompt, not even multi-agent orchestration (in its common, naive sense).
The harness is the sum of those flows, expressed with plenty of actual engineering around each and every LLM request. This sum is what produced the step-function in capability that the underlying model alone couldn't achieve.
Harnesses for Other Types of Agents
If harnesses for coding agents works so well, what about other use cases?
Conversational agents, for example, make up in volume most of what enterprises actually want from LLMs: support agents, sales agents, scheduling agents, internal copilots, and business-aligned customer-facing chat.
The Surprising Challenge of Conversational Use Cases
On the surface, the work of coding agents seems far more complex than mere conversations. But, perhaps counter-intuitively, real-world conversations often present a drastically bigger challenge.
Real-world customer interactions are looser in success criteria, contain more variability, and are subject to tighter consistency constraints than assisted code editing. On top of all that, the price of an average failure is drastically higher from a business perspective.
Conversational agents are still mostly built by engineers for someone else. This often means the requirements are harder to understand, and the dogfood loop around the implementation is weaker.
The development cycle in this projects is, in our experience, astonishingly common. When new edge cases appear in production, the workflow amounts to adding another instruction to one of the increasingly-larger system prompts.
The model seems to start handling that case correctly, but a week later, a different conversation that used to work has quietly broken, because the model is now over-applying the new instruction in places it does not belong.
The team then adds an exception, and then another. But as the prompt grows, the model's adherence to any given line of it gets worse. The team starts to dread making changes, and velocity and adaptability slow.
Parlant as a Conversational Harness
We built Parlant on the same insight that drove Claude Code: that the model is not the bottleneck, and the gains from re-shaping what the model sees are much larger than the gains from waiting for the next model.
The opinions we have baked into Parlant's workflow are different, because the work is different. A conversational agent does not edit files. It maintains a coherent, aligned, and predictable interaction over many turns.
It applies a dynamic set of business rules to a moving conversation. It is judged not on whether the code compiles, but on whether customers are handled correctly and consistently.
To our knowledge, Parlant is the first complex, open system that treats a conversational agent as a full harness in this sense, rather than a prompt with tools attached. An agent does not run as a single LLM call. It runs as a pipeline of narrow stages, each of which gets exactly the context it needs:
- Guideline matching. Narrowing down the behavioral rules that govern an agent (what to do, what to avoid, what policies to apply) to the small subset that actually applies to this point in this conversation. The model never sees the rules that do not matter right now and, as a result, is far more consistent at applying its provided rules. This is similar to skills in coding agents.
- Trigger-based tool calling. Instead of presenting the model with a large tool library and hoping it picks the right ones, Parlant's pipeline triggers the evaluation of only specific tools at each turn, based on the conversation's state and the matched guidelines.
- Canned responses. For moments where the team needs to control exactly what the agent says, such as disclosures, scripted offers, and specific phrasings legal has signed off on, the harness can bypass generation entirely and select a pre-approved template. The model's job, in those high-stakes moments, focuses on correct selection rather than composition.
- Full traceability. Every decision the pipeline makes (which guidelines fired, which tools were considered, which response was selected and why) benefits from the underlying structured approach, and is logged end-to-end. A conversation can be replayed and inspected the way an engineer would step through a debugger, seeing exactly how specific instructions affected the model's output at a particular turn of a conversation.
What Harnesses Cost
It would be misleading to suggest the shift is free. While a good harness dramatically improves results, it costs more than a system prompt in two respects.
- First, it costs more tokens, because pipelined stages send more API calls than one large one.
- Second, it may cost more in latency, because more stages mean more sequential work.
In our experience (and many happy Parlant users), the trade is overwhelmingly worth it once an agent is being asked to do anything serious: anything where reliability, compliance, or debuggability matter more than time-to-prototype.
But it is a trade. A weekend prototype does not need a harness, whereas an agent that interfaces directly with customers often cannot be built without one.
It is also worth saying: harness work is not a one-off situation. Coding harnesses are still actively evolving. While we have strong opinions about the trade-offs Parlant makes, our team constantly searches for ways to improve every aspect of both the developer and user experience.
In our opinion, that is just what real engineering looks like!
Harnesses Will Keep Compounding
We do not think the next few years of LLM progress will be won at the model layer alone. The harness level is where the most exciting and impactful work will be done, and where the biggest leaps in capability will be seen.
Frontier models will keep improving, slowly, probably expensively, in increments. The applied gap between "raw model" and "model in a thoughtful harness" is already large, and we expect it to keep widening. Claude Code made this concrete for engineering.
We believe the same proof is on its way for every other domain in which language models do real work.
If you are building a conversational agent for a real business, the question is no longer "which model should I use?" It is "what is my harness, and what opinions does it encode?" If the answer is "a system prompt and some tools," there may be a step-function on the table that has not yet been picked up.
The frame that matters here is not "buy a framework" or "build your own." It's the recognition that conversational agents, like coding agents, are systems whose value comes from the workflow around the model, not from the model alone.
Need help getting started?