Priya's support agent kept booking the wrong appointment slot. Not always, just often enough to generate a steady trickle of angry callbacks. The reasoning in the transcripts looked fine. The agent understood the request, picked a time, confirmed it. So she did what most teams do first: she upgraded the model.
The new model was measurably smarter on every benchmark. It also booked the wrong slot at exactly the same rate.
Because the bug was never in the model. The agent's calendar tool returned availability in the account's default timezone, and the harness never passed the caller's timezone into the context. A better model just reasoned more confidently over the same wrong data.
This is the lesson that keeps getting relearned in 2026, and it has a name now. Agent = Model + Harness. The model is the part everyone talks about. The harness is the part that determines whether your agent works.
What Is an Agent Harness?
An agent harness is the software layer wrapped around a language model that turns it into an agent. It manages the tools the model can call, the memory that persists between turns, the context that fits in the window, and the loop that feeds tool results back into the next model call. The model reasons. The harness does everything else.
The shorthand that spread through engineering blogs and Wikipedia this year is deliberately simple: Agent = Model + Harness. Hold the model fixed and change the harness, and the agent transforms. Swap the model under a fixed harness and often nothing changes. Most teams have it backwards, treating the model as the variable and the harness as plumbing.
The model touches nothing directly. Every tool call, memory lookup, and context decision passes through the harness first. The model never talks to your CRM, it asks the harness to, and the harness decides how.
Why Won't a Better Model Fix a Broken Agent?
A better model fixes reasoning problems. It does nothing for the failures that dominate production, which come from missing tools, truncated context, stale memory, and broken loops. If the model can't see the right information or can't take the right action, more intelligence just produces a more articulate version of the same mistake.
An agent's run goes wrong in one of three ways: the model misunderstands the request, reasons to a bad conclusion, or reasons perfectly over inputs the harness got wrong. That last category is enormous, and it's the one a model upgrade can't touch.
Priya's timezone bug is one example. Here are the failure modes a smarter model leaves untouched:
| Failure mode | What the harness gets wrong | What the model does with it |
|---|---|---|
| Missing tool | No inventory tool exists | Improvises a guess, more confidently with a better model |
| Truncated context | Policy dropped to fit the window | Can't reason about text it never received |
| Stale memory | Reads a snapshot from session start | Confidently uses the outdated value |
| Broken loop | A tool error gets swallowed, an empty result passed through | Treats the empty result as success |
In every case the model did its job: it reasoned over what it was given, and the harness gave it the wrong thing. Teams that obsess over model selection and ignore harness design plateau fast because they're tuning the component that wasn't the problem. We wrote about the broader version of this trap in why multi-agent systems fail in production.
When an agent fails, don't ask whether the model was smart enough. Ask whether it had what it needed. Trace the run. Nine times out of ten the reasoning was sound and the inputs were broken.
What Does the Harness Actually Manage?
The harness manages four things: tools, memory, context, and the execution loop. Tools are the actions the agent can take. Memory is what persists across turns and sessions. Context is what fits in the model's window right now. The loop is how tool results flow back into the next model call. Get these four right and the model has room to do its job.
Tools are the functions the agent can call and how their results come back. A tool is a contract: what the model sees in the description, what arguments it takes, what shape the result has, what happens on failure. A tool that returns a 40-kilobyte JSON blob buries the model. The same tool returning a five-field summary lets it act. That shaping is harness work, and it's the subject of why your agent has 30 tools and no idea when to use them.
Memory is what survives beyond the current model call, from earlier turns in this conversation to what you learned about this customer last month. The harness decides what gets written and what gets read back. A CX agent with no long-term memory greets a returning caller like a stranger. One with badly scoped memory leaks another customer's details.
Context is the working set: everything currently in the model's window. It's the scarcest resource in the system and the hardest single job the harness has, so it gets its own section next.
The execution loop runs the whole thing: send context to the model, get back a response or a tool request, execute, feed the result back, repeat. The loop is where error handling lives, where retries happen, where the harness decides an agent has looped too long. A sloppy loop turns one failed tool call into an infinite retry that burns your token budget; we covered the money side in reasoning tokens: the shadow cost of agents.
Customer Memory
4 memories recalled
“Discussed upgrading to Business plan. Budget approved at $50k. Follow up next Tuesday.”
How Does the Harness Manage Context in Long Sessions?
The harness manages context by deciding, on every turn, what stays in the window and what leaves. As a session grows, tool outputs and prior turns pile up until they overflow the model's window. The four standard moves are compaction (summarize old turns), bounded access (read slices of large content), retrieval (pull relevant history from an external store), and delegation (hand subtasks to subagents).
A single support call can involve identity verification, three account lookups, a policy document, a transaction history, and a dozen turns of conversation. Dump it all in raw and you blow past the limit before the call ends. Keep everything instead and quality degrades as the model loses the thread. Long context doesn't fail loudly, it fails as a slow drift into vagueness, a problem we dug into in context engineering for production AI agents.
So the harness has to be selective. The four moves, from cheapest to most involved:
Compaction. Summarize older turns: ten turns of back-and-forth become a three-sentence summary. The risk is losing a detail that matters later (ask anyone whose agent compacted away the account number), so the policy needs to know what's load-bearing.
Bounded access. Give the agent a tool to page through large content instead of loading it whole, so the 40-kilobyte history never touches the window at once.
Retrieval. Keep history in an external store and pull only what's relevant: the three entries that matter for this decision, not two years of record. Chanl exposes this through its memory layer, the pattern most CX agents converge on.
Delegation. Hand verbose subtasks to a subagent. That's the next section, because it's the most powerful move and the most misunderstood.
Context management is an active, per-turn decision, not a config value you set once. A harness that does it well feels like it has a bigger window than it does, because it spends the window on what matters.
When Should the Harness Use Subagents?
Use a subagent when a subtask would flood the main context with detail the parent doesn't need. The subagent runs in its own context window, does the messy work, and returns a clean summary, so the parent stays focused instead of drowning in the intermediate steps of a lookup, a search, or a long document read.
Some subtasks are just verbose. Searching a knowledge base might read twenty documents to find one answer; a call transcript might take thousands of words to yield three facts. Land all that in the main context and the parent loses the plot. Delegate it: the subagent's twenty document reads never enter the parent's window, the same way a colleague hands you a paragraph of findings rather than their entire browser history.
There's a cost. Every subagent is another model, another loop, more tokens, more latency. Delegating a subtask that would have taken one turn inline is pure overhead. The heuristic: delegate when the subtask is verbose and its details are disposable; keep it inline when the details feed the parent's next decision. Identity verification stays inline, because the result shapes everything after. Summarizing a customer's twelve past tickets gets delegated, because the parent only needs the summary.
A subagent is also a component with a contract: given this input, return this shaped output. Test it in isolation before it goes into the harness. Running realistic scenarios against it with scenario testing catches the case where your summarizer drops the one fact the parent needed.
How Is a Harness Different From a Framework?
A framework gives you the parts to build a harness. LangGraph, the Microsoft Agent Framework, and the Claude Agent SDK all hand you tool interfaces, memory primitives, and loop machinery. The harness is your opinionated arrangement of those parts: your tool set, your memory policy, your context rules, your approval gates.
Two teams on the same framework ship agents that behave nothing alike, because the framework is neutral. It doesn't decide whether your agent compacts context aggressively or keeps everything, delegates lookups or inlines them, or whether a refund needs human approval. Those are harness decisions, and they're yours.
Frameworks now treat the harness as a first-class thing to design. Microsoft's Agent Framework shipped an explicit Agent Harness layer this year, because teams kept rebuilding the same tool, memory, and context scaffolding by hand and getting it subtly wrong.
The framework is the engine; the harness is the car you build around it. The same engine goes in a race car and a delivery van, and nobody says the engine defines the vehicle. Neither does the model.
Building a Harness You Can Actually Operate
A production harness needs three properties beyond just working: observable, testable, and versioned. Observable so you can see which tool the agent called and what came back. Testable so you can verify harness changes before they ship. Versioned so a context-policy tweak is a deliberate, reviewable change, not a silent config edit.
Observability. Every tool call, memory read, and context decision should be traceable. When an agent misbehaves, you need to reconstruct exactly what it saw and did. That's not logging the final output. It's logging the trajectory: the sequence of harness decisions that led there. Without it, every debugging session is a guess. We made the full case in the agent observability gap in production.
Testability. Harness changes are risky because they're invisible in the model. Tightening a compaction policy or reordering tool results can silently change behavior on cases your team never checks by hand. Run scenario suites against the harness after every change, the same way you'd run unit tests after a code change. A harness edit with no test is a production experiment.
Versioning. Treat harness configuration as code: the tool set, the memory scope, the context rules, and the approval gates should all live in version control and change through review. A shift from keep-everything to compact-after-ten-turns is a meaningful behavior change. It should show up in a diff, not in a dashboard nobody's watching. The monitoring layer tells you whether the change did what you intended.
- Trace every tool call, memory read, and context decision
- Shape tool outputs to summaries, not raw payloads
- Set an explicit context policy: compact, bound, retrieve, or delegate
- Scope memory per customer to prevent cross-session leaks
- Delegate verbose, disposable subtasks to subagents
- Cap loop iterations so failures do not burn the token budget
- Run scenario suites after every harness change
- Version the harness config and change it through review
None of these eight items is about the model. That's not an accident. The model is a dependency you consume. The harness is the system you build, and it's where your engineering effort compounds.
The Upgrade That Actually Worked
Priya fixed the timezone bug in an afternoon. Not by touching the model, which she rolled back to the cheaper version she'd started with. She changed one thing in the harness: the calendar tool now receives the caller's timezone, resolved from their profile, on every call. The wrong-slot callbacks stopped that week.
Then she did the less obvious thing: she went hunting for the next timezone bug before it earned its own trickle of callbacks. She added tracing to every tool call, shaped the fat JSON payloads down to summaries, scoped memory per caller, and wrote scenario tests for the three interaction types that mattered most, so a future harness change couldn't quietly reintroduce the same failure.
The model she runs today is the same one that was booking wrong slots six months ago. The agent is dramatically better. Everything that changed, changed in the harness.
That's the part the benchmarks don't measure and the model-upgrade cycle keeps hiding. Your agent is a model wrapped in a harness, and the model is the part you don't control. The harness is the part you do. Build that.
Build a harness you can see into
Chanl gives your agent traced tool calls, scoped memory with retrieval, and scenario tests that catch harness regressions before they ship. Build, connect, and monitor the layer where your agent's quality actually lives.
Start free- Agent harness (Wikipedia)
- Addy Osmani, Agent Harness Engineering
- Arize AI, Context management in agent harnesses: memory, files, and subagents
- Microsoft Agent Framework at BUILD 2026: Agent Harness, Hosted Agents, CodeAct
- awesome-harness-engineering
- Long-Running AI Agent Runtime in 2026: Sessions, Sandboxes, Checkpoints, and Harnesses
Co-founder
Building the platform for AI agents at Chanl — tools, testing, and observability for customer experience.
El briefing de Signal
Un email por semana. Cómo los equipos líderes de CS, ingresos e IA están convirtiendo conversaciones en decisiones. Benchmarks, playbooks y lo que funciona en producción.
