Context vs Prompt vs Loop vs Harness Engineering: The Four-Layer Agent Stack

Every week in mid-2026, a new term lands on Hacker News — context engineering, loop engineering, harness engineering — and teams treat them as interchangeable upgrades to "prompt engineering."

They are not interchangeable. They are four layers of the same stack, each with different units of work, failure modes, and tools.

• Prompt engineering asks: How do I word this message?
• Context engineering asks: What does the model see on this call?
• Loop engineering asks: What autonomous workflow repeats until a goal is met?
• Harness engineering asks: What code runs the loop, tools, and verification reliably?

Confusing them is expensive. A team that rewrites prompts when the harness has no verification step will never fix silent failure loops. A team that builds a sophisticated harness with vague goals will burn tokens forever.

The same model can also consume radically different token totals across harnesses, but token count alone is not a quality score. The Cursor cost-transparency and harness-efficiency analysis shows how to compare verified task success, time, cache behavior, and dollars together.

This guide maps the full stack — with diagrams, diagnostics, and links to explainx.ai's deeper guides on each layer.

TL;DR — the four layers at a glance

Nesting rule: Harness implements loops → each loop step assembles context → context contains prompts.

The stack diagram

┌─────────────────────────────────────────────────────────────┐
│  HARNESS ENGINEERING                                        │
│  Runtime: tool exec, sandbox, retries, checkpoints, logs    │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  LOOP ENGINEERING                                     │  │
│  │  Workflow: trigger, goal, actions, verification, memory │  │
│  │  ┌─────────────────────────────────────────────────┐  │  │
│  │  │  CONTEXT ENGINEERING (per iteration)            │  │  │
│  │  │  Assembly: history, RAG, tools, CLAUDE.md, MCP  │  │  │
│  │  │  ┌───────────────────────────────────────────┐  │  │  │
│  │  │  │  PROMPT ENGINEERING (messages inside)     │  │  │  │
│  │  │  │  Wording: role, format, constraints, CoT  │  │  │  │
│  │  │  └───────────────────────────────────────────┘  │  │  │
│  │  └─────────────────────────────────────────────────┘  │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
         ▲                              ▲
         │                              │
    Boris Cherny:                  Andrej Karpathy:
    "build loops"                  "context engineering"
    (loop + harness)               (context + prompt)

Think of it like web development:

You would not fix a broken payment API by rewriting button copy. Same logic applies here.

Layer 1 — Prompt engineering (innermost)

Definition: Optimizing the text of individual messages — usually the system prompt and current user turn — to elicit better model behavior.

Techniques: Chain-of-thought, few-shot examples, role assignment, JSON schema instructions, temperature and sampling controls, system prompt structure.

Unit of work: One message pair (system + user) or one turn in a chat.

Example — prompt-level fix

Before (vague):
Summarize this doc.

After (prompt-engineered):
You are a staff engineer writing release notes for developers.
Output: 3 bullets, each ≤25 words, past tense, no marketing language.
If the doc lacks version numbers, say "Version unclear" — do not invent one.

That improves a single call when the right document is already in context.

When prompt engineering is enough

• One-shot translation, classification, or formatting
• Early prototyping before you know the workflow shape
• Failures are clearly about misunderstood instructions, not missing files

When it is not enough

• The model "doesn't know" your codebase → context problem
• The task needs 40 tool calls → loop problem
• Tool calls hang or duplicate writes → harness problem

Deep dive: Context vs prompt engineering — precise distinction (two-layer guide; this post extends it to four).

Layer 2 — Context engineering (per call)

Definition: Designing the full package the model conditions on for each API call — not just message wording.

Karpathy's mid-2026 framing popularized the term: the hard part is not the clever user message; it is curating what fills the context window.

What lives in the context package

The four context levers

From explainx.ai's context engineering guide:

1. Content selection — does this token earn its place?
2. Structure and ordering — constraints first; docs before user message
3. Token budget — protect budget for variable content
4. Cache placement — stable prefix (system + tools) before cache breakpoint

Example — context-level fix (same user message)

[SYSTEM — always loaded]
Project: explainx.ai monorepo. Package manager: pnpm. Tests: pnpm test --filter web.
Never edit apps/mobile without explicit ask.

[RETRIEVED — grep hit, apps/web/lib/pathway-data.ts, lines 40-95]
{relevant_snippet_only}

[TOOLS — this task only]
Read, Edit, Bash(pnpm test:*)

[USER]
Fix the failing pathway progress test.

The user message is boring on purpose. Quality comes from what surrounds it.

Context engineering surfaces in Claude Code

Full stack breakdown: CLAUDE.md vs SKILL.md vs MCP.

When context engineering dominates

• RAG pipelines and codebase Q&A
• Sessions beyond ~10 turns (history pollution)
• Tool-selection errors (too many tools exposed)
• Cost/latency (200k context that should be 40k)

Learn the discipline: Context Engineering pathway.

Layer 3 — Loop engineering (workflow)

Definition: Designing the autonomous workflow that decides when to call the model, what goal must be satisfied, and how to know the run is done — without you typing each turn.

Addy Osmani popularized loop engineering in June 2026, building on Boris Cherny at Anthropic:

