# Prompt, Context, Harness, Loop: The Four Layers of Engineering Reliable AI Agents

Two years ago, the advice was simple: *"Just write a better prompt."* Whole job titles appeared overnight. Prompt libraries were traded like baseball cards. And for a while, it worked — because we were mostly asking a model to produce a single chunk of text in a single shot.

That era is over.

The moment you ask a model to *do things* — call tools, read files, browse, run code, remember, retry, and keep going for hundreds of steps — the prompt becomes the smallest part of the problem. As Andrej Karpathy put it, the LLM is a new kind of CPU and its context window is the RAM. The prompt is just one instruction. What actually determines success is the entire operating system you build **around** the model.

I've spent the last two years helping enterprise teams move from clever prompts to production agents. The pattern is always the same: teams that treat this as *four distinct engineering disciplines* ship reliable agents. Teams that keep tweaking prompts stay stuck in demo purgatory.

Those four disciplines are **prompt engineering**, **context engineering**, **harness engineering**, and **loop engineering** — four concentric rings, each wrapping the one inside it.

> **Building or scaling agentic AI in your org?** I run hands-on enablement workshops covering exactly this stack — from context design to production harnesses. [Book a discovery call →](https://topmate.io/siddheshp)

* * *

## The Big Picture: Four Concentric Rings

Each layer wraps a wider concern. The prompt is the innermost instruction. Context is everything the model sees before it responds. The harness is the software scaffolding that lets the model act. The loop is the control flow that decides when to keep going and when to stop.

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/a40744c8-4c8b-4522-af1e-c69f9b558707.png align="center")

Here's the one-line definition of each, and who owns it:

| Layer | Question it answers | Failure if you skip it |
| --- | --- | --- |
| **Prompt** | *What am I asking the model to do, right now?* | Vague, inconsistent, unsteerable output |
| **Context** | *What does the model need to see to plausibly succeed?* | Hallucination, "it forgot", garbage-in-garbage-out |
| **Harness** | *What can the model actually do, and how safely?* | Model can reason but can't act; unsafe actions |
| **Loop** | *When does it act, retry, escalate, or stop?* | Infinite loops, runaway cost, compounding errors |

Let's walk each ring from the inside out.

* * *

## Layer 1: Prompt Engineering — The Instruction

Prompt engineering is the craft of writing the instruction the model executes: the task description, the role, the constraints, the examples, and the output format.

It is **necessary but no longer sufficient**. It still matters enormously — a badly worded system prompt will sink even a perfect harness — but it is now one input among many.

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/1f3b73f9-0029-4ef3-8166-fd8b01d3b9ef.png align="center")

### What still earns its keep

*   **Explicit role and objective.** "You are a refund-processing agent. Your goal is to resolve the ticket or escalate — never to chit-chat."
    
*   **Constraints as guardrails.** State what *not* to do as clearly as what to do.
    
*   **Few-shot examples** for format and tone — one good example beats a paragraph of description.
    
*   **Structured output contracts** (JSON schema, XML tags) so downstream code can parse reliably.
    

### Where it hits a wall

The prompt is *static*. It can't know today's inventory, this user's history, or the result of the last tool call. The second your task depends on live, changing information, no amount of prompt polishing helps. That's the handoff to context engineering.

> **Rule of thumb:** If you're on your 15th prompt revision and the agent still "forgets" or "makes things up," you don't have a prompt problem. You have a context problem.

* * *

## Layer 2: Context Engineering — What the Model Sees

Shopify's Tobi Lütke defined it best: context engineering is *"the art of providing all the context for the task to be plausibly solvable by the LLM."* Karpathy amplified it. The field agreed almost overnight, because it named the thing that actually breaks agents.

**Most agent failures are not model failures anymore. They are context failures.**

Context is *everything* the model sees before it generates a token — not just your prompt:

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/4d2648b1-5a16-4c9c-a674-c518c30c5ec0.png align="center")

The context window is finite RAM. The discipline is deciding *what earns a place in it at each step*. The LangChain team crystallised four strategies — a vocabulary worth memorising:

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/4c749b7a-0543-47cb-9be0-0a6aefbcdb98.png align="center")

