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

Era What you tune When it dominated Coined / popularized by
Prompt engineering The instruction text 2022–2024 The community at large
Context engineering The information in the window 2025 Tobi Lütke, Andrej Karpathy, Anthropic
Harness engineering The environment around the model 2026 Mitchell Hashimoto, OpenAI, LangChain
Loop engineering  What drives the agent 2026 (emerging)  Boris Cherny, Addy Osmani, IBM
Graph engineering The organization of many agents  2026 (emerging) Community (contested) 

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:

Benchmark Model Spread
Terminal-Bench 2.0 Claude Opus 16 pts
CORE-Bench Claude Opus 36 pts
SWE-bench Pro Claude Opus 24 pts

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:

Component What it does Claude Code example
Execution loop Thought → Action → Observation, repeated until a stop condition The main Claude Code REPL
Tools Schemas the model can call (read, edit, run, search) Read, Edit, Bash, Grep, WebFetch
System prompt + rules Always-loaded guidance CLAUDE.md, ~/.claude/CLAUDE.md
Persistent guides Conditional, auto-discovered guidance Skills (.claude/skills/<name>/SKILL.md)
Filesystem as state Disk holds work in progress, the window doesn't docs/plans/, docs/reviews/, etc.
Sandboxes Bounded blast radius for execution Bash sandbox, MCP-isolated tools
Sub-agents Isolated context for parallel or heavy work .claude/agents/<name>.md
Hooks Deterministic interception of events PreToolUse, PostToolUse, Stop in settings.json
Sensors / oracles Tests, linters, type checkers, review agents — the verification gates test-runner subagent, lint hooks
Context management Compaction, summarization, offloading Auto-compaction in Claude Code
Orchestration Spawning sub-agents, routing, handoffs Agent tool, /skill invocations
Observability Logs, traces, transcripts across iterations Session transcripts, hook outputs

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.

Claude customization mechanisms

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

Each one tunes a different layer. Prompt engineering is about the instruction text itself — what you say to the model in a single message. Context engineering is about what's in the window when the model runs: retrieval, tool calls, memory, system prompts. Harness engineering is about the environment around the model across many windows and iterations: the loop, the sub-agents, the sandboxes, the verification gates. None of them replace each other; a good harness still needs well-engineered context and a well-written prompt underneath it.

Not exactly, think of it as the next layer wrapping the last one, not a swap. Some practitioners frame it as a distinct successor paradigm, others (including Anthropic) call it a specific form of context engineering. We take the layered view: harness engineering wraps context engineering, which wraps prompt engineering. Each layer is additive, and the debate over the "correct" framing is honestly still an open one in the community.

No, and starting with a heavy harness before you need one usually slows you down. The recommended order is: tighten your always-on rules (like a CLAUDE.md), add hooks for your non-negotiables, then build subagents for verification. An outer loop )the Ralph-style 'run until the tests pass' pattern) is the last thing you add, only once your sensors are solid enough to trust the loop to police itself.

Ralph is the minimal harness pattern, literally a while loop, a prompt file the model updates between runs, and the model itself. It works because disk becomes the memory (not the context window), each iteration tackles exactly one task, and git gives you free rollback. It's less a specific tool and more a proof of concept: even the simplest possible harness, if it has a loop and a gate, outperforms a bare model with no scaffolding at all.

This is the exact skeleton our agentic Gen-e2 pipeline runs on: context-gathering subagents, implementation subagents, and a quality gate that won't sign off on 'done' without proof. If you're AI-first and want a harness built to hold up past the demo stage, that's the conversation we're always up for. Reach out and tell us where your loop keeps breaking.

They're the two layers now forming on top of harness engineering. Loop engineering is about who drives the agent: instead of you prompting it turn by turn, a heartbeat, cron job, or goal condition keeps it running until a stop condition is met. The Ralph pattern is the minimal version of this.

Graph engineering goes a level higher, programming the organization of many agents: which nodes exist, which handoffs are allowed, and how work gets routed and governed across them.

Both are early and largely unnecessary until your harness is solid, a loop without trustworthy sensors just hallucinates completion faster, and a graph without reliable loops does the same thing at greater scale. Get the harness right first, these are the layers you reach for once it's all set.

References

Primary sources

Examples and implementations
Ready to kickstart your next big project?
Let's innovate together.
Work with Us