Prompt vs. Context vs. Harness Engineering: The Difference That Actually Matters

On August 26, 2026, a developer asked Claude to build a sandbox mechanism meant to stop AI agents from filling up his disk with temporary files. Claude wrote a script to detect whether other agents were still active before deleting their temp data. The review process flagged the approach twice and downgraded the model partway through. Then, while testing whether the sandbox actually worked, the agent ran a recursive delete against the developer's real home directory instead of the isolated test path. Roughly 700 gigabytes gone.

This wasn't an isolated event either. Anthropic's own Claude Code repository has at least five separately filed incidents describing the same failure class over six months: home directories or root paths getting wiped by an agent-constructed command that nothing in the surrounding system caught before it ran.

The instructions Claude was given were reasonable. The reasoning that led to the test wasn't obviously reckless. What failed was the layer around the model, the part that should have made a destructive command targeting a real home directory architecturally impossible to run. That layer has a name now: the harness. And the industry spent a lot of 2026 figuring out it's a genuinely different discipline from the two that came before it.

Three layers, three different jobs

Prompt engineering is the oldest and narrowest of the three. It's the wording of a single request, the part a person writes by hand to get a better answer out of one model call. If a model misreads a clearly written instruction, that's a prompt problem, and it's usually visible immediately because the answer comes back obviously wrong.

Context engineering is broader. It's the discipline of deciding what information actually fills the model's context window before it answers: conversation history, retrieved documents, tool definitions, memory, application state. Good context engineering doesn't mean stuffing in everything available. More context that isn't relevant adds noise and makes the model more likely to miss what matters, not less. It means curating what the model sees for a given call.

Harness engineering is different from both, and it's the one that doesn't show up in the answer itself. It's the system that runs around the model across an entire task, not a single call: executing tool calls, deciding what's allowed to run without asking, catching a bad result before it reaches the next step, retrying failures, enforcing limits, and giving the whole thing a way to stop. A model with perfect instructions and perfect context can still fail here, because this layer governs what happens after the model decides what it wants to do, not what it's told or what it knows.

This isn't just a terminology debate, the benchmark numbers prove it

If the rm -rf incident sounds like an edge case, a cluster of 2026 research on agent benchmarking shows the same gap shows up constantly, just measured in performance instead of catastrophe. Multiple papers have now documented that holding a model completely fixed and only changing the harness around it moves benchmark scores by a wide margin, often more than switching to a different model entirely.

On SWE-bench Pro, Claude Opus 4.5 scores 45.9% under a standardized evaluation scaffold called SEAL, and 55.4% under the Claude Code harness. That's roughly a 9.5 point swing with the exact same model weights. The Holistic Agent Leaderboard has reported single-model swings of up to nearly 48 percentage points on SWE-bench Verified Mini depending purely on scaffold choice. One analysis found a basic scaffold scoring 23% on SWE-bench Pro while an optimized version of the same setup scored over 45%, a 22-point gain from harness changes alone, no model upgrade involved. In one case, adding a single search subagent to an otherwise identical setup was enough to flip the ranking order between two different frontier models on the same benchmark.

The researchers behind one of these papers put it plainly: a benchmark score is the joint outcome of the model and the harness, but published leaderboards almost always report it as if it were a model property alone.

What was actually missing in the rm -rf case

It's worth being specific about which layer failed, because it wasn't a prompt problem or a context problem. The model wasn't confused about what the user wanted, and it wasn't missing relevant information about the task. What was missing was a boundary the harness should have enforced: no architectural check that stopped a recursive delete from resolving to a real home directory, and no sandbox isolation strong enough to make the test environment's filesystem genuinely separate from the host's.

Related incidents reported in the same repository describe the same gap from different angles: a destructive command hidden inside a self-written helper script, a shell variable expansion that silently turned a scoped delete into a root-level one, a cleanup step that restored the real $HOME value right before the delete ran against it.

None of that is something a better prompt fixes. A better prompt doesn't stop a correctly-written, syntactically valid command from executing against the wrong path. That's what a harness is for.

What the harness is actually made of

Strip the diagram down and a harness is a small number of concrete responsibilities, not one big thing:

