Beyond the Prompt: Why Harness Engineering Is a Lever for AI Agents

Three settled eras of working with LLMs, plus two more taking shape, each a different thing you tune. Each one builds on the last, none of them get deprecated.

TL;DR

Mental model:

Graph (emerging)  
  └── Loop (emerging) 
      └── Harness
          └── Context
              └── Prompt

Each layer wraps the one below. A great harness still needs a well-engineered context and a well-written prompt, it just gives you more leverage on top.

An analogy: commissioning a house

Start with the three settled eras — three ways to hire a builder, three levels of leverage:

1. Prompt engineering — You hand the builder verbal instructions: "two bedrooms, brick, finished by June." Whatever they already know, plus what you said, is what you get.
2. Context engineering — Same instructions, plus blueprints, a materials list, the site survey, and a phone to call you with questions. The builder has everything they need to act, not just to remember.
3. Harness engineering — All of the above, plus the worksite itself: scaffolding, a foreman who reviews each day's work, quality inspectors who sign off before the next phase starts, and specialist sub-contractors (electrician, plumber) you can call in for specific jobs. The builder isn't just told what to do — they're operating inside an environment that catches mistakes and keeps work moving.

Each layer is additive. A great harness still needs good blueprints (context) and clear instructions (prompt), it just surrounds them with a worksite designed for reliable delivery.

One trap to avoid: "harness = tools" is a tempting shortcut, but in agent vocabulary "tools" usually means function calls (Read, Edit, Bash) and tool calling arrived with context engineering, not the harness. The harness is more than tools; it's the worksite around them.

Why the terms keep changing

Each term emerged when the previous one stopped capturing the most important lever for getting useful work out of a language model.

• Prompt engineering was the lever when the context window was 4k tokens and every interaction was one-shot. You squeezed quality out of a single message.
• Context engineering became the lever when context windows grew to hundreds of thousands of tokens and tool calling let agents pull in their own information. The bottleneck moved from "say it well" to "fill the window with the right stuff at the right moment."
• Harness engineering became the lever when tasks got long enough that no single context window could hold them. The bottleneck moved again — to the environment the model operates inside: the loop, the file system, the sub-agents, the verification gates.

The pattern is consistent: each new era names existing practice that had outgrown the previous label, not a new technique invented from scratch.

Prompt Engineering (2022–2024)

The first era: writing the single instruction that produces useful output in one shot. Few-shot examples, chain-of-thought, role prompts, output format constraints.

What it solved. ChatGPT shipped with a 4k-token context window. To get good work out of it you had to pack the request densely and rely on the model's training. There was no looping, no tool use in production, no MCP, just messages.create() and pray.

Where it ran out. As soon as people started asking the model to work over more than a few hundred lines of code, "write a better prompt" stopped scaling. You couldn't fit the codebase. You couldn't update your prompt every time the file changed. And the model couldn't ask for what it needed, it could only work from what you'd already pre-loaded.

Prompt engineering didn't go away, it became the innermost layer of everything that came after. Open-source coding agents like Cline and Aider still use carefully tuned system prompts; they just don't only use them.

Context Engineering (2025)

"The delicate art and science of filling the context window with just the right information for the next step." — Andrej Karpathy, June 2025

Coined informally by Shopify's Tobi Lütke in mid-2025 and amplified by Karpathy on X. Anthropic gave it institutional weight in Effective context engineering for AI agents (September 2025), framing it as "the natural progression of prompt engineering."

What it covers. Everything that decides what tokens are in the window when the model runs:

• Retrieval-augmented generation (RAG) — pull relevant docs on demand from a vector store
• Tool calling — let the model fetch files, search the web, query the database itself
• MCP — vendor-specific tools and resources injected at runtime (Jira, Figma, GitHub, Confluence)
• Memory and state — what gets carried between turns, what gets summarized away
• System prompt and rules — CLAUDE.md, AGENTS.md, project conventions

What it solved. With million-token windows and tool use, models could explore a real codebase, read what they needed, and take actions. Cursor, Windsurf, Cline, Aider, the first wave of coding agents , all worked this way.

Where it ran out. Tasks kept getting longer. People started asking coding agents to "clone this site end-to-end" or "migrate this service from Express to Fastify." Two failure modes emerged:

1. Compaction drift. When the window filled up mid-task, the agent summarized its history to keep going. Summaries lose detail. The agent would "remember" finishing tests it hadn't run, or marking buttons "implemented" that didn't work. The longer the task, the worse the drift.
2. No room to recover. A single context window had to hold the full task forever. There was nowhere to reset, nowhere to delegate cleanly, nowhere to verify without paying for the verification tokens in the same window.

Context engineering also didn't go away, it became the next layer, sitting between the prompt and what came next.

Harness Engineering (2026)

"Any time you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again." — Mitchell Hashimoto, My AI Adoption Journey, February 2026

The term was crystallized by Mitchell Hashimoto in February 2026 and adopted by OpenAI days later. LangChain's Vivek Trivedy followed with The Anatomy of an Agent Harness (March 2026) and the now-quoted formula:

