EXPLAINER

The model is the hire. The harness is the job.

Everyone argues about which model is best. Almost every agent that fails in production fails somewhere else — in the scaffolding around the model. Here is what that scaffolding is made of, one part at a time.

September 2026 · 9 minute read · Every animation can be replayed

1A model on its own cannot hold a job

Picture the best new hire you have ever met. Sharp, quick, genuinely knowledgeable. Now put them in an empty room on their first morning. No desk. No files. No login. Nobody to ask. No one checking their work before it reaches a customer.

They would be useless — not because they lack ability, but because ability was never the missing piece. A language model is in exactly that position. It is a pure function: text goes in, text comes out. It cannot remember yesterday, it cannot look anything up, it cannot take an action, and nothing stops it acting on a misunderstanding.

The harness is everything you build around the model so it can actually do a job: the workspace it runs in, the notes it keeps, the rules it follows, and the person who signs off before anything reaches a customer.

In plain terms. The model is the hire. The harness is the job — the desk, the filing cabinet, the handbook and the manager. Swapping in a smarter model rarely fixes a weak harness.

2Six parts do the work

A production agent is not one clever prompt. It is a small system, and it has recognisable organs. Six of them carry most of the weight.

The six parts, around the model

They are not optional extras you add once something breaks. Each one closes a specific failure mode, and the failure modes are predictable.

3Sandbox — somewhere safe to be wrong

The moment an agent can run code, send messages or touch a database, a misunderstanding stops being a bad sentence and becomes a bad action. A sandbox is a walled-off place to act: a container, a scratch directory, a test account, a database copy.

The point is not that the agent will behave. The point is that when it does not, the blast radius is a throwaway environment rather than your production data.

The action bounces. Production never sees it

Failure it prevents. A confident agent deleting or messaging something real because it misread one instruction.

4Sub-agent orchestration — narrow jobs, focused workers

One agent asked to do six things at once does all six adequately and none of them well. Its instructions grow long, its attention spreads thin, and every extra tool you hand it makes the next decision harder.

The fix is delegation. A coordinator breaks the work into narrow jobs and hands each to a sub-agent with its own short instructions and a couple of tools. Each one has a small decision to make, so each one makes it better. The results come back to the coordinator to assemble.

One broad task becomes three narrow ones

Failure it prevents. An agent with twenty tools and a two-page prompt that quietly picks the wrong one.

5Observability — being able to answer "why did it do that?"

An agent that gives a wrong answer once is a curiosity. An agent that gives a wrong answer and leaves no trace is unfixable, because you cannot tell whether the model misread the request, a tool returned bad data, or a retry silently swallowed an error.

Observability means every step is recorded: what the agent was asked, what it decided, which tool it called, what came back, how long it took and what it cost. When something goes wrong you read the trace instead of guessing.

A readable trace of the whole run

Failure it prevents. A bug you can reproduce for a customer but never explain, so you never actually fix it.

6Compression — keeping what still matters

Every model has a finite context window, and a long-running agent will fill it. Once it is full something has to go, and if you have not decided what, the system decides for you — usually by dropping the oldest messages, which is often where the actual instructions were.

Compression is doing that deliberately: summarise the settled part of the conversation, keep the decisions and the open questions, drop the transcript. It also cuts cost, because you are re-sending a summary rather than an ever-growing history on every single turn.

Keep the decisions, drop the transcript

Failure it prevents. An agent that forgets its own instructions halfway through a long task — and a bill that grows with every turn.

7Evaluator — scoring the work before it ships

"It looked fine when I tried it" is not a quality bar, and it does not survive a prompt change. An evaluator is a fixed set of cases with known-good answers, run automatically, scoring each output against a standard.

It can be a second model grading the first, a rule check, or simply an assertion that the reply contains a real appointment time. What matters is that it runs every time, so a change that improves one case and breaks four others is caught by you rather than reported by a customer.

Nothing ships unscored

Failure it prevents. A prompt tweak that quietly makes the agent worse, discovered weeks later.

8Approval loop — a person signs off on anything irreversible

Some actions can be undone and some cannot. Drafting a reply is reversible. Sending it to a patient is not. Refunding money, deleting records, posting publicly, messaging a customer at 2am — those need a human in front of them.

An approval loop is the rule that the agent drafts and a person sends. It sounds like it defeats the purpose, and it does not: the agent still does the reading, the reasoning and the writing, which is the slow part. The human does the one-second check that keeps the whole thing trustworthy.

The agent drafts. A person sends

Failure it prevents. The single message to a real customer that you would give anything to take back.

9The six, side by side

Part	What it does	What goes wrong without it
Sandbox	A walled-off place to run code and take actions	A misunderstanding becomes a real, irreversible action
Sub-agents	Narrow jobs handed to focused workers	One overloaded agent picks the wrong tool
Observability	A recorded trace of every step	Bugs you can see but never explain
Compression	Keeps the decisions, drops the transcript	The agent forgets its own instructions; costs climb
Evaluator	Scores output against a standard, every time	Quality drifts silently after each change
Approval loop	A human signs off on anything irreversible	The message you cannot take back

10What this looks like in a real system

We run a WhatsApp booking agent for clinics. Patients message at any hour, it answers, finds a slot and books it. The model doing the reasoning is a commodity — you could swap it for a competitor and patients would not notice.

Everything that makes it trustworthy is harness. Bookings are written to a test calendar until the flow is proven. Availability lookup and reply-writing are separate steps rather than one large prompt. Every conversation is logged end to end, so when a booking goes wrong we can read exactly what happened. Long threads are summarised down to the patient, the reason for the visit and the slot. A fixed set of awkward messages is replayed after every change. And anything involving a cancellation or a refund is drafted for the front desk rather than sent.

The line worth keeping. When an agent is unreliable, the instinct is to reach for a better model. Look at the harness first — that is almost always where the problem lives.

Want this built for your business?

We build WhatsApp and workflow agents for clinics and small businesses in Mumbai — with the harness included, not bolted on later.

Talk to us on WhatsApp

← Back to Concepts