Prompts vs. Context vs. Loops: The 2026 AI Engineering Map

“The model can’t follow instructions.”

That complaint gets filed against three completely different bugs, and most teams debug it as if it were always the same one. Sometimes the instruction really is ambiguous. Sometimes the instruction is fine but the model never saw the right file, the right ticket, or the right schema. And sometimes the model had everything it needed and still drifted off course by step twelve of a forty-step run. Three different failures, one symptom, and if you fix the wrong layer you’ll spend a week rewriting a prompt to solve a problem that was never about the prompt.

This is the actual substance behind the “loops vs. context vs. prompts” question that’s been circulating since a June 2026 post by Peter Steinberger — founder of OpenClaw — crossed six million views in days: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”[^1] Boris Cherny, who built Claude Code at Anthropic, said the same thing on stage days earlier: “I don’t prompt Claude anymore. I have loops that are running… My job is to write loops.”[^2] Within weeks, Andrew Ng had mapped his own three nested loops for product building, and developer Addy Osmani had given the pattern a name: loop engineering.[^3]

None of this retires prompt engineering. It’s not a succession story — prompts got replaced by context, which got replaced by loops. It’s a layering story. Each discipline solves a harder problem than the one before it, and production AI systems in 2026 need all of them at once. This guide maps all four layers — prompt, context, harness, and loop engineering — explains what each one actually controls, gives you a diagnostic for finding your real bottleneck, and covers what this means if you’re building agentic automation on UiPath, LangGraph, or any stack in between.

The short answer

Four disciplines, one ratchet. Each term took over when task complexity broke the previous layer, and each corresponds to a progressively harder question about the same underlying goal: getting a model to do the right thing.[^4]

Each layer contains the one before it: the prompt is an object inside the context window; the context pipeline is a subsystem inside the harness; the harness is what a loop calls, repeatedly, on a schedule.[^4] A sloppy prompt still hurts inside the best-engineered loop ever built — nothing here is optional, it’s additive.

Why “the model can’t follow instructions” is usually a misdiagnosis

Puppyone’s practitioner framing gives a genuinely useful three-question diagnostic for figuring out which layer actually broke, and it’s worth running before you touch anything:[^5]

Can you reproduce the bad output with the same prompt and the same context, twice? If yes, it’s a prompt problem — the instruction is ambiguous or under-specified, and that’s deterministic. If it’s flaky within a single turn, something noisy got into the input: stale retrieval, tool-output variance, hidden state. That’s a context problem, and it’s stochastic because an upstream retriever or tool changed the input, not because the prompt changed.

More Read

Building Multi-Agent Systems with Google ADK: The Complete Step-by-Step Guide

From Zero to Deep Agent: A Step-by-Step Guide Using LangGraph

Guardrails in Amazon Bedrock: Building Safer and Governed Generative AI Applications in LangGrap

Did the model receive the right files, tools, and facts? If no, that’s context engineering, full stop. If yes, but the model ignored them anyway, you’re looking at a prompt problem (wrong priority order) or a loop policy problem (bad tool selection, incomplete acceptance criteria).

Did it know when to stop? If no — the loop kept retrying, drifted in scope, or claimed success falsely — that’s a harness or loop problem, and it’s almost always traceable to a missing or weak verifier.

The reason this matters operationally: most teams over-invest in the layer that’s fashionable and under-invest in the layer that’s actually broken. A team that keeps rewriting prompts when their real problem is stale retrieval is polishing the wrong floor of the building.

Layer 1: Prompt Engineering — say it clearly

Prompt engineering is the founding discipline: same model, different phrasing, different output. “Summarize this article” gets mush; “as a senior editor, summarize in three paragraphs — core claim, evidence, limitations, 150 words each” gets something usable. The toolkit is well established: role assignment, few-shot examples, step-by-step decomposition, output format contracts, explicit refusal boundaries.[^4]

Mechanically, an LLM is a context-sensitive probability machine. A role shifts the sampling distribution toward that persona’s training data; examples establish a pattern to continue; explicit constraints raise the weight of compliance. Prompting doesn’t command the model — it shapes the probability space the answer gets drawn from.

The ceiling: prompts can’t conjure facts that aren’t present. A perfectly worded instruction to “analyze our internal architecture doc” still fails if the doc was never in the context window. Prompt engineering solves the expression problem. It cannot solve the information problem, and the moment work shifts from open-ended Q&A to “do something with my data,” the center of gravity moves to the next layer.

