Beyond the Prompt: The Four Layers of Loop Engineering

If you have been working with large language models recently, you have probably watched the vocabulary expand: prompt engineering, context engineering, harness engineering, and now loop engineering.

It is tempting to treat these as successive buzzwords—or as four competing names for the same practice. Neither interpretation is particularly useful.

A better mental model is a set of four architectural layers. Each layer answers a different question:

1. Prompt engineering: What should the model be asked to do?
2. Context engineering: What should the model know for this step?
3. Harness engineering: What system lets the agent execute reliably over time?
4. Loop engineering: What causes the system to find, perform, verify, and continue work without a human supplying every next prompt?

These layers are cumulative, not replacements. A well-designed autonomous loop still depends on clear instructions. A strong harness still needs carefully selected context. And none of the outer layers can rescue a task whose objective is vague or whose success cannot be verified.

The Four-Layer Stack at a Glance

Layer	Primary design question	Main unit of design	Typical artifacts	Common failure mode
Prompt engineering	What should the model do?	One instruction or interaction	System instructions, task prompts, examples, output schemas	Ambiguous or inconsistent output
Context engineering	What should the model see now?	One inference step’s information package	Retrieved data, tool definitions, message history, project files, context-selection rules	Missing, stale, noisy, or excessive context
Harness engineering	How does the agent execute reliably?	The runtime surrounding one or more model calls	Tool router, sandbox, retries, checkpoints, tests, permissions, persistent artifacts	Fragile execution, lost progress, unsafe actions, poor recovery
Loop engineering	What keeps useful work moving without manual prompting?	A recurring, goal-directed operating cycle	Triggers, queues, completion criteria, verifier agents, worktrees, durable state	Runaway work, false completion, repeated mistakes, unbounded consumption

The boundaries are not perfectly standardized. In some architectures, the execution loop is considered part of the harness. The newer term loop engineering places emphasis on an outer operating cycle that discovers or receives work, invokes the harness, evaluates the result, records state, and decides what happens next. Addy Osmani described it as replacing yourself as the person repeatedly prompting the agent: you design the system that does that instead.¹

That distinction is useful—but it should be treated as an emerging architectural framing, not a settled industry standard.

---

Stage 1: Prompt Engineering

The model receives an instruction

Prompt engineering is the innermost layer. It shapes the immediate request made to the model:

• the objective;
• the role or perspective to adopt;
• the constraints to respect;
• the output format to produce;
• and, when useful, examples of acceptable results.

A prompt can be simple:

Explain why this test is failing and propose the smallest safe code change.

Or it can be a structured contract describing success criteria, prohibited actions, available inputs, and a required response schema.

The important point is that the human is still driving the interaction. The human decides when to ask, what to ask, and what to do with the result.

What prompt engineering solves

LLMs are sensitive to how a task is framed. Clear instructions reduce ambiguity and make the expected result easier to evaluate. Prompt engineering is therefore not obsolete; it remains the instruction layer inside every larger agent architecture.

A useful analogy is a work order. A precise work order gives a capable technician a clear objective. But it does not provide live diagnostic data, tools, a safe workshop, progress tracking, or a process for assigning the next job.

Where prompt engineering stops

A prompt cannot provide information that was never included and is not reliably available to the model. It also does not, by itself:

• retrieve the latest project state;
• decide which tool to call;
• preserve progress across sessions;
• recover from a failed command;
• enforce permissions;
• or determine when another run should begin.

When teams try to solve those system problems only by making the prompt longer, they create a fragile wall of instructions. The problem has moved beyond wording.

---

Stage 2: Context Engineering

The model receives the right working set

A prompt is part of the context, but it is not the whole context.

For an agent, context may include:

• system and user instructions;
• conversation history;
• retrieved documents or code;
• tool definitions and tool results;
• project conventions;
• current state and recent actions;
• examples;
• and environmental metadata.

Anthropic defines context engineering as curating and maintaining the optimal set of tokens supplied during inference. The challenge is not simply to add more information, but to select the information with the highest value for the current step.²

Think of context as the agent’s workbench. Prompt engineering writes the job card; context engineering decides which drawings, measurements, tools, and previous notes should be placed on the bench before work begins.

Tools expand context—but they do not eliminate the context problem

