Prompt vs Context vs Harness vs Loop Engineering: The 2026 Stack Explained

Quick answer: Prompt, context, loop and harness engineering are four layers of one AI agent stack. Prompt engineering words one instruction, context engineering controls what the model sees, loop engineering controls how work repeats and when it stops, and harness engineering designs the whole environment around the agent. They nest rather than compete.

In the space of three years, the discipline of getting useful work out of AI models has been renamed three times, and each renaming marked a real shift rather than a rebrand. Prompt engineering gave way to context engineering, which is now being subsumed into harness engineering, with loop engineering describing the control layer inside it. If you have felt that the ground keeps moving under the terminology, you are right, and the movement reflects a genuine evolution in how serious AI systems are built. This piece lays out the whole stack clearly, so you can see how the four disciplines relate rather than treating them as competing buzzwords.

Understanding this stack is not academic. It is the difference between building AI systems that impress in a demo and building ones that work reliably in production, which is exactly the gap the forward deployed engineer exists to close. Each layer is covered in depth in its own guide, and the practical craft of all four is what the Forward Deployed Engineering Program teaches, because production AI depends on the whole stack rather than any single layer.

Key Highlights

• The four disciplines are not competitors, they are layers of a single stack that evolved as AI systems grew from single prompts into autonomous agents.
• Prompt engineering asks how to word the instruction, context engineering asks what the model sees on each call, loop engineering asks how the agent repeats until done, and harness engineering asks what whole environment surrounds the agent.
• The evolution from prompts to harnesses tracks the shift from one-shot model calls to agents that work continuously and reliably at production scale.
• Prompt engineering is not dead, it moved, becoming the foundational layer inside the newer disciplines rather than being replaced by them.
• Whoever understands the full stack, rather than one fashionable layer, is the person who can actually ship reliable AI, which is the forward deployed engineer's core value.

Why the terminology keeps changing

The renaming is not marketing churn, it reflects a real change in what building with AI actually involves. In the early days, you interacted with a model through a single prompt, so the skill was writing that prompt well, and prompt engineering was the whole game. As systems grew more sophisticated, the model needed more than a well-worded instruction, it needed the right information assembled around that instruction, and context engineering named that broader skill. As systems became autonomous agents that act repeatedly and unattended, they needed a whole environment of constraints and feedback around them, and harness engineering named that.

So the sequence of terms tracks the sequence of what we ask AI systems to do. Each new discipline did not replace the previous one, it wrapped around it, adding a layer that the growing complexity of the systems demanded. Prompt engineering is still there, inside context engineering, which is inside the harness. The reason the terminology feels unstable is that the field genuinely moved three times in three years, each move adding a layer as AI systems evolved from answering a single question to autonomously completing complex work. Seeing the terms as a stack that grew, rather than a series of fads that replaced each other, is the key to making sense of all of it.

Prompt engineering: how do I word this

What is prompt engineering?

Prompt engineering is the craft of wording a single instruction so a model produces the output you want. It covers clear instructions, worked examples, structured output formats and careful framing. It operates at the level of one message, and it remains the innermost layer of the stack rather than a discipline that has been replaced.

Read why prompt engineering is not dead

The foundational layer is prompt engineering, and it answers the narrowest and most immediate question: how do I word this instruction so the model does what I want? It is the craft of composing the actual text sent to the model, choosing the phrasing, structure, examples, and framing that produce good output for a single interaction.

Prompt engineering emerged first because it was the first thing anyone needed. When your entire interaction with a model was a prompt and a response, the prompt was everything, and small changes in wording produced large changes in quality. The discipline developed real techniques: clear instructions, worked examples, structured formats, and careful framing. What made it feel fragile was that it operated at the level of individual messages, so a change in the model or the task could break a carefully tuned prompt. This fragility is part of why the field moved beyond treating the prompt as the whole solution, but prompt engineering did not disappear. It became the innermost layer, the craft of the individual instruction, still essential but no longer sufficient. Anyone who declares prompt engineering dead has mistaken a layer being wrapped for a layer being removed.

Context engineering: what does the model see

What is context engineering?

Context engineering is the practice of deciding what the model sees on each call: instructions, retrieved documents, memory, tool results and conversation history. Anthropic describes it as curating the best set of information during inference. It operates at the level of the whole context window, and prompt engineering sits inside it.

Read the full guide to context engineering

The next layer out is context engineering, which answers a broader question: what information does the model actually see when it runs? A prompt is only part of what reaches the model. Around it sits everything else in the context window: retrieved documents, memory of past interactions, tool definitions, system instructions, and data pulled from other sources. Context engineering is the discipline of curating all of that.

Anthropic has described context engineering as the set of strategies for curating and maintaining the optimal set of information during model inference, including everything that lands in the context beyond the prompt itself. The term settled around mid-2025, gaining rapid adoption after prominent figures in the field endorsed it, and it has been taken up by major AI companies and frameworks. The shift from prompt to context engineering reflects a real realisation: for complex tasks, what determines the quality of the output is less the exact wording of the instruction and more whether the model has the right information in front of it. Getting the right documents, the right memory, and the right tools into the context, without polluting it with irrelevant material that confuses the model, is a distinct and harder skill than wording a single prompt. The dedicated guide to context engineering covers how it works in practice.