| Strategy | What it does | Real-world example |
| --- | --- | --- |
| **Write** | Persist info *outside* the window so it survives truncation | Anthropic's researcher saves its plan to memory before the window fills; `CLAUDE.md` files |
| **Select** | Retrieve only the relevant facts, tools, or memories | RAG over docs; semantic search over a large tool catalogue |
| **Compress** | Summarise or trim to retain only necessary tokens | Claude Code's "auto-compact" at 95% window usage |
| **Isolate** | Partition context so pieces don't pollute each other | Sub-agents with separate windows; code sandboxes holding heavy objects |

### The failure modes you're preventing

Drew Breunig catalogued how long contexts rot, and the names are worth knowing because you *will* see all four:

*   **Context Poisoning** — a hallucination gets written into context and is then treated as fact.
    
*   **Context Distraction** — so much context that it drowns out the model's own training.
    
*   **Context Confusion** — irrelevant content bleeds into and warps the answer.
    
*   **Context Clash** — two parts of the context contradict each other.
    

Context engineering is where most of the real work lives today. But even a perfectly-packed context window is inert if the model can't *do* anything with it. That's the harness.

* * *

## Layer 3: Harness Engineering — What the Model Can Do

Here's the term teams most often miss. The **harness** is the software scaffolding that turns a passive text predictor into an agent that acts on the world. Claude Code, Cursor, and Copilot are, at their core, harnesses. The model is the engine; the harness is the entire car around it.

A harness owns: the **tools** and their schemas, the **agent-computer interface (ACI)**, the **execution sandbox**, the **guardrails**, the **observability**, and the plumbing that feeds results back into context.

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/72d57504-9788-42ad-bcdb-38783146b17e.png align="center")

### The agent-computer interface is where agents live or die

Anthropic's team reported that while building their SWE-bench agent, they spent **more time optimising tools than the overall prompt.** That single sentence should reframe how you budget your effort. Their guidance for a good ACI:

*   **Treat tool definitions like docstrings for a junior engineer.** Include example usage, edge cases, and clear boundaries between similar tools.
    
*   **Poka-yoke your tools** — design arguments so mistakes are hard to make. (They switched to *absolute* file paths after the model kept tripping on relative ones once it changed directories.)
    
*   **Keep formats close to what the model has seen in training.** Writing code inside JSON forces awkward escaping; markdown is friendlier.
    
*   **Give the model room to think** before it must commit to a tool call.
    

### The harness also enforces safety

This is the layer where you decide what the agent is *allowed* to do: which tools require human approval, what the sandbox can touch, what gets logged. Autonomy without a harness that enforces boundaries is how you get an agent that `rm -rf`s a production directory because it "seemed like the next step."

> **Rule of thumb:** If your agent can reason brilliantly but keeps failing on execution — malformed tool calls, wrong paths, unsafe actions — invest in the harness, not the prompt.

A great harness with a naive control flow still misbehaves: it loops forever, gives up too early, or repeats the same failing action. That's the outermost ring — the loop.

* * *

## Layer 4: Loop Engineering — When to Act, Retry, and Stop

An agent is, at its heart, *an LLM using tools in a loop.* Loop engineering is the design of that control flow: the iteration cycle, the stopping conditions, error recovery, reflection, and — when needed — delegation to sub-agents.

The base loop is the classic sense-plan-act-reflect cycle:

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/6ef6705b-fd6c-4d42-8f74-1eab7c2b9082.png align="center")

### The decisions that make or break a loop

*   **Stopping conditions.** Task complete? Max iterations hit? Budget exhausted? Confidence too low? Without hard stops, you get infinite loops and runaway bills.
    
*   **Error recovery.** When a tool fails, does the agent retry, try a different approach, or escalate to a human? Blind retries of the same failing action are a top production pathology.
    
*   **Human-in-the-loop checkpoints.** Pause for approval before irreversible actions (payments, deletes, sends).
    
*   **Reflection.** Let the agent critique its own output before continuing — the *evaluator-optimizer* pattern, where one call generates and another critiques in a loop.
    

