Skip to content
Recent Articles
5/5 - Four Layers, One Agent System: Choosing the Right Engineering Lever
8 min · readRECENT ARTICLES

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

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

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.

Four layers around one modelThe model stays in the middle while the engineering lens moves outward from a single message to an entire run.
Four layers around one model
The unit of work expands outward: message, turn, run, then the lifecycle of the goal.
PromptQuestion: is this message clear?Artifact: instructions, examples, schemaFailure: ambiguity or format driftMeasure: task quality and validity
ContextQuestion: did this turn see the right evidence?Artifact: ranked working set and provenanceFailure: rot, missing or stale factsMeasure: grounding, recall, tokens
HarnessQuestion: can this action run safely?Artifact: policy, state, receipt, tool resultFailure: duplicate or unauthorized side effectMeasure: success, latency, risk
LoopQuestion: is the goal truly complete?Artifact: checkpoint, budget, verifier resultFailure: premature stop or doom loopMeasure: time to verified state
When a symptom spans layers, preserve the boundaries: fix the prompt inside the message, the context builder at the turn, the harness at the action boundary, and the loop at the goal boundary.
The model stays in the middle while the engineering lens moves outward from a single message to an entire run.

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.

The debugging orderA layered debugging sequence prevents a prompt edit from masking a retrieval, authorization, or completion defect.
The debugging order
Start with the contract closest to the observed failure, then move outward only when the evidence crosses a boundary.
1 · ObserveCapture request and run IDRecord model and settingsPreserve source and tool evidence
2 · ClassifyMessage or evidence?Action or authority?Progress or completion?
3 · Inspect promptCheck objective and constraintsCheck examples and schemaCheck data boundaries
4 · Inspect runtimeCheck context and retrievalCheck tool policy and stateCheck timeout and retries
5 · Inspect loopCheck goal predicateCheck no-progress brakesCheck budget and resume
Do not add more outer complexity until the inner contract is measurable and stable.
A practical decision
If the model cannot answer from the available evidence, fix context. If the model can answer but the action is unsafe, fix the harness. If the action works but the run cannot stop truthfully, fix the loop.
A layered debugging sequence prevents a prompt edit from masking a retrieval, authorization, or completion defect.

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.

When a local defect becomes a system incidentOuter-layer reliability comes from clear ownership: each boundary should fail closed and leave enough evidence for repair.
When a local defect becomes a system incident
Contain the failure at the layer that owns it, then verify that the outer layers remain within budget.
A model turn produces an outcome the system cannot safely trustThe message, working set, action boundary, or completion signal is incomplete
Prompt or contextAmbiguous task or missing evidenceStale source wins over current state
HarnessTool call lacks scope or receiptRetry repeats a side effect
LoopNo verified completionRepeated turns consume budget
Containment and recoveryClassify the owner, preserve the trace, pause unsafe work, repair one boundary, and rerun the acceptance case from a known checkpoint.
The model is not the final authority for permissions, state changes, or completion. The system must make those decisions explicit.
Outer-layer reliability comes from clear ownership: each boundary should fail closed and leave enough evidence for repair.

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.

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