Agent harness explained: prompt, context and harness

"Agent harness" is one of those terms that sounds vague until you understand the problem it is trying to solve.

Over the past few months, "harness" has shown up in almost every conversation about AI agents. The most common explanation is that the harness is "the agent's environment". That is correct, but it does not help much in understanding what it is, what it is not, and how it differs from prompt engineering or context engineering.

This article starts from a video on the Caleb Writes Code channel, "Agent Harness explained in 8min", and organises the main ideas with my own reading of what this means for people building products.

The central claim is simple:

Harness engineering does not replace prompt engineering or context engineering. It uses both, inside an environment with clear rules about how the agent starts, executes, verifies and finishes each task.

From prompt to context: how we got here

Shortly after ChatGPT launched in 2022, we were working with context windows of around 4,000 tokens. That was very little room for anything substantial.

You could build agents around that, but it quickly became clear that writing a good prompt was not enough. The question changed:

How do we reuse a small memory space to do more with less?

That is how we moved from prompt engineering to context engineering, with techniques such as:

Tool calling — the agent explores the repository, reads only the files relevant to the task and performs external actions;
MCP (Model Context Protocol) — lets you add vendor-specific capabilities on top of the model;
RAG — connects your own databases so the right information is available when it is needed.

These techniques produced a new generation of agents, mostly for coding. Tools like Cursor, Windsurf, Cline, Roo Code and Aider adopted tool calling to manage context, and they were (and still are) good tools.

At the same time, models improved and context windows grew. Agents began to handle longer tasks, and people started asking them for features and fixes with an ever wider scope.

The ceiling: long tasks and summaries that lose information

Even with good context engineering, there was a limit.

Ask an agent for something enormous, for example "clone this entire website". With a simple prompt, the result is a fragile site, because the model answers in one shot. With context engineering the result improves, but it is still far from ideal: the site is partly finished, some buttons do nothing and some features were never tested end to end.

The problem was not context engineering itself. It was one mechanism in particular: continuous context summarisation.

Imagine a task that takes 12 hours. As the context window fills up, the agent summarises what it has done to free space and carries on. Then it summarises again. And again.

In practice, the agent becomes limited by the quality of its own summaries. That is why you get tasks that are:

half done;
never even attempted;
reported as complete when they were not;
simplified to the point where features are marked as "verified" without ever having been tested.

This elastic way of managing context looked like it could handle long tasks. It was not as effective as it appeared.

The convergence: subagents, swarms and orchestration

Before the term existed, there were already several attempts to work around the problem:

subagents, for hierarchical context management;
agent swarms, where several agents work in parallel, each with its own context window.

All of these pointed in the same direction. The ingredients needed were:

a better orchestration layer;
a better execution environment;
better context management.

That combination is what became known as the agent harness, a term that spread in early 2026. You can see it as a buzzword, but it describes a real shift in how the industry is building agents.

The big change: loops with clean context

The most important change harness engineering brings is the idea of a loop.

Instead of keeping an agent working in one session that keeps accumulating and summarising context, we move a layer above context engineering:

the agent works in iterations;
each iteration receives a fresh, clean prompt and context;
there is a strict rule about how each iteration starts and how it ends.

A typical flow works like this:

You generate a long requirements document (for example, a PRD, a product requirements document);
That document is turned into a structured task list, often in JSON;
In each iteration, the agent picks a single task;
It implements it;
It tests it;
It documents what it did and updates progress;
The iteration ends, and the next one starts with clean context, reading state from files rather than from a summary in memory.

The loop repeats until every task is done.

One of the best-known examples was Ralph (the "Ralph Wiggum loop" technique described by Geoffrey Huntley). What caught attention was not only how well it worked, but how simple the architecture was: the repository is small.

Anthropic published a demonstration with the same logic: a lightweight environment with an initialiser agent that prepares the requirements and the progress log, and an agent that moves forward feature by feature, leaving the work in a clean state at the end of each session.

Many coding agents already build this harness layer directly into the application, each in their own way.

Prompt, context and harness: layers, not replacements

An important clarification from the video: harness engineering does not make context engineering obsolete, let alone prompt engineering.

If you look at the system prompt of open-source agents like Cline, it is still, to a large extent, a well written prompt. What changed is the relative weight:

Prompt engineering — tells the agent who it is and gives it a persona and base rules. Still there, but a smaller part of the system;
Context engineering — decides what the agent sees at any moment: files, tools, data;
Harness engineering — defines the environment and the sequence of steps the agent works in: how it starts, which task it picks, how it verifies and when it stops.

The harness uses the other two layers. The paradigm shift is in the environment, not in abandoning the earlier techniques.

The anatomy of a harness

A useful way to think about it:

Agent = model + harness.

Everything that is not the model is part of the harness. In practice that includes:

execution loop — the cycle that decides when an iteration begins and ends;
tools — tool calling and MCP;
context management — what goes into each iteration;
persistent state — progress files, git history;
execution environment — usually a sandbox;
permissions and approvals — what the agent can do alone and what needs human validation;
verification — tests, linters, automated checks;
orchestration — subagents and coordination between them.

None of these components is new on its own. What is new is treating them as a system designed on purpose.

What this means for people building products

There is one consequence of this model that I find under-discussed.

If the loop starts from a requirements document and executes one task at a time, then the quality of the result depends on the quality of those requirements. An agent with an excellent harness will implement, test and document, with discipline, exactly what it was asked for.

If what was asked for does not solve a real problem, the harness only makes building the wrong thing more efficient.

This is where I see the connection with the work we do at Painstack:

Market signals — what people say, search for and already try to solve;
Organised evidence — testing hypotheses against data instead of intuition;
Validated problem — deciding what is worth building;
Requirements (PRD) — only then writing the document that feeds the loop;
Harness loop — the agent implements task by task;
Tests — with Playwright, for example, to verify the main journeys;
Product in production.

Painstack is not a harness and does not replace engineering. Its role sits before the loop: helping make sure the requirements document starts from a problem backed by evidence.

Validate what to build before automating the building.

Conclusion

The evolution went roughly like this:

Prompt engineering: asking well;
Context engineering: showing the model the right information;
Harness engineering: designing the environment, the rules and the cycle the agent works in.

The most practical lesson is the one about loops: on long tasks, clean context on every iteration and state saved to files tend to work better than a single session that summarises itself until details fall away.

But a harness does not decide what is worth building. That is still our job.

References

Note: the video includes a segment sponsored by Cursor, which was not used as a source for this article.