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

Context engineering, Loop engineering, Harness engineering = 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

This guide maps the full stack - with diagrams, diagnostics, and detailed visuals

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

┌─────────────────────────────────────────────────────────────┐
│  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)

Boris Cherny about self-verification loops:

Boris Cherny: "Two of the most powerful features in Claude Code: /loop and /schedule":

Andrej Karpathy about "context engineering":

Think of it like web development:

Boris Cherny: "I am surprised that people are surprised this is how I prompt Claude."

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

Context vs prompt engineering:

Definition: Designing the full package the model conditions on for each API call

In mid-2026, Karpathy popularized the idea that the real challenge lies in curating the context window:

What lives in the context package

The four context levers

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: [........]. 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:

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)

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. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops"

Addy Osmani's guide:

The loop still contains prompts = something generates them each iteration. You stop being that something

The five loop components

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:

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

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

Addy Osmani's guide:

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

Products as harnesses

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

Prompt layer:

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

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

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

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

Save this so you don't lose it

Follow @beamnxw for more alpha

=> my substack

=> my telegram channel

=> my youtube

=> my github

=> my github works