### Loop topologies scale up

For hard problems, a single loop becomes a *system* of loops. Anthropic's building blocks map cleanly onto loop-engineering choices:

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/9d83cc1b-f134-45fe-bdce-f87cc69cdca5.png align="center")

| Loop pattern | When to use it |
| --- | --- |
| **Single loop** | Bounded tasks with clear completion (fix a bug, extract fields) |
| **Evaluator-optimizer** | Clear quality criteria + iterative refinement pays off (translation, drafting) |
| **Orchestrator-workers** | Subtasks can't be predicted up front (multi-file code changes, research) |
| **Parallel / voting** | Speed via independent subtasks, or confidence via multiple attempts |

Note the deep connection back to Layer 2: isolating context across sub-agents is *both* a context strategy and a loop topology. The rings are concentric, not independent — decisions ripple across them.

> **The cost warning nobody mentions early enough:** multi-agent loops can burn **15× more tokens** than a single chat turn (Anthropic's own figure). Loop engineering is as much about economics as correctness.

* * *

## Putting It Together: How the Four Layers Interact

The layers aren't a checklist you complete once — they're a system that runs on *every step* of an agent's trajectory. One full turn looks like this:

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/7620b44e-5962-4b2b-b1b0-df9f5779d58f.png align="center")

Read it top to bottom and the division of labour is obvious:

*   **Loop** decides *whether* to run another step.
    
*   **Context** decides *what the model sees* this step.
    
*   **Prompt** decides *what we're asking* this step.
    
*   **Harness** decides *what the model can do* and *how safely*.
    

Break any one ring and the whole agent degrades — usually in a way that *looks* like a model problem but isn't.

* * *

## A Maturity Model: Where Is Your Team?

Use this to locate yourself honestly. Most enterprise teams I meet are at Level 1 or 2 and think their problem is "we need a better model."

| Level | Name | What it looks like | Ceiling |
| --- | --- | --- | --- |
| **0** | Prompt tinkering | Copy-pasting prompts into a chat UI | No automation, no reliability |
| **1** | Prompt + RAG | Templated prompts, static retrieval | "It forgets", brittle to edge cases |
| **2** | Context-aware | Dynamic context assembly, memory, compression | Can't take actions safely |
| **3** | Harnessed | Real tools, sandbox, guardrails, tracing | Loops misbehave; cost surprises |
| **4** | Loop-engineered | Stop conditions, recovery, HITL, sub-agents | Production-grade, observable, economical |

The jump from Level 1 to Level 4 is not "a smarter model." It's four engineering disciplines applied deliberately.

* * *

## Practical Takeaways

1.  **Diagnose the right layer.** "Forgot / hallucinated" → context. "Reasoned well, executed badly" → harness. "Won't stop / loops / too expensive" → loop. "Inconsistent tone or format" → prompt. Fixing the wrong layer is why teams spin.
    
2.  **Budget effort like the pros do.** Anthropic spent more time on tools than prompts. Your instinct to keep polishing the prompt is almost always misallocated effort past a certain point.
    
3.  **Instrument before you optimise.** You cannot context- or loop-engineer what you can't see. Tracing and token accounting come *first*.
    
4.  **Add complexity only when it earns its place.** Start with the simplest thing — a single well-scoped LLM call — and climb the rings only when the task demonstrably needs it. Multi-agent is powerful and expensive; reach for it last.
    
5.  **Treat context as a system, not a string.** It's dynamic output assembled per step — the right information and tools, in the right format, at the right time.
    

* * *

## Closing Thought

"Prompt engineering" was never wrong — it was just too small a word for the job. Building a reliable agent is an exercise in building a small operating system around a model: an instruction (**prompt**), working memory (**context**), a body that can act (**harness**), and a nervous system that decides when to keep going (**loop**).

Master all four, in order, and you stop shipping demos and start shipping agents.

* * *

*Found this useful? I write regularly on enterprise agentic AI, cloud architecture, and the engineering behind production LLM systems. Follow along, and if you're building this in-house,* [*let's talk →*](https://topmate.io/siddheshp)