Tools let an agent retrieve information or take actions dynamically. Through an API, database connector, search service, file system, or an open standard such as the Model Context Protocol (MCP), the agent can reach beyond model parameters and the initial prompt. MCP, for example, defines a client-server architecture through which AI applications can connect to external data sources, tools, and workflows.³

A common agent cycle looks like this:

1. inspect the current objective and available context;
2. choose a tool;
3. call the tool;
4. observe the result;
5. update the working context;
6. continue until it can answer or act.

This is already a loop, but it is an inner tool-use loop. Its purpose is to make progress within the current run. It is not yet the outer operational loop discussed later in this article.

More context is not automatically better

Context windows are finite, and irrelevant material can compete with the evidence that matters. Long-running agents also accumulate tool results, intermediate plans, logs, and generated artifacts. That creates three recurring problems:

• Context saturation: the working history grows until it must be trimmed or compacted.
• Context dilution: important evidence becomes harder to distinguish from noise.
• Information loss: summaries and compaction can omit details required by later steps.

This is why context engineering is an active process rather than a one-time data dump. The system must continually decide what to load, retain, summarize, externalize, or discard.²

Where context engineering stops

Even excellent context does not provide a durable execution environment. The agent may still fail halfway through a long task, repeat completed work, modify the wrong files, or lose continuity when a new session starts.

That is the problem addressed by the next layer.

---

Stage 3: Harness Engineering

The agent receives an execution system

A harness is the runtime that surrounds the model and turns model decisions into controlled, observable execution.

Depending on the use case, a harness can provide:

• model invocation and tool routing;
• a sandbox or isolated workspace;
• permission boundaries and approval gates;
• retries, timeouts, and error handling;
• planning and task decomposition;
• checkpoints and resumability;
• context compaction and session handoffs;
• tests, evaluators, and validation steps;
• logs, traces, and durable artifacts.

Anthropic’s managed-agent architecture separates a session, an agent harness, and a sandbox. In that design, the session is the append-only record, the harness calls the model and routes tool requests, and the sandbox provides the execution environment.⁴ The exact boundaries vary by implementation, but the principle is consistent: reliable agent behavior depends on more than the model call.

The best analogy is an operating environment. The model is a reasoning engine; the harness gives it controlled access to memory, tools, files, processes, and feedback.

Why long-running tasks expose the need for a harness

Long tasks rarely fit cleanly into one context window or one uninterrupted session. Agents may compact their history, start a fresh session, or hand work to another agent instance. Without external artifacts, the next session has to reconstruct what happened.

Anthropic reported two characteristic failure modes in experiments with long-running coding agents: agents attempted too much at once and exhausted their context mid-implementation, or later sessions saw partial progress and incorrectly concluded that the task was complete. Their mitigation used an initializer, incremental work sessions, and durable progress artifacts that the next session could read.⁵

This is more precise than saying context engineering simply “breaks after five or ten minutes.” There is no universal time threshold. Failure depends on the task, model, context window, tools, harness, and amount of generated state. The architectural issue is continuity across steps and sessions—not a stopwatch.

Stable artifacts matter more than perfect memory

A robust harness externalizes what must survive:

• the specification;
• the plan and task list;
• test results;
• changed files;
• unresolved questions;
• decisions and their rationale;
• and the current definition of done.

The agent can then reconstruct its working context from durable artifacts rather than relying on a compressed conversational memory.

Verification belongs in the system

An agent that can act but cannot reliably evaluate its output is not autonomous in a useful sense. A harness should give the agent access to objective checks wherever possible: unit tests, linters, schemas, policy checks, simulations, or independent evaluators.

Anthropic recommends simple, composable agent patterns and describes an evaluator-optimizer workflow in which one model produces a response while another evaluates it and provides feedback.⁶ Separation can reduce self-review blind spots, but another model is not automatically an independent source of truth. Verifiers also need clear rubrics, trustworthy evidence, and escalation paths.

Where harness engineering stops

A harness can reliably execute a task once it has been invoked. But who decides that there is work to do? Who starts the next run, selects the next item, and prevents the system from revisiting the same task forever?

If the answer is still “a human types another prompt,” the system has a harness—but not yet the outer loop.

---

Stage 4: Loop Engineering

The system receives an operating cycle

Loop engineering moves one level above an individual agent run. Its focus is the recurring control system that:

1. detects or receives work;
2. constructs a goal and constraints;
3. invokes an agent through its harness;
4. checks the result;
5. records durable state;
6. decides whether to continue, stop, retry, or escalate.

