An AI model can solve hard problems and write convincing code, yet an agent built around that same model can struggle to book a flight or star a GitHub repository.
The failure rarely comes from anything difficult. It comes from something ordinary: a login screen, a network timeout, a button that moved since yesterday. A capable model is only one part of a reliable agent. It also needs software that manages access, executes actions, handles failures and checks results. That surrounding system is the harness.
AI agent = LLM + harness
What is harness engineering?
Harness engineering is the work of building the systems that let an AI model complete tasks reliably. Think of the model as an engine. The engine supplies power, but a working vehicle also needs steering, brakes, controls and instruments. The harness provides those functions for an agent.
| Component | What it does | What goes wrong without it |
|---|---|---|
| Tools | APIs, browser automation and other capabilities the agent uses to act | The agent can describe the action but cannot take it |
| Memory | Stores previous actions, results and relevant preferences | It repeats work it already did, or forgets what it learned |
| Context management | Selects the information the model needs for its next decision | Decisions made on stale, missing or bloated input |
| Guardrails | Checks and permissions that define what the agent may do | An action with real consequences taken without approval |
| Observability | Logs and traces of tool calls, results, errors and cost | A failure you cannot explain, and therefore cannot fix |
| Verification and feedback | Confirms whether an action worked, and tells the model when it did not | “Done” reported with nothing behind it |
Together these connect the model’s decisions to real actions and measurable outcomes. If you have read the five-part anatomy of an agent, the harness is everything in that picture except the brain.
Better prompts cannot fix every failure
Clear prompts help an agent understand its task. They cannot supply missing permissions or repair a broken integration.
Ask an agent to star a GitHub repository. If it meets a login screen, telling it to “think step by step” will not authenticate it. Without proper authentication and verification, the agent either fails — or, worse, reports success with no evidence.
A well-designed harness handles this in code. It provides an authorised connection, keeps credentials outside the model’s context, executes the request and checks the result. Standardising that tool access is exactly the problem the Model Context Protocol sets out to solve.
The practical lesson is simple: prompts guide the model, but the surrounding software must support execution.
Stop runaway loops before they become expensive
Agents usually work in a loop:
- Choose the next action.
- Call a tool.
- Read the result.
- Decide whether to continue.
That loop is what lets an agent finish multi-step work. It is also what lets it repeat a failing action indefinitely without making progress. A harness needs hard limits:
- A maximum number of model or tool calls.
- A timeout for the task as a whole.
- A spending or token budget.
- A retry limit for repeated errors.
The system might stop after eight iterations and report what remains unresolved. The right limit depends on the task. What matters is that a recoverable failure never turns into an expensive, open-ended process.
Verify results before reporting success
An agent saying “done” is not proof that anything happened.
If the task was to star a repository, the harness should check that the repository is actually starred — through an API response or by inspecting the resulting browser state. If the action failed, the model should get useful feedback back: what was attempted, what happened, and what is still incomplete. It can then retry within its limits, try another route, or explain why it cannot continue.
Success should rest on observable evidence. The same rule applies to sending an email, updating a database or deploying an application.
What that looks like in code
Stripped to its skeleton, a harness is a bounded loop with a check at the end. The model decides; the harness acts, counts, and verifies:
MAX_STEPS = 8
BUDGET_USD = 0.50
def run(task):
state = {"task": task, "history": []}
spent = 0.0
for step in range(MAX_STEPS):
action = model.decide(state) # the LLM chooses
if action.kind == "finish":
break
result = tools.execute(action) # the harness acts
spent += result.cost
state["history"].append((action, result))
if spent > BUDGET_USD:
return report(state, "stopped: budget exhausted")
# Never trust "done" - check the world.
if verify(task):
return report(state, "verified")
return report(state, "unverified: " + describe_gap(task))For the GitHub example, verify() is a single request: GET /user/starred/{owner}/{repo} returns 204 if the repository is starred and 404 if it is not. The model’s opinion never enters into it.
Check before you retry
For actions with side effects, the harness should confirm whether the first attempt succeeded before trying again. The GitHub example happens to be forgiving: starring is a PUT, and starring an already-starred repository changes nothing. Sending an email is not forgiving. A timeout does not mean the message was never sent, and a blind retry sends it twice. Check state first, or attach an idempotency key so the receiving system can recognise the repeat.
A better harness can improve cost and reliability
When an agent performs poorly, switching to a larger model looks like the obvious fix. The surrounding workflow deserves a look first. Unnecessary tool calls, oversized context, repeated retries and weak error handling all raise cost and lower reliability — and none of them are solved by a bigger model.
Improving the harness addresses them directly:
- Give the model relevant information at the right time.
- Use direct APIs where they are appropriate, rather than driving a browser through the same task.
- Return clear, actionable tool errors.
- Avoid repeating work.
- Stop as soon as the outcome is verified.
The gains depend on the task, the model and the implementation. Measure completion rate, cost, latency and failure patterns before deciding what to change.
Context engineering and harness engineering work together
Context engineering is about the information available to the model: retrieval, conversation history, summaries and context-window management. Its central question is does the model have what it needs to make a good decision? Retrieval is where that most often breaks — see why RAG fails once your data is not English-only text.
Harness engineering covers the broader execution system: tools, permissions, state, retries, budgets and verification. Its central question is can the agent carry out that decision reliably, and confirm the result?
The two are tightly linked. Good context produces better decisions; a good harness turns those decisions into controlled, verifiable actions.
Build for the moments when things go wrong
A convincing demo shows that an agent can finish a task under favourable conditions. Production requires it to cope with expired credentials, unavailable tools, ambiguous responses and partial failures. That is where harness engineering matters most — and why deciding which actions an agent may take alone, and which need a human, is part of the harness rather than an afterthought.
A capable model helps. Clear prompts help. Reliable agents also need carefully designed software around them.
Before upgrading the model, ask: what happens when the next action fails?