Layer 2: Context Engineering — feed it the right information

Anthropic’s own applied AI team frames this precisely: context engineering is “the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts” — tools, message history, retrieved documents, MCP connections, everything the model sees beyond the instruction itself.[^6] The prompt is one curated object inside the context window, not the whole interface.

Two forces make this a real engineering discipline rather than a bigger prompt. First, agents generate far more candidate context than chat ever did — an agent run can touch dozens of tools, each spraying results, errors, and state into a finite window. Second, and less intuitively, more context isn’t free. Anthropic’s team points to context rot: as token count in the window increases, a model’s ability to accurately recall information from that context decreases, even in models built for long context.[^6] This isn’t a bug you can prompt around — it’s architectural. Transformers give every token pairwise attention to every other token (n² relationships for n tokens), so as context grows, that attention gets stretched thinner, and models simply have less training-data experience with long-range dependencies than short ones.

The practical rule Anthropic states directly: good context engineering means finding the smallest possible set of high-signal tokens that maximizes the likelihood of the desired outcome.[^6] Concretely, that plays out in a few well-documented techniques:

• Compaction — summarizing a conversation nearing its context limit and reinitiating with the summary, preserving architectural decisions and unresolved issues while discarding redundant tool output. Claude Code does this automatically, keeping the five most recently accessed files alongside the compressed summary.[^6]
• Structured note-taking (agentic memory) — the agent writes persistent notes outside the context window (a NOTES.md, a to-do list) and reads them back after a context reset. This is how long-running agents maintain coherence across thousands of steps without ever holding the full history in the window at once.[^6]
• Just-in-time retrieval — rather than pre-loading everything, the agent keeps lightweight references (file paths, stored queries) and loads data on demand, mirroring how humans use file systems and bookmarks instead of memorizing entire corpora.[^6]
• Sub-agent architectures — specialized sub-agents explore extensively in their own clean context windows (tens of thousands of tokens each) and return only a condensed summary (1,000–2,000 tokens) to the lead agent, keeping the orchestrating context lean.[^6]

Bad tool design is one of the most common context failures in practice: a bloated tool set with overlapping functionality creates ambiguous decision points, and “if a human engineer can’t definitively say which tool should be used in a given situation, an AI agent can’t be expected to do better.”[^6]

The ceiling: perfect inputs, unsupervised execution. The model can have every fact it needs and still plan well, then drift by step seven; misread a tool result and build on the misreading; or report confident completion on work that doesn’t actually run. Input quality was never the whole game, because nobody was watching the work happen turn over turn. That’s the next layer.

Layer 3: Harness Engineering — control the run

LangChain states this one as a formula: Agent = Model + Harness. Harness = Agent − Model.[^4] The harness is everything around the weights — what the model sees, what it can touch, how steps sequence, what persists, who checks the output, and what happens on failure. Oracle’s engineering team makes the same split explicit: an agent’s architecture has two separable layers, the model (the inference engine that reasons) and the harness (the code that prepares context, executes tool calls, enforces constraints, and persists state) — and most agent engineering work happens in the harness, not the model.[^7]

The analogy that lands cleanest: you brief a new hire before an important client visit (that’s the prompt). You hand them account history and a pricing sheet (that’s context). But if the meeting genuinely matters, you also send a checklist, require a check-in call at key milestones, review the recording afterward, and check results against criteria. Nobody skips that bundle for high-stakes human work. Harness engineering is refusing to skip it for agents.[^4]

Concretely, a harness owns:

• Tool integration — defining tools with clear names, descriptions, and schemas, classified as data tools (retrieve context), action tools (side effects), or orchestration tools (invoke sub-agents).[^7]
• State and memory — the read/write lifecycle around each turn: reading conversational history, knowledge base entries, and entity memory before the model is called; writing new memory after it acts.[^7]
• Verification — a separate check on whether the model’s “done” claim is actually true, since a terminal message with no more tool calls doesn’t mean the goal was met; it might just mean the model gave up or asked a clarifying question the harness didn’t notice.[^7]
• Observability — structured logging of every reasoning step, tool call, argument, and result, because a 20-iteration run touching eight tools produces a trace too complex to debug from vibes alone.[^7]