The key change is not that repetition exists—tool-using agents and harnesses already contain loops. The change is that the human’s repeated “what next?” action is encoded into the surrounding system.

Triggers can be time-based, such as a scheduled maintenance run, or event-based, such as a newly opened issue, a failed build, or an updated data source. A goal-directed loop may also continue until an explicit exit condition is satisfied.

This framing was popularized by Addy Osmani in June 2026. He described five operational elements plus a memory layer: automations, worktrees, skills, plugins and connectors, sub-agents, and external memory.¹ These are useful building blocks, especially for coding agents, but they are not a universal protocol or mandatory product checklist.

Six practical components

1. Automations: what wakes the system up?

An automation supplies the heartbeat. It can be a schedule, webhook, queue message, repository event, monitoring alert, or state transition.

A trigger should identify a candidate for work—not grant unlimited authority. The receiving system still needs to validate the event, establish scope, and decide whether the agent is permitted to act.

2. Worktrees or isolated workspaces: where can parallel work happen safely?

For software tasks, Git worktrees allow multiple working trees to be attached to the same repository, making it possible to check out more than one branch at a time.⁷ An orchestrator can assign separate worktrees to parallel agents so that edits do not collide in one directory.

Worktrees solve workspace isolation, not coordination by themselves. Parallel changes can still conflict semantically when they modify the same interfaces, dependencies, or assumptions. Integration and testing remain necessary.

Outside software development, the equivalent might be a temporary branch of a document, an isolated data workspace, a transaction boundary, or a disposable sandbox.

3. Skills: what reusable knowledge should not be rediscovered every run?

A skill packages repeatable instructions, domain conventions, procedures, or tool guidance. It gives the agent a reusable playbook: how this project is structured, how a release is validated, or how a recurring task should be performed.

Skills should reduce guesswork without flooding every run with every rule. The loop or harness should load the relevant skill at the right time—another example of context engineering operating inside the larger architecture.

4. Plugins and connectors: what can the agent observe or change?

Connectors link the agent to issue trackers, repositories, databases, monitoring systems, collaboration tools, and other operational surfaces. MCP is one way to standardize access to external tools and context, but it is not required for loop engineering.³

Every connector expands both capability and risk. Tool descriptions, credentials, allowed operations, result validation, and approval policies belong in the design—not as an afterthought.

5. Sub-agents or independent evaluators: who checks the work?

A maker-checker pattern separates production from evaluation. One agent proposes or implements a change; another reviews it against tests, requirements, or a rubric.

The architectural value comes from separation of roles and evidence, not simply from adding another model call. The checker should be able to reject the result, request revision, or escalate ambiguity to a human.

6. Durable state: what must survive the current session?

Loop state exists outside any single model context. It records what has been attempted, what passed, what failed, what remains, and why the system made its previous decision.

That state can live in files, a database, an issue tracker, a workflow engine, or another durable store. The specific technology matters less than three properties:

• it survives session and process boundaries;
• it can be reconstructed and audited;
• and it prevents the loop from treating every wake-up as day one.

The missing seventh component: explicit stop and escalation conditions

The six-part framing explains how a loop runs. Production designs also need to define when it must not keep running.

Useful stop conditions include:

• the objective has passed objective validation;
• the maximum number of iterations has been reached;
• no measurable progress has occurred across several attempts;
• the requested action exceeds the agent’s permissions;
• evidence is missing or contradictory;
• the proposed change has a high blast radius;
• or a human decision is required.

“Keep trying until it works” is not a completion criterion. It is an invitation to generate repeated actions, misleading self-assessments, and uncontrolled consumption.

---

Architecture in Action: An Autonomous Issue-Resolution Loop

Consider a team using a coding agent to maintain a web application.

With prompt engineering, a developer asks the model to diagnose a specific bug and produce a patch.

With context engineering, the agent retrieves the issue, relevant source files, project conventions, recent changes, logs, and tool definitions needed for the current step.

With harness engineering, the agent works in a sandbox, edits files, runs tests, records progress, recovers from tool failures, and preserves artifacts across sessions.

With loop engineering, the surrounding system can repeatedly operate the maintenance process:

