Prompt, Context, Harness, Loop: The Four Layers of AI Agent Engineering

You rewrite the prompt for the fifth time. The agent still calls the wrong tool, forgets what it looked up two steps ago, or keeps retrying after it should have stopped. The fix usually isn’t in the prompt at all.

Four practices have shown up to describe where these problems actually live: prompt engineering, context engineering, harness engineering, and loop engineering. They read like competing trends, but they’re stacked layers of the same system, and mixing up harness engineering vs context engineering is one of the most common ways people misdiagnose a broken agent.

TL;DR: Prompt engineering shapes the wording of one request. Context engineering decides what fills the model’s context window. Harness engineering is the code that executes calls and tools around the model. Loop engineering decides when the model runs again and when it stops. Each layer wraps the one before it.

Prompt engineering: what you ask

Prompt engineering is the oldest of the four terms and the one most people already know. It means shaping the wording of a single request: the role you assign the model, the instructions you give it, the examples you show it, the format you ask for.

None of that requires an agent. Prompt engineering works the same whether you’re asking a chatbot a one-off question or writing the instruction block a tool-calling model reads on its first turn.

The practice still matters once an agent is running. Every call inside a longer system, first turn or fiftieth, is still a prompt someone wrote, and a badly worded one weakens every layer stacked on top of it.

Techniques like chain-of-thought instructions, few-shot examples, and a strict output format still do real work here. A model told to “think step by step before answering” behaves differently than one just asked for the answer, and that difference holds whether the call is standalone or the tenth turn of an agent loop.

What changes is the size of the job. A well-worded prompt is the whole task when you’re prompting directly. Inside an agent, it’s one input among several the model reads on every turn, which is where context engineering picks up. Future AGI’s guide to prompt engineering covers the technique on its own.

Context engineering: what the model sees

Context engineering names something bigger than wording: everything that fills the model’s context window on a given call, not just the request you typed. The term got its current shape from a widely shared 2025 exchange.

Shopify CEO Tobi Lütke wrote that he liked “context engineering” better than “prompt engineering” because it described the real skill. Developer Andrej Karpathy agreed about a week later, adding that context engineering is “the delicate art and science of filling the context window with just the right information for the next step.”

Anthropic’s own engineering team later defined it more formally: curating and maintaining the right set of tokens during inference, including everything that lands in the window besides the prompt itself, system instructions, memory, retrieved documents, tool definitions, and tool outputs.

The distinction from prompt engineering is what’s inside your control. A prompt is the part you write by hand. Context also includes what a retrieval step pulled in, what earlier turns left behind, and what a tool call returned, none of which you’re typing fresh each time.

In practice, context engineering is a curation problem more than a writing one. The window has a limit, so someone, or something, has to decide what stays in and what gets summarized, pushed to a file, or dropped once it stops earning its place.

Harness engineering: what executes

Harness engineering covers what happens after the model decides something, not what it’s told or shown. The framing is most often traced to a March 2026 LangChain post by Vivek Trivedy, though the origin is contested. It is built around one formula: agent equals model plus harness.

His definition: a harness is “every piece of code, configuration, and execution logic that isn’t the model itself.” That includes executing tool calls, parsing what comes back, retrying on failure, routing work to sub-agents, and enforcing limits on what the agent is allowed to do.

Trivedy’s framing is blunt about the split: “The model contains the intelligence and the harness is the system that makes that intelligence useful.” A brilliant model wired to a sloppy harness still produces unreliable runs, since nothing checks whether a tool call actually worked before moving on.

Harness engineering vs context engineering

These two get confused because both sit close to the model, but they answer different questions. Context engineering decides what the model sees before it responds. Harness engineering decides what happens to what it says afterward.

Harness engineering is what decides whether a tool call runs safely, whether a bad result gets caught, and whether a limit gets enforced. Perfect context handed to a broken harness still fails.

Future AGI’s look at bloated coding-agent harnesses covers what a harness costs when it carries more than it needs to.

Loop engineering: what controls iteration

Loop engineering is the outermost layer. It decides when the model gets called again, what counts as the goal being met, and when the whole run should stop.

Developer Addy Osmani named the practice in a June 2026 essay: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.” Instead of typing the next instruction by hand, you design the rule that decides what happens next.

Boris Cherny, who created Claude Code at Anthropic, described the same shift in remarks widely quoted afterward, where the wording varies across reproductions: “I don’t prompt Claude anymore. I have loops running. They’re the ones prompting Claude and figuring out what to do.”

A loop with no stop condition isn’t really a loop, it’s a program that keeps going regardless of whether it’s right. This layer is a deep practice on its own, with its own components and failure modes worth a dedicated look.

The agent loop glossary entry is a good place to start. A closer look at the core components underneath any agent covers the model, memory, and controller pieces a loop actually runs on.

Where each term actually came from

These four terms were not coined together, and treating them as one official taxonomy overstates what happened. Three of the four were named by different people writing independently over roughly a year, each naming the layer they were staring at. Prompt engineering has no single coiner.

The table happens to read chronologically. The order of the names follows the order of the layers: wording first, then what filled the window, then what executed around the model, then what decided when to stop calling it at all.

None of the four authors were building a shared framework together. They were each naming the specific gap they kept running into, and the stack only looks designed in hindsight because the gaps happened to sit on top of each other.

Watching one request move through all four layers

Take a support agent handling “where is my order.” The request enters, and all four layers touch it before a customer sees a reply.

The prompt is the system instruction plus that one line: find the order, check its status, answer clearly. The context is everything else in the window on that call: the order lookup tool’s schema, the last two turns of the conversation, and whatever the retrieval step pulled about this customer’s account.

The harness is what runs next: it executes the order-lookup tool call, parses the returned status and delivery date, and decides what to do if that call fails, retry it, try a fallback, or flag it for a person instead of guessing.

The loop makes the final call: is the goal met? If the status came back clean, the run ends with a reply. If the lookup failed twice, the loop’s stop condition should end the run and hand it to a person rather than looping forever.

What each layer controls, and what breaks when it’s weak

Each layer fails in its own recognizable way, which makes the four-layer split useful for more than definitions. It’s a diagnostic.

Read the table against a real symptom. An agent that answers confidently with the wrong order number usually has a context problem, not a prompt problem. An agent that runs up a huge bill overnight usually has a loop problem: nothing told it when to stop.

The check that cuts across all four layers

Whichever layer is weak, you still need a way to see what actually happened and score it. That job doesn’t belong to any one of the four; it cuts across all of them.

Future AGI’s platform reflects that split directly: Evals score the output, Observe shows the trace of what the harness and loop actually did, and Workbench is where prompt choices get tested before they ship. They’re separate views over the same runs, not a fifth layer that replaces prompt, context, harness, or loop work.

That’s the honest scope of the tie: Future AGI’s evaluation tools help you check what each layer produced. They don’t write your prompts, assemble your context, run your tools, or decide when your loop stops.

That’s a deliberate boundary, not a gap. Checking a system and running it are different jobs, and conflating them is how teams end up trusting a loop just because nothing has visibly broken yet.

Which layer actually needs your attention

Most agent problems get blamed on the model or the prompt by default, since those are the parts people see first. The layer split gives you a faster way to place the blame correctly.

If the model misunderstands a single, well-formed request, that’s a prompt problem. If it has the right facts somewhere in the system but doesn’t use them, that’s context. If tool calls run but failures go unnoticed, that’s harness.

If the agent doesn’t know when to try again or when to quit, that’s loop.

Fixing the wrong layer is why some agent bugs never seem to go away no matter how many times the prompt gets rewritten. Find the layer that’s actually weak first, then fix that one.