Harness Engineering in Plain English

Who this is for

• Software engineers running coding agents (Claude Code, Cursor, Codex) on real projects.
• Tech leads and security architects who decide what an agent is allowed to touch.
• Platform and operations teams who pay the token bill for agent workloads.

What you will be able to do after reading

• Tell prompt, context, harness and loop engineering apart, so you fix the right layer when an agent fails.
• Name the five jobs a model can never do for itself, and spot which one your setup is missing.
• Run a five-question test that shows whether your agent could wipe production tomorrow.

What is harness engineering, in one paragraph

Harness engineering is the work of building everything around an AI model so that an agent behaves safely in a real system. A raw language model is stateless. Text goes in, text comes out. The harness is the code, configuration, sandbox, tools, memory and rules that turn that text into actions. A useful picture is a strong horse and its harness. The horse supplies the power, and the harness decides where that power goes. The picture breaks in one important place. A horse avoids a cliff on its own. A model does not. Given a destructive command and the permission to run it, a model will run it with full confidence, because nothing inside the model measures the damage.

How is a harness different from prompt, context and loop engineering

When an agent fails, ask which row failed. A better prompt cannot fix a missing permission boundary, and a bigger context window cannot stop a command that the harness lets through.

Job 1, who decides what the agent may do

The most common cause of agent damage is excessive agency. The agent holds credentials far wider than its task needs. An agent that only has to read a database schema but holds a full-access key is one bad guess away from a deletion. OWASP lists excessive agency as one of the top risks for applications built on large language models.

The first step of the fix is to keep raw credentials out of the agent’s workspace. Route external calls through a proxy that adds the credential on the way out, so the agent never sees the secret and can only call methods you approved. The full agent permission matrix, ready to copy, is in the Field Kit.

Job 2, who checks that the work really happened

Agents grade their own homework generously. An agent will often report success because it wrote code, not because the code ran and passed. Trusting that report is how broken changes reach production.

The first step of the fix is to require outside proof. A task is not complete until a separate check, such as real test results or a reviewer with a fresh context, confirms it. Anthropic’s engineering team describes this kind of pattern for long-running agents, where progress is tracked in files and features are marked passing only after testing.

Job 3, what stops a retry from doing the work twice

Long tasks outlive the model’s memory. After a context reset, an agent can forget that a module was already migrated and start again, burning tokens and creating conflicts.

The first step of the fix is an external progress record that the harness makes the agent read at the start of every session, such as a progress log and a feature list kept in the repository. The Field Kit includes a 30-minute failure test that shows whether your setup survives an interrupted run.

Job 4, what catches a mistake before it lands

When an agent hits a blocker, it may try a drastic workaround, such as deleting a directory or a database table to clear an error. The model does not feel the risk. The harness has to.

The first step of the fix is to intercept tool calls before they run. Coding agents increasingly support hooks that fire before a tool executes. Claude Code, for example, documents a PreToolUse hook that can allow, deny or ask for confirmation. A hook that blocks known destructive patterns stops the command before it reaches the operating system.

Job 5, who answers for every action

After an incident, teams often cannot tell whether a person or an agent ran the command. Ordinary logs are weak evidence, because an agent with broad permissions can change or delete them.

The first step of the fix is an append-only audit trail that ties every tool call to a session and an identity, stored where the agent cannot edit it. Some engineers are proposing hash-chained formats for this, such as AIVS, which is currently an individual IETF Internet-Draft and therefore still work in progress.

What happens when a harness job is missing

In April 2026, PocketOS published a post-mortem after an AI coding agent (Cursor running Claude Opus 4.6) deleted its production data in about nine seconds. The agent was working on a staging task, hit a credential mismatch, found a Railway CLI token with far broader powers than anyone realized, and used it to delete a volume. Because the provider kept volume backups inside the same volume, the backups went with it.

The model was not malicious. Two harness jobs were missing. Job 1 failed because a broad token sat within reach of the agent. Job 4 failed because no check paused a destructive call for a human to approve. Either one, in place, would have stopped the damage.

Is my harness production-ready, a five-question test

1. Are the agent’s API keys held outside its workspace, or can it read them in plain text?
2. Are destructive actions blocked by infrastructure, or only by a sentence in the prompt?
3. If the agent loops, is there a hard token or cost cap and a working stop switch?
4. Is every claim of done verified by a separate check before it counts?
5. Could you prove, for the last 30 days, which actions an agent took and which a person took?

If you answered no to any question, that is the job to build first. The Field Kit has a failure test for each one, the risk-tier template and a 30-day rollout plan for a small team.

Questions engineers ask

What is harness engineering?

It is the work of building the tools, permissions, state, checks and audit around an AI model so that an agent acts safely in a real system.

Is an agent framework the same as a harness?

No. A framework gives you building blocks. The harness is the running environment, rules and checks those blocks execute inside.

Can a better prompt replace a harness?

No. Prompt instructions influence the model but do not enforce limits. Only infrastructure can reliably block a destructive action.

Why do long-running agents fail without a harness?

They lose track of progress when the context resets. External progress files and verified task lists keep them on track.

Does prompt caching matter for harness design?

Yes. Providers such as Anthropic cache a stable prompt prefix, so keeping fixed instructions first and changing data last can lower cost and latency.

RamthaMedia is not affiliated with Anthropic, Google, OpenAI or GitHub.