"I don't prompt Claude anymore. I have loops that are running."

That quote is about layer 3, not layer 1. The loop still contains prompts — something generates them each iteration. You stop being that something.

The five loop components

From What is loop engineering?:

Example — loop spec (not a prompt)

name: morning_p1_triage
trigger: cron "0 8 * * 1-5"
goal: zero open GitHub issues labeled P1 without assignee
actions: [github_mcp.list_issues, github_mcp.comment, github_mcp.assign]
verify: script checks assignee field on all P1 issues
memory: log file of triaged issue IDs this week
max_iterations: 20
human_gate: none  # read/write on issues only

No clever phrasing — workflow architecture.

Loop engineering vs prompt engineering

Implementation guides:

• Loop engineering with Claude Code
• AI agent loop architecture — triggers, retries, checkpoints
• /goal and long-running agents
• Goal mode complete guide
• Loop Engineering pathway

When loops fail (and it's not the prompt)

Human oversight: When to let the agent run vs gate it.

Layer 4 — Harness engineering (runtime)

Definition: Building or configuring the orchestration code that executes loops — parsing model output, calling tools safely, managing retries, assembling context each turn, and enforcing exit conditions.

Boris Cherny and Anthropic engineers use harness engineering for the systems that prompt Claude iteratively — observe, plan, act, reflect — over hours.

The agent harness is the concrete artifact:

Goal in → context assembly → model call → parse → execute tools
       → capture results → verify → loop or exit → result out

Harness components

Why harness beats model upgrades on benchmarks

LangChain's Deep Agents team reported gains on Terminal-Bench 2.0 from harness changes alone — same underlying model. The pattern generalizes:

Better harness on the same model > same harness on a better model — for many agentic tasks.

Reason: the model only sees what the harness assembles and only gets the retries the harness allows. See agent harness engineering on Terminal-Bench.

Products as harnesses

Minimal harness philosophy: Pi agent harness (Mario Zechner).

Self-improving harnesses: Self-harness agents (arxiv).

Deep read: Anthropic engineer on loops vs single prompts.

How the layers interact on one real task

Task: "Migrate our auth module to Clerk and make all tests pass."

Prompt layer (insufficient alone)

Migrate auth to Clerk. Make tests pass.

Works for a toy repo. Fails on a monorepo in one shot.

+ Context layer

• Load CLAUDE.md with package manager, test command, auth file map
• Retrieve only apps/web/lib/auth/* via grep — not whole repo
• Expose Edit + Bash(test) tools only

Each iteration of the agent sees a sane package.

+ Loop layer

trigger: developer runs /goal
goal: pnpm test --filter web exits 0 AND auth routes use Clerk SDK
verify: test command + grep for legacy auth imports
max_iterations: 50
memory: PROGRESS.md updated each checkpoint

Agent runs until verified — not until it says "done."

+ Harness layer

• Sandbox bash; block rm -rf
• Hooks run lint after every edit
• Checkpoint git stash every 10 turns
• Retry transient API failures
• Log token usage per step
• Human gate before editing production env files

Production shipping requires all four.

Diagnostic — which layer is broken?

Use this when an agent underperforms:

Fix bottom-up within a layer, outer layers first across layers: if verification never runs, no prompt edit helps.

The 2026 career map

Prompt engineering is table stakes — like knowing SQL if you build backends.

Context engineering is required for any agent that reads your data.

Loop engineering is required when you want autonomy measured in hours, not seconds.

Harness engineering is required when failure has a cost — money, data, reputation.

Practical learning path

1. Week 1 — Prompt + context basics
   System prompts guide → Context vs prompt → CLAUDE.md vs SKILL.md vs MCP

2. Week 2 — Loop design
   What is loop engineering? → Loop architecture → Claude Code loop guide

3. Week 3 — Harness hardening
   Agent harness guide → Hooks → Human-in-the-loop gates

4. Ongoing — Pathways
   Context Engineering pathway · Loop Engineering pathway · MCP pathway

Bottom line

Prompt, context, loop, and harness engineering are not four names for the same job. They are four layers of one stack:

• Prompt — message wording
• Context — per-call assembly
• Loop — autonomous workflow
• Harness — reliable execution

Karpathy named the context crisis. Cherny named the loop shift. Production teams name the harness when benchmarks move without new models.

When someone says "we need better prompts" on a long-running agent, ask: Which layer is actually failing? The answer determines whether you edit a paragraph, redesign retrieval, rewrite the goal spec, or fix retry logic.

Get the layer right — then optimize inward.

Related reading

• Ethan Mollick — Wharton Prompting Science: specs not tricks — July 2026 evidence that tricks fade; management stays
• Context vs prompt engineering (two-layer deep dive)
• Claude Code loops official guide (July 2026)
• What is loop engineering?
• What is an agent harness?
• Anthropic engineer: loops, not single prompts
• Destructive Command Guard: a runtime safety gate for agent shell commands
• AI agent loop architecture
• CLAUDE.md vs SKILL.md vs MCP
• Loop engineering mainstream skill
• Context Engineering pathway
• Loop Engineering pathway

Terminology and product features reflect the agent tooling landscape as of July 7, 2026.