5/5 - Four Layers, One Agent System: Choosing the Right Engineering Lever

#AI Agents #Prompt Engineering #Context Engineering #Harness Engineering #Loop Engineering

Prompt, context, harness, and loop engineering are not competing names for the same activity. They are nested control surfaces around one model call. Prompt engineering shapes the message. Context engineering shapes everything the model sees on a turn. Harness engineering governs tools, state, permissions, recovery, and evidence. Loop engineering governs repeated turns, goals, progress, and stopping.

The distinction matters because symptoms travel across layers. A model that invents a fact may need better evidence rather than a stronger instruction. An agent that repeats a tool call may need a no-progress brake rather than another example. A dangerous action may need a policy boundary rather than a more cautious system prompt. The fastest debugging path is to identify the smallest layer that owns the failing contract, then check whether an outer layer is hiding the evidence.

The four layers in one view

The model is in the middle. The layers wrap outward because each one controls a larger unit of work and a longer time horizon. Prompt work happens inside one call. Context work happens at the boundary of a turn. Harness work happens around the run. Loop work happens across turns and sometimes across hours.

The nested view prevents category errors: a prompt revision cannot solve a missing source, an unsafe tool, or an untruthful completion signal.

The matrix gives operators a common vocabulary for deciding whether to edit a message, rebuild context, harden execution, or redesign the loop.

Layered systems are easier to operate when the triage path asks “which contract is false?” before asking “which prompt should we try?”

Description: Each card answers four questions: what the layer owns, what artifact it produces, what failure it catches, and what metric can tell you whether it works. Those are more useful distinctions than a list of fashionable techniques.

What changes as you move outward

At the prompt layer, iteration is cheap and local. You can change wording, examples, delimiters, or an output schema and rerun a fixture set. At the context layer, changes affect retrieval, ranking, compression, source freshness, and token budget. At the harness layer, changes can authorize or deny side effects and must be tested against restart, timeout, and duplicate execution. At the loop layer, changes affect spend, duration, concurrency, and whether a run stops in a truthful state.

A comparison by example

Imagine an agent asked to update a service and open a change request. Prompt engineering can make the requested format and acceptance criteria clear. Context engineering supplies the repository instructions, current configuration, test output, and deployment policy. Harness engineering decides whether the agent may edit files, run tests, and create the request, then records the exact diff and result. Loop engineering decides whether to keep repairing, pause for review, or stop after tests and policy checks pass.

If the agent changes the wrong file, first inspect the context: did it see the repository map and current branch? If it produces invalid JSON, inspect the prompt and parser. If it opens a request for the wrong repository, inspect harness identity and authorization. If it keeps repairing a failing test without changing the state, inspect the loop’s progress ledger and verifier. The same visible phrase, “the agent failed,” can refer to four very different defects.

One model, four budgets

The budgets differ by layer. Prompt budget is clarity: how much instruction and example material is needed before extra words add confusion. Context budget is information: how many tokens and which sources can be carried without drowning the signal. Harness budget is authority: which tools, credentials, resources, and side effects are allowed. Loop budget is time: how many turns, tokens, dollars, and parallel actions can be spent before the system pauses or fails.

Do not trade one budget for another blindly. Raising the context limit can increase cost and latency without repairing poor ranking. Raising the turn cap can make a doom loop more expensive. Adding more tools can make planning harder and increase blast radius. A useful optimization improves the relevant contract while preserving the outer boundaries.

The failure surface is cumulative

The outer layers depend on the inner ones, but they do not replace them. A harness can enforce tool permissions while a weak prompt causes unnecessary calls. A loop can have a correct completion check while context rot causes it to reason from stale evidence. A well-ranked context can still produce a malformed action if the prompt lacks a schema. Reliability is therefore multiplicative in practice: a serious weakness in one layer can dominate an otherwise excellent system.

A practical operating model

Use one trace and one vocabulary across all four layers. Record prompt version, context item IDs, model and decoding settings, tool policy snapshot, run state, budget remaining, and verifier outcome. This lets an operator answer a simple but important question: what exactly did the system know, what did it ask the model to do, what did the model request, what did the harness allow, and why did the loop stop?

Build tests by layer and then a small end-to-end set. Prompt tests should cover ambiguity, examples, schema, and refusal. Context tests should cover retrieval scope, stale facts, compression, token pressure, and provenance. Harness tests should cover authorization, malformed arguments, timeouts, idempotency, credential scope, and restart. Loop tests should cover completion, pause and resume, no progress, budget exhaustion, cancellation, and child work. End-to-end tests should prove that the layers compose without bypassing one another.

The source visual that inspired this series is useful precisely because it keeps the layers separate. Its practical implication is not to create four teams or four products. It is to ask the right question before changing the system. When quality drops, do not assume the prompt is guilty. When a tool is unsafe, do not assume the model needs more caution. When a run does not finish, do not add turns before checking the completion predicate.

A concrete debugging walk-through

Imagine that an agent updates a deployment but reports success while the service still serves the old version. Start with the loop: did the completion predicate query the live deployment or only inspect a model-generated summary? If the predicate is correct, inspect the harness: did the tool have the right cluster and namespace, and did its receipt include the observed rollout digest? If the receipt is correct, inspect context: did the agent see a stale deployment manifest or old health output? Finally inspect the prompt: did it clearly distinguish the desired digest from the current digest and require a verification step?

This order is deliberately outside-in for a side effect and evidence-driven for a model response. It prevents a common anti-pattern: editing the prompt until the agent sounds more confident while the real defect is an authorization mismatch, stale context, or a verifier that checks the wrong state.

Review the interfaces, not only the layers

The most expensive defects live between layers. Prompt and context can disagree about which source is authoritative. Context and harness can disagree about whether a tool result is trusted. Harness and loop can disagree about whether a timeout means “retry” or “reconcile.” The interfaces should therefore carry explicit fields: source and authority for context, schema and argument digest for tools, state revision and idempotency key for actions, and verifier result plus stop reason for loop transitions.

A compact readiness checklist

Prompt: can a parser and a reviewer state what a valid answer means?
Context: can an authorized operator list exactly what evidence was shown and why?
Harness: can the system deny, reconcile, retry, and resume a side effect safely?
Loop: can the system prove success, pause on uncertainty, and stop on no progress?
Whole run: do trace, cost, latency, policy, and verifier evidence share one identity?

If one answer is “not yet,” add observability and a bounded test before adding more autonomy. The goal is not to make the model appear more capable. It is to make the entire system predictable under normal work, bad inputs, dependency failures, and restarts.

Primary references

The takeaway

Prompt, context, harness, and loop engineering are four views of one agent system. The model remains central, but reliability is determined by the contracts around it. Make the message clear, the working set deliberate, the action boundary safe, and the completion signal truthful. Then measure each layer separately and the whole run together.

4/5 - When Done Actually Means Done: Loop Engineering for Long-Running Agents