1. A new issue or failed build triggers the loop.
2. The loop checks scope, priority, permissions, and duplication.
3. It creates an isolated worktree for the task.
4. The harness starts an agent with the relevant skills, issue details, and repository context.
5. The agent investigates, edits, and tests incrementally.
6. A checker evaluates the patch against the issue, test results, and project rules.
7. If validation fails, the loop supplies structured feedback for another bounded attempt.
8. If validation succeeds, the system records the outcome and prepares the change for the permitted next step.
9. If confidence is low, limits are reached, or the change requires approval, the loop escalates to a human.

The human has not disappeared. Human attention has moved from supplying every next prompt to designing objectives, permissions, evidence, boundaries, and escalation paths.

Inner Loops and Outer Loops

The word loop is overloaded, so it helps to separate three nested cycles:

The model interaction loop

The model reasons, calls a tool, observes the result, and reasons again. Context engineering determines what the model sees on each pass.

The execution loop

The harness plans, invokes the model, routes tools, checks progress, handles errors, and resumes work across steps or sessions.

The operational loop

The outer system discovers work, invokes the harness, verifies the outcome, updates durable state, and decides whether another run is needed.

This nesting explains why “loop engineering” and “harness engineering” are sometimes used differently by different authors. In implementation, the outer loop may be code inside the harness, a workflow engine around it, or a product feature. The conceptual distinction is about responsibility, not necessarily a separate deployment unit.

What Loop Engineering Is Not

It is not unlimited autonomy

Removing repetitive human prompting does not mean removing human oversight. High-impact actions may still require approval, and uncertain outcomes should escalate rather than continue indefinitely.

It is not just a cron job

A schedule can wake an agent, but a useful loop also needs a goal, context selection, action boundaries, verification, state, and stopping logic.

It is not a replacement for prompts

Every run still contains instructions. Loop engineering changes who or what assembles and submits those instructions; it does not remove the need for them.

It is not solved by adding more agents

Multiple agents can increase parallelism or provide role separation, but they also increase coordination complexity. A single agent with strong tools, tests, and state may outperform a multi-agent design whose members share the same blind spots.

It is not automatically reliable because it is autonomous

Autonomy multiplies both useful work and failure. If a manually triggered agent makes one poor decision, a human may notice. If an outer loop repeats that decision every hour, the design has automated the mistake.

A Practical Design Checklist

Before moving outward from prompts toward autonomous loops, ask:

Objective

• Is the goal specific enough for a machine to act on?
• Can success be observed or tested?
• Is there a clear boundary around what the agent may change?

Context

• What information is required for the next decision?
• How will stale, untrusted, or irrelevant context be filtered?
• What should be retrieved on demand rather than loaded every time?

Harness

• Are tools constrained and results validated?
• Can execution be resumed after interruption?
• Are progress, decisions, artifacts, and failures observable?
• Does the system use deterministic checks where available?

Loop

• What starts each run?
• What is the maximum iteration, time, or resource boundary?
• What proves completion?
• What state must persist?
• What conditions force a stop or human escalation?
• Can repeated actions be detected before they become a cycle?

If these questions do not have concrete answers, adding an automation trigger will not create a dependable autonomous system. It will only make an unreliable system run more often.

The Takeaway

The progression from prompt engineering to loop engineering is not a story about old practices becoming irrelevant. It is a story about moving the engineering boundary outward:

• Prompt engineering shapes the instruction.
• Context engineering shapes the model’s working view.
• Harness engineering shapes reliable execution.
• Loop engineering shapes the recurring system that initiates, verifies, remembers, and continues work.

The farther outward you move, the less the challenge resembles writing a clever prompt and the more it resembles systems engineering. You must design state, isolation, observability, verification, permissions, termination, and recovery.

That is the real architectural shift. You are no longer optimizing a conversation with a model. You are designing a controlled engine in which model interactions can produce durable outcomes—repeatedly, measurably, and within explicit boundaries.

Sources

Footnotes

1. Addy Osmani, “Loop Engineering”, June 7, 2026. ↩ ↩²

2. Anthropic, “Effective context engineering for AI agents”, September 29, 2025. ↩ ↩²

3. Model Context Protocol, “What is the Model Context Protocol?” and “Architecture overview”. ↩ ↩²

4. Anthropic, “Scaling Managed Agents: Decoupling the brain from the hands”, April 8, 2026. ↩

5. Anthropic, “Effective harnesses for long-running agents”, November 26, 2025. ↩

6. Anthropic, “Building effective agents”, December 19, 2024. ↩

7. Git, “git-worktree Documentation”. ↩