Agent = Model + Harness

What a harness is. Everything around the model that turns a single inference call into a useful agent: the loop, the tools, the sub-agents, the sandboxes, the hooks, the file system, the verification gates, the observability.

What it adds over context engineering. Context engineering optimizes what's inside one window. Harness engineering optimizes the whole environment across many windows over time. The new primitives are the outer loop, fresh contexts per iteration, and verification gates the model can't reason around.

The harness effect

If "harness engineering" sounded like a buzzword, the benchmarks argue otherwise. Daniel Vaughan's The Harness Effect (April 2026) aggregates published numbers showing the same model swings significantly depending on which harness wraps it:

The takeaway: harness engineering is a measurable performance lever, often bigger than the gap between adjacent model generations. Choosing your harness matters as much as choosing your model.

The minimal harness: Ralph

Geoffrey Huntley's Ralph Wiggum as a "software engineer" (July 2025) predates the term but became the canonical example:

while :; do   
   cat PROMPT.md | claude-code 
done

That's the whole harness. A loop, a prompt file (which the model updates between iterations), and the model itself. Each iteration starts fresh, reads what's left to do, picks one task, completes it, updates the spec, and exits. The next iteration starts clean.

Ralph works because:

• Disk is state. The PRD and TODO list live on the filesystem; the context window is disposable.
• One task per iteration. The model can't drift across an 8-hour task because it never sees an 8-hour task — only the next item.
• Git is memory. Each iteration commits its work. Roll-back is free.
• Tests are the gate. The loop continues until the spec is satisfied and the tests pass — no human "looks good to me" required.