Loop engineering: how does the agent repeat until done

What is loop engineering?

Loop engineering is the design of how an agent repeats work until it is done: what triggers each cycle, how results are checked, and when the loop stops. Good loops have explicit termination conditions such as success, a maximum number of iterations, a spending budget or detected lack of progress.

Read the full guide to loop engineering

As AI systems became agents that take actions rather than just answering questions, a new layer appeared: the loop. An agent does not run once, it runs repeatedly, observing the result of each action, reasoning about it, and deciding the next move, continuing until it reaches its goal or hits a stopping condition. Loop engineering is the discipline of designing these cycles so the agent reliably works toward the goal rather than spinning uselessly or stopping too soon.

The core of loop engineering is control flow and, above all, termination. An agentic loop repeats a cycle of acting, receiving feedback from the environment, and using that feedback to choose the next action. The critical design question is when the loop should stop: on success, on reaching a maximum number of iterations, on exhausting a budget, or on detecting that it is making no progress. Get the termination wrong and the agent either runs forever, burning time and money, or stops arbitrarily before finishing. Loop engineering is the least discussed of the four disciplines and one of the most consequential, because the difference between an agent that reliably completes work and one that loops uselessly or quits early lives entirely in the design of the loop. The dedicated guide to loop engineeringgoes into how these cycles are actually built.

Harness engineering: what whole environment surrounds the agent

What is harness engineering?

Harness engineering is the design of everything around the model in an agent: the repository structure, tools, constraints, documentation, verification checks and feedback that shape and limit what the agent does. Its core idea is that when an agent makes a mistake, you change the system so the mistake becomes harder to repeat.

Read the full guide to harness engineering

The outermost layer, and the newest, is harness engineering, which answers the broadest question: what is the entire environment around the agent that lets it work reliably? A capable agent still needs scaffolding to be productive: the tools it can call, the constraints that keep it on track, the feedback loops that catch its mistakes, the project structure and instructions that shape its behaviour, everything that surrounds the model but is not the model.

OpenAI described harness engineering as building the full environment of scaffolding, constraints, and feedback loops around an agent such as its Codex system, and the term gained currency in early 2026. The harness includes the repository structure, the continuous integration configuration, the formatting and linting rules, the package managers and frameworks, the project instructions, and the external tool integrations. It represents a shift in what the engineer does: away from writing code directly and toward designing the environment, specifying intent clearly, and building the feedback loops that let agents build and maintain software autonomously. OpenAI reported that an internal team using only its Codex agents built production software over roughly five months, merging around fifteen hundred pull requests and generating on the order of a million lines of code, moving far faster than manual development would have allowed. That result was a demonstration of harness engineering: the humans built the harness, and the agents did the coding. The dedicated guide to harness engineering explores the discipline in full.

LangChain reported raising its coding agent from 52.8% to 66.5% on Terminal Bench 2.0, moving from the top 30 to the top 5, by changing only the harness.

How the four layers fit together

The clearest way to hold the whole stack in mind is to see each discipline as answering a progressively broader question about the same system.

Read from top to bottom, the scope widens at each step, from a single message to the entire environment, and each layer contains the ones above it. A harness contains loops, loops assemble context on each iteration, and context includes prompts. This is why they are a stack rather than rivals. An engineer working on a serious AI system is operating at all four levels at once, wording the instructions, curating the context, designing the loops, and building the harness, even if they do not always name each layer separately.

Where Writers Disagree About the Layers

Writers do not yet agree on how the four layers nest. Some treat harness engineering as the outermost layer and place context engineering inside it. Others describe loop engineering as the outermost layer because it decides when the whole run repeats or stops, and others present the four as a timeline in which each new term arrived when the last one stopped being enough. This article treats harness engineering as the whole environment and loop engineering as the control layer inside it, because that matches how most production agents are built. The practical point does not depend on the diagram: each layer answers a different question and fails in a different way.

What Breaks When Each Layer Is Weak, and How to Diagnose It

How to tell which layer needs attention

Start from the symptom, not the layer. If a single response is badly worded, work on the prompt. If the model lacks a fact it should have, work on context. If the agent takes a wrong action or cannot recover from an error, work on the harness. If the agent never finishes or stops too soon, work on the loop. Fixing an outer layer cannot compensate for a missing fact, and polishing the prompt cannot compensate for a loop with no stop condition.

One Request Through All Four Layers

Consider an expense approval agent asked to approve a travel claim.

• Prompt: the instruction tells the agent to check the claim against policy and return a decision and a reason in a fixed format.
• Context: the agent receives the relevant policy section, the employee's role and the receipts, not the whole company handbook.
• Harness: the agent can look up receipts but cannot approve above a set limit; a check confirms the output format, and a malformed response triggers a retry.
• Loop: if a receipt is missing, the agent asks for it and tries again. The loop stops on success, after three attempts or when the budget is spent, and then escalates to a person.

