Five terms are floating around the AI engineering world right now, and people use them almost interchangeably. They're not interchangeable. They're layers of the same stack — and confusing them is why so many agent projects fail in ways their builders can't diagnose.
Here's how I think about them after building with these systems for a while: prompt engineering is what you say, context engineering is what the model sees, agentic engineering is what the model can do, loop engineering is how the model gets better, and harness engineering is everything around it that makes it shippable. Message, input, action, iteration, infrastructure. Miss any one of the five and the system doesn't work; misattribute a failure to the wrong layer and you'll "fix" it forever without fixing it.
Layer 1: Prompt engineering — what you say
The original discipline, and the one everything else grew out of. Prompt engineering operates at the level of a single message: instructions, personas, output formats, few-shot examples, the phrasing of the request itself. In 2022–2023 it was treated as the skill of the AI era — people collected "ultimate prompt" threads like spellbooks, and for single-turn tasks, the skill genuinely mattered. A well-specified instruction with three good examples beats a vague one-liner; that was never false.
What changed isn't that prompting stopped working. It's that the unit of work outgrew it. As soon as agents started running multi-turn sessions with tools and state, the interesting problems moved elsewhere — to what fills the window across a whole run, to how the system iterates, to the infrastructure around it. Prompt engineering didn't die; it was reclassified: a contained, necessary discipline inside every larger system. Every context window still contains instructions. Every agent still needs a well-written system prompt. The spellbook just turned out to be chapter one.
My opinion: the "prompt engineering is dead" takes are as wrong as the "prompt engineering is everything" takes were. Both mistake a layer for the whole stack. Here's the honest assessment — prompting is the highest-leverage skill exactly where the interaction is thinnest (a single question to a chat interface) and the lowest-leverage exactly where the system is thickest (a 50-turn agent run with tools). Most working engineers live somewhere in the middle, which is why you still need it: a bad system prompt will poison even a well-architected harness. The foundation didn't crumble; the building just got taller.
Layer 2: Context engineering — what the model sees
The term went mainstream in June 2025, when Shopify CEO Tobi Lütke posted that he preferred "context engineering" over "prompt engineering" — "the art of providing all the context for the task to be plausibly solvable by the LLM" — and Andrej Karpathy amplified it with the sharper definition: "context engineering is the delicate art and science of filling the context window with just the right information for the next step." Karpathy's companion analogy: the LLM is the CPU, and the context window is the RAM — the model's working memory.
Prompt engineering was about phrasing a single message. Context engineering is systems architecture: deciding what enters the window, in what order, at what granularity, and at what point in a task's lifecycle. The inventory is bigger than most people realize — system instructions, few-shot examples, retrieved documents, tool definitions, conversation history, task state, memory. And the discipline includes what to exclude: too much irrelevant context doesn't just cost money, it degrades performance.
This isn't folk wisdom. Anthropic's research on multi-agent tasks found that token usage — the information load on each call — explains roughly 80% of performance variance across runs. Not model choice. Not prompting style. The context.
My opinion: most agent failures are context failures wearing a model costume. When an agent goes off the rails at turn 15, the instinct is to blame the model ("it's not smart enough") or the prompt ("I need better instructions"). In my experience it's usually the context: stale state accumulating, retrieved junk crowding out the actual task, tool definitions so bloated the model can't find the right one. The fix is architectural, not rhetorical. Prompt engineering was the single-turn version of this discipline; context engineering is the production version.
Layer 3: Agentic engineering — what the model can do
If context engineering is the input layer, agentic engineering is the system layer: giving the model the ability to act — tools, permissions, autonomy — and designing the whole thing to a professional standard.
The primitives are well established now. Function calling (OpenAI shipped it in June 2023) lets the model emit structured calls instead of prose; the host application executes them for real. Anthropic's Model Context Protocol standardized how tools get defined and served. These are the load-bearing mechanisms underneath every agent.
But "agentic" has a second, more important meaning, and it's Karpathy's: the distinction between vibe coding and agentic engineering. Vibe coding raises the floor — anyone can build software by describing it. Agentic engineering raises the ceiling — it's about preserving the quality bar of professional software while going much faster. "You're still responsible for your software just as before, but can you go faster?" The gap between mediocre and excellent users of these tools is widening, and the difference is engineering discipline, not prompting talent.
Karpathy's other essential contribution here is the autonomy slider: practical systems sit somewhere between fully manual and fully autonomous, and placing each task on that slider is a design decision, not a default. Cursor and Perplexity are canonical partial-autonomy products — the model acts, but inside interfaces built for verification and human control.
My opinion, stated as someone who's run production systems for 19 years: agency without verification is a liability, not a feature. Most "agents" I've seen demoed are impressive precisely because they skip the boring parts — idempotency, permissions scoping, rollback, audit trails, rate limits. The unsexy scaffolding is the actual engineering. An agent that can call your production API but can't tell you what it did, undo it, or prove it was authorized isn't a product; it's an incident waiting for a timestamp. The autonomy slider isn't philosophical — it's the difference between a demo and something you'd let near customer data.
Layer 4: Loop engineering — how the model gets better
A newer term, and the one that crystallized for me most recently. In June 2026, Boris Cherny — the creator of Claude Code at Anthropic — said it plainly: "I don't prompt Claude anymore. I have loops that are running. My job is to write loops." Peter Steinberger (OpenClaw) told developers to stop prompting coding agents and start designing the loops that prompt them. Addy Osmani's essay on the shift put the economics in one line: "the verifier is the bottleneck, not the model."
The pattern, stripped to its essentials:
Goal → Attempt → Feedback → Self-correct → Verify → Done?
A human sets one high-level, testable objective. The agent acts — reads the repo, writes code, calls APIs. The environment responds: tests fail, the compiler errors, the output misses the rubric. The agent reads the feedback and adjusts — diagnoses, not just retries. Then a separate verification step grades the output. Pass, and the loop ends. Fail, and it goes around again.
Two rules make or break the loop, and both are verified by people who run these systems at scale:
- The generator must never grade its own work. Anthropic's engineering team found that when a single agent evaluates its own output, it confidently praises mediocre work — while "tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work." Separate the maker from the checker, in a separate context window.
- The loop ends on the verifier's verdict, not the agent's confidence. No fixed iteration counts, no "it feels done." A checkable rubric and a stop condition.
My opinion: loop engineering is where senior engineering judgment lives now. And here's the thing nobody needs to tell a backend engineer twice: we already know how to do this. A well-designed agent loop is CI/CD with a probabilistic step inside it. Goal = the ticket. Attempt = the build. Feedback = the test suite. Verify = code review and staging. Stop condition = the merge gate. The discipline transfers almost one-to-one — which is why I think experienced engineers are systematically undervaluing how much of their existing judgment applies here. The new skill isn't prompting. It's writing the judge.
Layer 5: Harness engineering — everything around the agent
If the first four layers are the working parts, harness engineering is the discipline of building the vehicle they ride in. The definition I find clearest: an AI agent is a model plus a harness, and the harness is everything except the model — tools, context, prompts, memory, guardrails, feedback loops, observability. Harness engineering is the practice of designing, measuring, and improving that harness so agents are reliable in production.
Concretely, a production harness has layers of its own:
- Tool orchestration — which tools the agent can call, in what order, with what permissions; schema validation and timeout handling so a model can't retry a failed destructive call six times or escalate a prompt injection into arbitrary execution.
- Guardrails — runtime constraints: topic restrictions, injection defenses, sensitive-data handling.
- Memory and state — persistence across sessions, so the agent doesn't start every task with amnesia.
- Observability — tracing every LLM call, tool call, and retrieval; cost and latency tracking. When an agent fails at 2 AM, the harness is what tells you why.
- Lifecycle management — deployment, versioning, rollback of the agent system itself.
Note the relationship: context engineering is one component inside the harness. So are the loops from Layer 4. The harness is the outermost layer — the full operational wrapper that runs, constrains, and observes the agent once it's built. A framework gives you building blocks; an SDK gives you a vendor library; the harness is what actually ships.
The evidence that this layer matters most is striking: LangChain's coding agent jumped from 52.8% to 66.5% on Terminal-Bench 2.0 — from top 30 to top 5 — by changing only the harness, not the underlying model. And OpenAI's Codex team reportedly built a million-line application with no human-written code by investing in harness design: context engineering, architectural constraints enforced by deterministic linters, and periodic "garbage collection" agents that hunt down inconsistencies and drift.
My opinion: harness engineering is the least glamorous and most decisive of the five. Nobody demos a harness. There's no viral moment in writing a tool-permission schema or a trace viewer. But it's the difference between a demo and a product — the entire difference. Teams that treat it as an afterthought ship demos; teams that take it seriously ship products. If you remember one sentence from this post, make it this one: when you improve the harness, you change how often the agent needs human correction; when you only upgrade the model, you get faster text but not stricter control.
The evolution: why each term had to be invented
These five terms didn't appear all at once. They arrived in sequence, and each one was named only after enough people got burned by the previous phase's blind spot. The history is worth telling because it's really a story about the unit of work getting bigger.
2022–2023: Prompt engineering. The ChatGPT moment. Millions of people learn that phrasing matters — personas, instructions, output formats, few-shot examples. The unit of work is a single turn: one message in, one answer out. It works, until it doesn't. The failure mode this phase exposed: no amount of clever phrasing fixes a system problem. You can tune a prompt for a week and still get garbage, because the problem was never the wording.
2023–2024: the context crisis. Function calling ships (June 2023), and suddenly agents are possible — multi-turn systems that use tools and carry state. Almost immediately, a new failure mode appears: the context window fills up with stale, irrelevant, or badly ordered information, and the agent loses coherence around turn 15. Prompt engineering has no answer for this — it's a message-level discipline trying to solve a session-level problem. People start doing context architecture without a name for it: truncation strategies, retrieval pipelines, state compaction, tool-definition pruning.
June 2025: context engineering gets its name. Tobi Lütke posts that he prefers "context engineering" over "prompt engineering"; days later Karpathy gives it the canonical definition — "the delicate art and science of filling the context window with just the right information for the next step." What happened wasn't a rebrand, it was a correction: the community admitted the skill called prompt engineering had always been a subset of something bigger. A month later Gartner published a report titled "Lead the Shift to Context Engineering as Prompt Engineering Fades." The unit of work is now the session: everything the model sees across a run.
2025–2026: the human becomes the bottleneck. Agents get longer-horizon — real GitHub issues, terminal tasks spanning dozens of steps. And a new constraint appears: the dominant workflow is still prompt → review → refine → repeat, with a human as the decision point between every model response. It's exhausting, unscalable micromanagement, and it can't run while you sleep. The people deepest in this — the ones building coding agents for a living — feel it first.
Running parallel to these dated phases, the "what the model can do" layer gets its own vocabulary without a single coining moment: Karpathy's autonomy slider (June 2025, YC talk) — placing each task deliberately between manual and autonomous — and later his distinction between vibe coding (raising the floor: anyone can build) and agentic engineering (raising the ceiling: professional standards at machine speed). It accumulated as the design philosophy that the loops and the harness would later systematize.
June 2026: loop engineering gets its name. Boris Cherny: "I don't prompt Claude anymore. I have loops that are running. My job is to write loops." Addy Osmani: "the verifier is the bottleneck, not the model." The unit of work becomes the iteration cycle: design the goal, the feedback mechanism, and the stop condition, then let the machine run the laps. You stop driving the car and start building the track.
2026: harness engineering. A deeper blind spot: everything works in the demo and breaks in production. Agents forget context between sessions, make confident mistakes with no audit trail, and fail at 2 AM with no one watching. The discipline that fixes this is the least exciting and most encompassing — the full operational wrapper. Context engineering turns out to have been one component inside it all along. The unit of work is now the production lifecycle.
My opinion on the pattern: each phase moved the engineer's job one level up the stack. Writing words → architecting information → designing iteration → building infrastructure. And each phase was resisted the same way: the previous phase's experts insisted their level was the real work. The prompt engineers of 2023 said context was "just prompting." Some context engineers of 2025 are already saying harness work is "just DevOps." They're wrong in exactly the way the last generation was wrong. The stack keeps growing upward, and the leverage keeps moving with it. If there's a sixth term coming, my money is on it being about fleets — not one agent's harness, but the coordination layer across many of them. We'll name it after it burns us.
How the five fit together
Picture the stack, outermost to innermost:
- Harness engineering builds the vehicle: tools, guardrails, memory, observability, lifecycle. Everything except the model.
- Agentic engineering gives the model calibrated agency inside that vehicle: what it can do, and where it sits on the autonomy slider.
- Loop engineering designs the iteration dynamics: goal → attempt → feedback → self-correct → verify → stop.
- Context engineering feeds the model the right information at each step of the loop.
- Prompt engineering crafts the individual messages — the instructions and examples inside that context.
Each layer has its characteristic failure mode, and my closing opinion is a diagnostic one: most teams debug at the wrong layer. The model gives a sloppy answer to a simple question → check the prompt first (not the model; a clearer instruction with examples is usually the fix). The agent hallucinates a bad API call → they blame the model (wrong layer; it's usually context — the tool definition was ambiguous or the relevant state wasn't in the window). The agent does something destructive → they blame "AI safety" in the abstract (wrong layer; it's agency design inside the harness — the autonomy slider was set wrong, permissions too broad, no dry-run). The agent produces mediocre work repeatedly → they write longer prompts (wrong layer; it's the loop — there's no verifier, no rubric, no stop condition, so nothing can ever get better). The agent works in the demo and falls over in production → they upgrade the model (wrong layer; it's the harness — no observability, no memory, no guardrails, no one thought about what happens at 2 AM).
Get the layering right and the field stops looking like alchemy. It's still engineering — message, input, action, iteration, infrastructure — just with a probabilistic component in the middle that you architect around instead of wishing away.
References
- Karpathy's "context engineering" definition (June 2025); Lütke's original post — via Glasp summary: https://glasp.co/articles/context-engineering
- Context engineering vs prompt engineering; Anthropic's "Effective Context Engineering for AI Agents"; token usage explaining ~80% of variance — https://ainewshub.live/blog/context-engineering-for-ai-agents
- Prompt → context → harness engineering phases — https://atlan.com/know/harness-engineering-vs-prompt-engineering/
- Karpathy on Software 3.0, vibe coding vs agentic engineering, autonomy slider (AI Ascent 2026; YC AI Startup School June 2025) — https://www.thedeepfeed.ai/posts/2026-05-01-karpathy-software-3-agentic-engineering/
- "Prompt Engineering Is Dead. Long Live Loop Engineering." — the loop pattern (goal → action → verification → self-correction): https://hackernoon.com/prompt-engineering-is-dead-long-live-loop-engineering-or-fractera-blog
- Loop engineering in the SDLC; Cherny ("my job is to write loops"), Osmani ("the verifier is the bottleneck"), generator/evaluator separation — http://qualityclouds.ai/blog/loop-engineering-agentic-sdlc-quality-clouds-mcp
- The agent loop anatomy; "the generator must never grade its own work" — https://www.zyte.com/blog/now-what-exactly-is-loop-engineering-and-where-do-anthropics-fable-5-model-and-web-scraping-fit-in/?utm_activity=ORS&hss_channel=fbp-104940802978089
- Harness engineering defined — "an AI agent is a model plus a harness"; the five harness layers (tool orchestration, guardrails, memory, observability, lifecycle) — https://www.nxcode.io/resources/news/what-is-harness-engineering-complete-guide-2026
- Harness vs framework vs SDK; the full operational wrapper — https://www.digitalocean.com/resources/articles/what-is-agent-harness
- Harness engineering as "the unglamorous work that makes AI agents work" — https://dev.to/iamfaham/harness-engineering-the-unglamorous-work-that-makes-ai-agents-work-6kf
Comments & Reactions