• Permissions. The agent needs to know what it's allowed to do without asking, and what it should never be allowed to do regardless of what it reasons its way into.
• Tool execution. A way to run tool calls (files, terminal access, external integrations) and a separate step that checks the result of those calls instead of trusting them blindly.
• State. Something that survives across the task, not just within one model call.
• A bounded loop. Plan, act, check the result, decide whether to continue, retry, or stop, with an actual exit condition instead of trusting the model to know when to give up.

A practical version of the specific gap in the rm -rf case looks like this, a guard that runs before a destructive command executes, not after:

import os
import re

PROTECTED_PATTERNS = [
    r"^rm\s+-rf\s+/\*?\s*$",            # rm -rf / or rm -rf /*
    r"^rm\s+-rf\s+\$?HOME\s*$",         # rm -rf $HOME or rm -rf HOME
    r"^rm\s+-rf\s+~/?\s*$",             # rm -rf ~ or rm -rf ~/
]

def check_destructive_command(command: str, resolved_path: str) -> bool:
    """Returns True if the command is safe to execute."""
    for pattern in PROTECTED_PATTERNS:
        if re.match(pattern, command.strip()):
            return False
    if resolved_path in (os.path.expanduser("~"), "/"):
        return False
    return True

That's not a sophisticated piece of engineering. It's a few lines that check what a command actually resolves to before letting it run, instead of trusting that a reasonable-sounding instruction produces a safe result. The GitHub issues on this exact incident class recommend close to this: evaluate destructive commands after shell expansion, not before, and sandbox agent execution away from host mounts by default so that even a command that does go wrong lands somewhere recoverable.

Where the terminology gets genuinely contested

Worth being honest that this isn't fully settled as a field yet. Most sources describe these three as nested layers, harness wraps context, context wraps prompt, where a strong harness still needs good context and a well-written prompt underneath it, it just adds leverage on top.

But the disagreement around that framing is real, not just semantic. Some writers treat harness engineering as a superset covering the other two rather than a separate layer stacked on top of them. And there's an emerging fourth term, sometimes called loop engineering or graph engineering, for the coordination layer when multiple agents or sub-agents work together, which some treat as part of the harness and others treat as its own discipline entirely. If you see slightly different diagrams in different places, that's why.

The actual takeaway

A good harness doesn't make the model smarter. It makes the system around the model survive the model being wrong, which it eventually will be, no matter how good the prompt or how well-curated the context.

The rm -rf incidents are a clean example precisely because nothing about them was a strange edge case. An agent testing whether a cleanup mechanism works is an extremely ordinary task. The failure wasn't exotic. The missing guardrail was.

If you're building anything that gives a model real tool access, the question worth asking isn't "is the prompt good enough" or "does it have the right context." It's: what happens the one time this agent does something destructive, and is there anything in the system, not the instructions, that catches it before it runs.

Resources

1. Bouchard, Louis. Harness Engineering: The Missing Layer Behind AI Agents. louisbouchard.ai.
2. AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents. arXiv.
3. Stop Comparing LLM Agents Without Disclosing the Harness. arXiv — source of the SWE-bench Pro and HAL scaffold-swing data.
4. The Double Measurement Confound in Agent Benchmarks. arXiv — on scaffolding as an uncontrolled variable.
5. Claude agent deleted about 700 GB from a developer's home directory during sandbox test. MLQ.
6. Catastrophic data loss. anthropics/claude-code issue #82165.
7. Data loss. anthropics/claude-code issue #88462.
8. SWE-bench in 2026: Benchmarks vs Scaffolding Reality. Digital Applied.
9. Gupta, Aakash. Harness Engineering: Your Complete Guide. news.aakashg.com.
10. Prompt, Context, Harness, Loop: The Four Layers of AI Agent Engineering. Future AGI.
11. Beyond the Prompt: Why Harness Engineering Is a Lever for AI Agents. PALO IT.
12. Context Engineering and Harness Engineering: Building Reliable AI Agents Beyond Prompts. DEV Community.
13. Harness Engineering vs Prompt Engineering vs Context Engineering Explained. Medium.