Remove any one layer and the failure is different: a weak prompt gives a badly formatted answer, weak context gives a wrong decision, a weak harness lets the agent approve something it should not, and a weak loop leaves the claim stuck.

Who Popularized Each Term

Why each renaming marked a real advance

It is worth pausing on why the field bothered to name each new layer, because the naming was not vanity, it tracked genuine progress in what AI systems could do. Each time the terminology shifted, it was because the previous frame had stopped being adequate to the systems people were building, and a new frame was needed to think clearly about the new complexity. Names matter here because they focus attention: once the field had a word for context engineering, practitioners started thinking systematically about context in a way they had not when it was an unnamed part of prompting.

This is how engineering disciplines mature. A concern that was once handled implicitly, or lumped in with something else, gets named when it becomes important enough to deserve dedicated attention, and the naming accelerates progress on it. Prompt engineering got named when getting output from models became a distinct skill. Context engineering got named when what the model sees became the dominant concern. Harness engineering got named when the environment around autonomous agents became the thing that determined reliability. Each name marked the moment a layer became important enough to study in its own right. Seeing the sequence this way, as a maturing field naming its layers as they became critical, dispels the impression that the terminology is just fashion. It is the vocabulary of a discipline growing more sophisticated, and understanding the vocabulary is part of understanding the sophistication. This maturation is exactly why building reliable agentic AInow requires thinking at all four levels rather than just one.

Where the stack is still heading

The stack is not finished, and it helps to hold it as a living structure rather than a fixed one, because more layers may yet appear as AI systems take on more. The pattern so far is that each new layer emerged when systems grew autonomous or complex enough to make a new concern dominant. There is no reason to think that process has stopped. As agents work together in larger systems, as they operate over longer horizons, and as they take on more consequential work, new concerns will likely become dominant enough to deserve their own names and disciplines.

You can already see hints of where the next layers might form: the coordination of multiple agents working together, the long-term memory and learning of agents that persist over time, the governance and safety of agents acting with real autonomy. Whether these become named disciplines in the way prompt, context, loop, and harness engineering did remains to be seen, but the direction is clear enough that an engineer building for the future should expect the stack to keep growing outward. This is why the goal is not to memorise four terms but to understand the underlying logic, that each layer manages a level of complexity the layer inside it cannot, so that when new layers appear you can place them. Understanding the stack as a growing structure rather than a fixed list is what keeps you oriented as the field continues to move, and it is part of the forward-looking capability that hands-on agentic AI engineering is meant to build.

Why the forward-deployed engineer needs the whole stack

This stack is not an abstract taxonomy, it is the working knowledge behind reliable production AI, which is exactly what the forward deployed engineer is paid to deliver. The reason so many enterprise AI projects stall in the gap between a demo and production is, in large part, that the demo used a good prompt and the production system needed the whole stack. A single clever prompt produces an impressive demonstration. A reliable system that runs on real data, takes real actions, and recovers from real failures needs curated context, well-designed loops, and a solid harness around it.

This is why understanding the full stack, rather than fixating on one fashionable layer, is the forward deployed engineer's core technical value. The engineer who only knows prompt engineering can build a demo. The engineer who understands the whole stack can build something that survives contact with an enterprise. Since forward deployed work is precisely about crossing the divide between demo and production, mastery of all four disciplines is not optional, it is the job. Building that mastery through the Forward Deployed Engineering Program, or by grounding yourself in agentic AI foundations and hands-on engineering with Claude, is how you become the person who can actually ship reliable AI rather than just demonstrate it.

You can also build the foundations through the Prompt Engineering Course and the Agentic Software Development Engineer Program.

The bottom line

The 2026 AI engineering stack has four layers that evolved as systems grew from single prompts into autonomous agents. Prompt engineering asks how to word the instruction, context engineering asks what the model sees on each call, loop engineering asks how the agent repeats until the job is done, and harness engineering asks what whole environment surrounds the agent so it works reliably. They are not competing disciplines but nested layers of a single stack, each wrapping the ones inside it, which is why the terminology kept changing as the field advanced rather than because any layer was truly replaced.

Prompt engineering did not die, it became the foundational layer inside the newer disciplines. The engineer who understands the entire stack, rather than one fashionable slice of it, is the one who can build AI that survives the journey from demo to production, which is the forward deployed engineer's defining value. Each layer has its own guide in this cluster, and building command of all four through the Forward Deployed Engineering Program is what turns an understanding of the stack into the ability to ship reliable systems on it.

Sources and Further Reading

• Anthropic engineering essay on context engineering for agents
• OpenAI write-up on building software with Codex agents (February 2026)
• LangChain post on improving Deep Agents with harness engineering, and its Terminal Bench 2.0 result
• Addy Osmani essay on loop engineering (June 2026)
• Posts by Tobi Lütke and Andrej Karpathy on context engineering (2025)
• Mitchell Hashimoto's early 2026 writing on harness engineering