The results are measurable. OpenAI ran a near-million-line production application where agents wrote 100% of the code and the engineers built the environment around them; Anthropic got Claude running unattended for hours via fresh-context resets and independent evaluator agents; LangChain reported the same model jumping from rank 30 to rank 5 on Terminal Bench purely by changing the harness, not the weights.[^4]

The ceiling: a perfect harness still controls one run, and you’re still the trigger for every run. You decide when to start it, you read the result, you decide what happens next. The agent got supervised; the workflow didn’t get autonomous. For a single high-stakes task, that’s fine. The moment you have recurring work — triage every new issue, refresh a report weekly, keep a test suite green — you become the cron job. That’s the bottleneck the fourth layer removes.

Layer 4: Loop Engineering — remove yourself from the run

Addy Osmani’s definition, the one nearly every other write-up on this topic cites: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”[^3] The prompt still exists — a machine writes it now. The harness still runs — a loop decides when it runs and whether the result is actually done. Instead of issuing instructions turn by turn, you define a goal with a testable termination condition, a verifier that decides “good enough,” a trigger (cron, webhook, another agent), and an exit path for failure. Then you walk away.

The five building blocks (plus the one everyone forgets)

Osmani’s breakdown of what a working loop needs is now the reference model cited across the space:[^3]

The memory piece is easy to underrate. “The model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesn’t.”[^3] Two native implementations have emerged as the reference primitives: Claude Code’s /goal (a durable objective that persists across turns, checked by a separate evaluator model so the agent that wrote the work isn’t the one grading it) and OpenAI Codex’s equivalent /goal command, which supports pause, resume, and clear across a long-horizon run.[^8]

What the loop is actually doing, mechanically

Strip away the tooling and every agent loop — whether it’s a single tool-calling agent or a full autonomous pipeline — runs the same five-stage cycle, repeating until a stop condition fires:[^7]

1. Perceive — take in input: a user message, a tool result, an error, or the outcome of the last action.
2. Reason — the LLM processes everything currently in context and decides what to do next.
3. Plan — for complex tasks, decompose the objective into subtasks; simple tasks skip straight to acting.
4. Act — execute something: a tool call, an API request, a code run.
5. Observe — examine the result. Did it work? Is the task actually complete? Does the plan need adjusting?

Then it loops back to step one. In pseudocode this reduces to six lines — while not done: call the model, execute any tool calls, append results, repeat until no tool calls remain — and that six-line pattern, formalized as ReAct (Reasoning + Acting) by Princeton and Google Research in 2022, is the architecture every major AI company has converged on independently.[^7][^9] Yao et al.’s original ReAct paper measured the gap directly: models that reason, act, and observe in a loop scored 34% higher on ALFWorld and 10% higher on WebShop than action-only baselines.[^9] Loop engineering isn’t a new architecture; it’s the discipline of making that 2022 pattern survive unattended, at scale, for hours.

Stop conditions are not optional

A loop that doesn’t know when to stop doesn’t fail gracefully — it fails expensively. The canonical cautionary example, cited across multiple independent sources covering this topic: an agent deployed to scrape a website hit a structure change, got an empty result, had no hard stopping condition, and called the broken tool 400 times in five minutes before hitting a platform rate limit.[^7] A production loop needs, at minimum:

• A hard iteration cap (max turns before forced exit)
• A wall-clock timeout
• A token or dollar budget per run
• No-progress detection — exiting when the same tool gets called with identical arguments for the third consecutive time, a strong signal the agent is stuck, not working[^7]
• A goal-completion check that is a real predicate, not just the absence of further tool calls — the model returning a terminal message doesn’t mean the objective was met; it might mean the model asked a question the harness silently ignored[^7]

The economics are real, not theoretical

This is where loop engineering diverges from every layer before it: it’s the first layer where the failure mode is measured in dollars, not just quality. Anthropic’s own internal data shows agents consume roughly 4x more tokens than standard chat, and multi-agent systems push that to approximately 15x.[^6][^7] Uber reportedly capped engineers at $1,500 per person per tool per month for agent tooling after burning its annual AI budget in four months — the expense moved from writing code to running the thing that writes code.[^10] The practitioner consensus on guardrails, repeated across every source covering this in 2026, comes down to three non-negotiables: a hard iteration ceiling, a diff/no-progress check that kills a run once recent passes stop changing anything, and a spend cap that ends the run before billing does.[^10] Without all three, what you’re running isn’t a loop — it’s an open invoice.