Most production harnesses (Claude Code, Codex CLI, Cursor's cloud agents, Devin) are richer than Ralph, but they share the same skeleton.

Anatomy of a Harness

Synthesizing across LangChain's 11-component breakdown, Anthropic's Claude Agent SDK post, and Birgitta Böckeler's taxonomy, here are the components a coding harness typically wires up:

Böckeler groups these into two roles:

• Guides (feed-forward) — what the model sees before it acts. System prompts, skills, MCP resources, tool descriptions.
• Sensors (feedback) — what tells the model whether it's done. Tests, linters, review subagents, hooks that reject bad output.

Engineering a harness means tuning both, and treating sensor failures as architecture problems, not prompt problems.

Claude Code as a Harness

Claude Code is itself a harness around the Claude model. The customization mechanisms map directly to the components above.

Each of these is a knob you turn when engineering the harness for a specific project:

• CLAUDE.md is your always-on guide. Project conventions go here.
• Skills are conditional guides, the model loads them based on context. Good for workflows that fire on specific triggers (e.g. a /security-review skill).
• Slash commands are explicit guides, the human triggers them. Good for steps that always need a user in the loop.
• Subagents give you isolated context windows. Good for high-volume exploration or verification work whose intermediate output you don't want in the main thread.
• Hooks are sensors, they intercept tool calls and can reject, modify, or augment them. Good for non-negotiable rules (no force-push, no skipping tests, no editing secrets.env).
• MCP gives the harness access to external systems (Jira, Figma, GitHub, Confluence).

PALO IT's Gen-e2 (our AI-first engineering methodology) pipeline is a harness built on these primitives: context-gathering subagents, implementation subagents, and a quality gate of test-runner / security-advisor / ui-reviewer subagents working through shared documents in docs/.

What's Still Disputed

The term is new and the community hasn't fully aligned. A few things to know:

Is harness engineering a successor to context engineering, or a layer on top of it? Böckeler and Anthropic frame it as a layer ("a specific form of context engineering"); other writers frame it as a successor paradigm. This page takes the layered view, harness eng wraps context eng wraps prompt eng, but the disagreement is genuine.

Is "harness" the same as "framework"? Not quite. The loose consensus: a harness is a runtime you live inside (Claude Code, Codex CLI, Cursor); a framework is a library you compose (LangGraph, CrewAI, AutoGen, MetaGPT). The line is fuzzy, LangChain's DeepAgents is described as both.

Was Ralph a harness? Huntley's original post (July 2025) doesn't use the word. The community retroactively classified it as the minimal harness pattern after Hashimoto coined the term. A reasonable retcon, Ralph captures the loop + spec + gate skeleton that every richer harness shares.

The substantive techniques behind harness engineering, loops, sub-agents, sensors, file-based state, all predate the term. The naming is what's new; the practice was already converging.

What comes after the harness?

If harness engineering was the 2026 story, two newer terms are already forming the next layers. Both fit the wrapping model this page uses.

Loop engineering. The harness gives you a reliable environment. Loop engineering is about who drives it. The shift, crystallized across developer threads in mid-2026, is from you prompting the agent to a system that prompts the agent: heartbeat, cron, hook, and goal loops that run until a stop condition is met. In our layered terms, a loop runs on top of a solid harness. The Ralph section above is really the minimal loop, loop engineering just names the practice and adds richer triggers. IBM and others have since published formal definitions, a sign the term is stabilizing rather than trending.

Graph engineering. Newer still, and more contested. Where a loop programs one agent's behavior, a graph programs the organization of many agents: which nodes exist (agents, deterministic functions, routers, human checkpoints), which handoffs are permitted, and how work gets routed and governed across them. The honest state of play: the label's provenance is unsettled, it collides with an older knowledge-graph usage, and even seasoned practitioners have publicly questioned how much it differs from existing graph-orchestration frameworks. The underlying practice, governed multi-agent topologies, is real and has a documented lineage. The name is what's still settling.

How the layers stack (in our view):

Graph → the organization of many looped agents    
 └── Loop → what drives a single agent inside its harness       
    └── Harness → the environment around one model  
       └── Context → what's in the window  
          └── Prompt → the instruction itself

Same pattern as before, each layer wraps the one below and none get deprecated. For enterprises the practical takeaway is unchanged. Get the harness solid first. Loops without trustworthy sensors just hallucinate completion faster, and graphs without reliable loops just do it at greater scale. That's the ground our agentic Gen-e2™ pipeline is built on: verification gates that hold whether you're running one loop or orchestrating many.

Building Your Own

If you're starting from a Claude Code project today:

1. Tighten the always-on layer. Write a focused CLAUDE.md — project conventions, where things live, what the model should never do.
2. Add hooks for non-negotiables. Anything that's "the model must never X" belongs in a hook, not a prompt. Hooks fire deterministically.
3. Use subagents for verification. A test-runner subagent that runs the test suite and reports pass/fail is the simplest oracle you can build. Wire it into your workflow so the model can't claim "done" without it.
4. Build skills for workflows that have a shape. Things like /plan, /execute, /validate
5. Push state to disk. Plans go in docs/plans/. Reviews go in docs/reviews/. Architecture decisions go in docs/architecture/. The context window is disposable; the filesystem is forever.
6. Once the harness is solid, consider an outer loop. If your tasks are long enough and your sensors are strong enough, a Ralph-style loop becomes viable. Don't start here.

Order matters. A loop without sensors produces hallucinated completion at high speed. A sensor without a loop wastes its signal. Build the gates first.

On GitHub Copilot? The same primitives apply: always-on instructions, conditional prompts, custom agents, skills. Microsoft's hve-core packages a ready-made set (49 agents, 102 instructions, 63 prompts, 11 skills) as a VS Code extension and CLI plugin for Copilot users, a useful reference for what a packaged Copilot harness looks like.

Loops, sensors, sub-agents, skills , it's a lot of knobs to turn, and most teams are figuring out the right combination in production. That's exactly the kind of work we live in every day. Our agentic Gen-e2 pipeline is built on the same primitives we just walked through: context-gathering subagents, implementation subagents, and a quality gate that won't let "done" slide through without proof.

If you're AI-first and want a harness that actually holds up past the demo, we'd love to hear what you're building. Reach out, swap war stories, or just tell us where your loop keeps breaking . Get in touch.

FAQ

References

Primary sources

• Mitchell Hashimoto, My AI Adoption Journey — February 2026. Closest thing to a canonical coinage of "harness engineering."
• Ryan Lopopolo (OpenAI), Harness engineering: leveraging Codex in an agent-first world — February 2026. OpenAI's institutional definition.
• Geoffrey Huntley, Ralph Wiggum as a "software engineer" — July 2025. The minimal harness pattern.
• Andrej Karpathy, tweet defining context engineering — June 2025.
• Simon Willison, Context engineering — June 2025.
• Anthropic, Building effective agents — December 2024. Pre-harness foundations.
• Anthropic, Effective context engineering for AI agents — September 2025.
• Anthropic, Building agents with the Claude Agent SDK — September 2025. Names the SDK as "the agent harness that powers Claude Code."
• Vivek Trivedy (LangChain), The Anatomy of an Agent Harness — March 2026. 11-component breakdown and the Agent = Model + Harness formula.
• Simon Willison, How coding agents work — March 2026.
• Birgitta Böckeler (Thoughtworks), Harness engineering for coding agent users — April 2026. The guides/sensors taxonomy.
• Daniel Vaughan, The Harness Effect: Same Model, Different Tool, Different Score — April 2026. Benchmark synthesis showing the harness can shift scores by 16–36 points.
• Dex Horthy (HumanLayer), A Brief History of Ralph — January 2026.
• IBM (Ivan Belcic & Cole Stryker), What Is Loop Engineering? — July 2026.
  
• Yash Thakker, Graph Engineering: After Loops, This Is How You Wire Multi-Agent Orgs — explainx.ai, July 2026

Examples and implementations

• Ralph-orchestrator — Ralph-pattern implementation with role-based agents.
• LangChain DeepAgents — Batteries-included harness on top of create_agent.
• microsoft/hve-core — Copilot-side packaged harness: instructions, prompts, agents, and skills as a VS Code extension and CLI plugin.
• awesome-harness-engineering — Curated list of tools and patterns.