Your voice AI product is already an agent harness
On SWE-bench, swapping the harness around an LLM moves the score by 22 points. Swapping the model moves it by 1.
That gap is the thing the AI engineering community spent the first half of 2026 trying to name. The name that stuck is the agent harness, and the framing is now everywhere: technical Twitter, engineering blogs, conference talks. The finding is either obvious or embarrassing, depending on where you sit. After a year of frontier-model convergence, the model you pick is almost never what decides whether your product works in production. What decides is everything wrapped around it.
The numbers behind the finding are not subtle. Stanford-cited work has the same model going from 46% to 80% accuracy under different harnesses. LangChain redesigned only the harness on Terminal Bench 2.0 and moved their score from 52.8% to 66.5% with the same model underneath. Vercel cut 80% of an agent's tools, watched success climb from 80% to 100%, and saw latency fall from 724 seconds to 141. The agent's brain didn't change in any of those experiments. The thing around the brain did.
If you've been building production AI for any length of time, none of this should surprise you. The industry finally has a name for what most of us have been doing for years: building the agent harness.
What an agent harness actually is
The cleanest definition I've seen is the one a few different writers have converged on. An agent is the model plus the harness. The model gives you intelligence. The harness gives the agent everything else: the tool execution, the memory beyond the context window, the state persistence across turns, the permission boundaries, the error recovery, the observability, the evals that catch regressions, the routing across providers, the deterministic orchestration that decides what the model is even allowed to think about at any given step.
The reason this framing took over in 2026 is that the top general-purpose models converged in capability. The choice between the leading five or six is rarely the thing that decides whether your product works. The thing that decides is what you build around them.
There's a corollary from Addy Osmani that I keep coming back to: every agent mistake should become a permanent fix in the harness. The harness only tightens. It never loosens. A good agent harness, over time, becomes a layered record of every failure mode you've seen in production and the specific guardrail that stops it from happening again. Models are bought. Harnesses are accumulated.
The contradiction nobody is naming
The agent harness discourse has been almost entirely framed around coding agents (Claude Code, Cursor, Codex, Aider) and general-purpose assistants. The benchmarks people cite are SWE-bench, Terminal Bench, GAIA. The architecture diagrams show file-system tools, terminal access, code search, IDE hooks.
Meanwhile, every serious voice AI company has been building a harness for years, by a different name, often without the benefit of a community-shared vocabulary for what they were doing.
Think about what a production voice AI product like Elba actually contains:
- A real-time speech-to-text and text-to-speech pipeline, with provider redundancy because no single TTS or ASR vendor has acceptable uptime, latency, and language coverage at the same time.
- A model-agnostic orchestration layer, because the real answer to "which LLM should we use" turns out to be "different ones for different turns" once you account for cost, latency, language, and the regulatory profile of the customer.
- Persistent conversation state, because a 90-second call has nothing to do with the LLM's context window. The state spans turns, modalities, channel switches (voice to WhatsApp to SMS to email), and sessions when a caller hangs up and calls back the next day.
- A deterministic workflow layer that decides what the model is allowed to do at each step. Not because the model couldn't generate the next action freely, but because in regulated industries you cannot ship a system that lets the model freely invent the next action on a clinical or insurance workflow.
- Deep integrations into customer systems: CRM, insurance backends, dispatch software. The model never talks to these. The harness does.
- Observability and audit logging that a clinical or operational auditor can read on its own, without an engineer translating it.
- Evals that are specific to each customer's workflow, run on every release, and gate deploys.
Read that list as a description of Elba and it reads like a product spec. Read it as a description of an agent harness and it reads like Addy Osmani's blog post. They are the same artifact, described under two different vocabularies.
This is the contradiction. The agent harness is being positioned in 2026 as a new category of engineering work. For voice AI in regulated industries, it has been the entire job from day one.
Why this reframing matters more than it looks
If you're an engineer at any voice AI company, the reframing matters for two reasons.
The first is internal. A lot of work that is hard to value in a sprint planning meeting starts to look very different once you accept that you're an agent harness company that happens to use voice as a surface. Replacing a TTS provider, writing the fallback logic for when a tool call times out, adding a new shape of state to the conversation store, building the evals for a new customer's specific dispatch workflow: that work is the product. It is where reliability lives.
The data backs this up directly. Stanford's number, where the same model performs 6x better under a different harness, is the upper bound. In our own production environment, every reliability win in the last twelve months has come from the harness. The model swaps we've done (across providers and model families) have changed unit economics. They have not changed our reliability numbers. The reliability numbers move when the harness gets tighter.
The second reason this matters is external. Customers in regulated industries (hospitals, insurance, emergency services, banking, government) are getting more sophisticated about what they're actually buying. A year ago, the question was "what model do you use." Now it's "how do you handle a tool failure mid-call", "what is your fallback path when the primary TTS provider degrades", "how do you guarantee a specific workflow gets followed when the model wants to deviate." These are harness questions. The companies that can answer them in detail, with logs, win those deals.
There's also a small-model angle worth being honest about. Some of the more triumphalist agent-harness writing in 2026 has implied that a great harness can make any model work. That overclaims it. A bad model still fails, harness or not. The more accurate version of the claim is that a great harness lets you make rational tradeoffs that you cannot make otherwise. You can route a specific turn to a smaller, cheaper, faster model because the harness has narrowed the surface area enough that the smaller model can succeed at that turn. You can run a regulated-language interaction on a sovereign EU model without taking a quality hit, because the harness has already constrained the problem. You can drop your inference bill in half without your end users noticing. None of that is possible with a model alone.
What we've learned building Elba's harness
Four things have held up across two years of iterating on this.
The deterministic workflow layer is non-negotiable in regulated voice. The first version of every workflow we ship is always more model-driven and less deterministic. The second version, always, is more deterministic. Production teaches you fast that "let the model decide" is fine for an internal prototype and a liability the moment a clinician or insurance agent is on the other end. The model still does plenty of work inside each step. It just doesn't choose the steps.
Model-agnostic orchestration is a survival strategy, not a marketing line. We've had to switch primary LLM providers several times in the last eighteen months for reasons that had nothing to do with capability: pricing changes, regional availability, vendor enterprise terms shifting, GDPR positions changing. If the harness binds you to a model family, you ship the next pricing crisis directly to your customers. We chose not to be in that business.
The harness gets credit for the wins and the blame for the losses. When a call goes well, it's because the harness held everything together. When a call fails, it's almost always because the harness failed to catch a state the model produced. Osmani's principle holds at our scale too: every failure becomes a permanent fix in the harness. We are, slowly, accumulating one of those.
Why we stopped calling Elba a voice AI product internally
If you are building any production AI system that talks to customers, executes workflows, integrates with external systems, or has a reliability SLO, you are an agent harness company. The model is the smallest part of what you ship. The integrations, the orchestration, the state, the fallbacks, the evals, and the audit trails are the product.
The 2026 agent harness discourse is useful because it gives the industry a shared name for work that voice AI teams (and a lot of other production teams) have been doing under different labels for a long time. Once you have the name, the architectural choices get clearer. The roadmap gets clearer. The hiring profile gets clearer.
For our part, we've stopped describing Elba as a voice AI product internally. It is an agent harness that runs voice as one of its surfaces. That reframing changed nothing about the codebase but almost everything about how we plan the next 12 months of work.
Arpit Nigam