There’s a second, quieter risk that compounds the longer a loop runs unattended: comprehension debt, Osmani’s term for the growing gap between what exists in your codebase or knowledge base and what you actually understand, because the faster a loop ships work you didn’t personally review, the faster that gap widens.[^3] Verification by a sub-agent tells you tests passed. It does not tell you the loop didn’t also flip a feature flag, use the wrong credentials, or make a change outside your intended blast radius — that requires governance (identity, scope, audit trail, rollback path), not just a verifier.[^11]

The full comparison

A practical diagnostic for daily use, adapted from the AI Builder Club’s framing: output misunderstands the ask → prompt problem. Output is fluent but wrong or stale → context problem. Output starts right and degrades across steps, or claims success falsely → harness problem, usually a weak verifier. Output is fine but nothing happens unless you personally kick it off → loop problem: you’re the cron job.[^4]

What this means for RPA and agentic automation teams

If you’re building on UiPath, Maestro, or any agent framework, this stack maps directly onto decisions you’re already making, whether you’ve named them or not.

Prompt engineering is the system prompt on your triage agent or the instructions block in Agent Builder — worth getting right, but it’s the smallest lever you have.

Context engineering is the layer where a knowledge format like Open Knowledge Format (OKF) does its work: a versioned, typed bundle of process documentation, runbooks, and schema definitions is exactly the “smallest set of high-signal tokens” Anthropic’s guidance calls for, instead of an agent re-deriving your queue-retry policy from scratch every run. It’s also the layer MCP servers operate at — MCP is how an agent’s context gets extended with live tool access rather than static documents.

Harness engineering is your Orchestrator integration, your exception-handling logic, and — critically — whatever checks whether a bot actually completed a transaction correctly versus just exiting without erroring. This is the layer most RPA teams have historically under-invested in relative to prompt/context work, and it’s a recurring root cause in why agentic automation programs fail: a bot that reports success without a real verification step is a harness failure wearing a green checkmark.

Loop engineering is a scheduled Orchestrator trigger evolving into something closer to /goal — not “run this process at 6am” but “keep reconciling this queue until it’s clean, verify with a separate check, and escalate to a human if you’re not making progress after N attempts.” Very few automation programs are here yet, and the token-cost lesson from coding agents applies directly: an unattended automation loop without a hard iteration cap and a cost budget is not more autonomous, it’s just a slower version of the same runaway-tool-call failure mode documented above.

The organizations getting real value from agentic automation in 2026 aren’t the ones with the cleverest prompts. They’re the ones who correctly diagnosed which of these four layers was actually their bottleneck before spending engineering time on it.

Key Takeaways

• Prompt, context, harness, and loop engineering are nested layers, not a succession of fads. Each one wraps the layer before it; none of them retire the others, and a sloppy prompt still hurts inside the best-engineered loop.
• “The model can’t follow instructions” is usually a misdiagnosis. Use the three-question test: reproducible with the same prompt and context → prompt problem. Flaky within one turn → context problem. Only breaks after N turns → harness or loop problem.
• Context engineering’s core discipline is subtraction, not addition — Anthropic’s own guidance is to find the smallest set of high-signal tokens, because context rot means more tokens can actively degrade recall, not just cost more.
• Harness engineering is where most of the actual engineering work happens — LangChain’s formula, Agent = Model + Harness, means the model is often not your bottleneck; your verification and state logic is.
• Loop engineering is the first layer where failure is measured in dollars. Agents run ~4x the tokens of standard chat, multi-agent systems ~15x. A loop without a hard iteration cap, a no-progress check, and a spend budget isn’t a loop — it’s an open invoice.
• For automation teams, this stack maps directly onto tools you already use: OKF-style knowledge bundles are context engineering, Orchestrator exception handling is harness engineering, and scheduled /goal-style automations are the next step in loop engineering — most programs are still one or two layers behind where the leading edge already is.

FAQs

What’s the difference between prompt engineering and context engineering? Prompt engineering is about what you ask the model to do in a single turn — the instruction wording, format, and constraints. Context engineering is about everything else the model sees while doing it — retrieved documents, tool outputs, message history, file structure. Anthropic frames context engineering as the natural progression of prompt engineering: the prompt becomes one curated object inside a much larger, actively managed context window.

What is loop engineering? Loop engineering, a term popularized by Addy Osmani in June 2026, is the practice of designing the system that prompts, checks, and re-runs an AI agent so a human doesn’t have to trigger every turn manually. It wraps prompt, context, and harness engineering rather than replacing them, adding scheduling, verification, and stop conditions on top.

Is loop engineering just agent orchestration rebranded? Partly. Orchestration frameworks (LangGraph, CrewAI, etc.) are the tools. Loop engineering is the discipline: deciding how work continues across runs, how it’s checked, and how and when it stops. You can use an orchestration framework badly (no verifier, no budget) or well; loop engineering is the practice that makes the difference.

How do you stop an AI agent loop from running forever? Layer multiple stop conditions: a hard maximum-iteration cap, a wall-clock timeout, a token or dollar spend budget, no-progress detection (exiting when repeated iterations produce no new information or repeat the same tool call), and a goal-completion check based on a verifiable predicate rather than just the model going silent.

What is harness engineering and how is it different from loop engineering? The harness is the environment a single agent run operates inside — its tools, state, and verification logic (LangChain’s formula: Agent = Model + Harness). The loop is what decides when that harness runs and whether the result is good enough to stop on. A loop without a harness is an unattended agent with no guardrails; a harness without a loop is a safe system that still needs a human to press go every time.

Why do AI agents consume so many more tokens than a chat conversation? Because every loop iteration is a full LLM call that includes the growing context of prior tool results, reasoning traces, and state. Anthropic’s internal data shows single agents run roughly 4x the token consumption of standard chat interactions, and multi-agent systems (where a lead agent spawns sub-agents) run closer to 15x, since each sub-agent independently explores and reasons before returning a condensed summary.

References

[^1]: Peter Steinberger (@steipete), post on X, June 7, 2026, cited across multiple sources including Firecrawl and Data Science Dojo coverage of loop engineering.

[^2]: Boris Cherny, creator of Claude Code at Anthropic, quoted in Firecrawl’s “Loop Engineering: Should You Stop Prompting Agents and Start Designing Loops,” June 11, 2026 — https://www.firecrawl.dev/blog/loop-engineering

[^3]: Addy Osmani, “Loop Engineering,” June 7, 2026 — https://addyosmani.com/blog/loop-engineering/

[^4]: AI Builder Club, “Prompt vs Context vs Harness vs Loop Engineering: The 4 Shifts,” June 11, 2026 (updated July 2, 2026) — https://www.aibuilderclub.com/blog/prompt-context-harness-evolution

[^5]: Puppyone, “Loop Engineering vs Prompt Engineering vs Context Engineering: A 2026 Practitioner’s Map,” June 17, 2026 — https://www.puppyone.ai/en/blog/loop-vs-prompt-vs-context-engineering-2026-map

[^6]: Anthropic Applied AI team, “Effective context engineering for AI agents,” September 29, 2025 — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[^7]: Richmond Alake, “The Agent Loop Decoded,” Oracle Developers Blog, June 11, 2026 — https://blogs.oracle.com/developers/the-agent-loop-decoded-three-levels-every-agent-engineer-must-know; and Casius Lee, “What Is the AI Agent Loop?,” Oracle Developers Blog, March 16, 2026 — https://blogs.oracle.com/developers/what-is-the-ai-agent-loop-the-core-architecture-behind-autonomous-ai-systems

[^8]: Puppyone, “Loop Engineering: 5 Building Blocks + The Missing One,” June 12, 2026 — https://www.puppyone.ai/en/blog/what-is-loop-engineering-5-building-blocks-missing-one

[^9]: Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models,” Princeton University and Google Research, arXiv:2210.03629, 2022 — https://arxiv.org/abs/2210.03629

[^10]: Data Science Dojo, “Agentic Loops Explained: From ReAct to Loop Engineering (2026 Guide),” June 9, 2026 — https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/

[^11]: Puppyone, “Loop Engineering: 5 Building Blocks + The Missing One” (governed workspace / identity, scope, audit, rollback section) — https://www.puppyone.ai/en/blog/what-is-loop-engineering-5-building-blocks-missing-one

Further sources consulted: MindStudio, “What Is Loop Engineering? The New Meta for AI Coding Agents,” June 9, 2026; Firecrawl, “Loop Engineering: Should You Stop Prompting Agents and Start Designing Loops,” June 11, 2026.