Prompt, context, loop, harness
Four words that get used as one. A map of the layers, what each one asks, and why the loop that checks the work is where most agents break.
Anyone who has spent time this year around people building with coding agents has heard four phrases used as if they were one thing with four names: prompt engineering, context engineering, loop engineering, harness engineering. They are four layers. Most of what follows in this series was learned delivering software under contract, where someone else decides when the work is done, and then built into Rindo. This first piece is only the map.
| Layer | The question it answers |
|---|---|
| Prompt engineering | How do I phrase the instruction? |
| Context engineering | What goes into the window, and what stays out? |
| Loop engineering | How does the agent iterate, when does it stop, and who checks? |
| Harness engineering | Everything around the model: tools, sandbox, memory, guardrails, observability |
| Evals | How do we know a change made it better? |
↑ Evals · outside all three: did the change make the whole better?
Context engineering
Prompt engineering asks how to write the instruction. Context engineering asks which configuration of everything the model sees is most likely to produce the behaviour you want, including what reaches the window without you putting it there. An agent’s state is not in its weights. It is in the window: the system prompt, the tool definitions, the conversation so far, the results the tools returned, the documents retrieved, the long-term memory, the plan and the intermediate reasoning.
The term exists because single-turn chat never needed it. A multi-step agent’s window grows on every step, and most agent failures are not a weak model. They are the right information not being in the window at the moment the model needed it.
Three facts shape the technique. Performance degrades as input grows, well inside the advertised limit, so more is not better; people call it context rot. Models attend to the start and the end of the window more than the middle, so what matters goes to one of the ends. And every token is a trade between completeness and noise.
The techniques follow from the facts. Compaction: when the window fills, summarise the history, keep the decisions and the constraints, drop the raw logs. Just-in-time retrieval: do not preload; let the agent fetch what it needs through tools, which is why a file-native setup, a conventions file, a directory tree and grep, works better than a wall of pasted context. External memory the agent reads and writes across sessions. Structured notes, so a plan survives compaction. Sub-agents that take a sub-task into a window of their own and return a condensed result. Tool design: few tools, clear descriptions, no overlap, compact output, because a tool description is context too and costs tokens. And context awareness: tell the model how much room is left, and it paces itself.
The working rule is the smallest set of tokens with the highest signal. Start minimal. Add only when an eval says so, because adding context makes things worse without anyone noticing, and feel is not a measurement.
Loop engineering
A chain runs a fixed sequence. A loop is dynamic: the agent can go back a step, adjust to feedback, try a different approach. Chains are predictable and easy to trace; loops suit work where the right path is not known in advance, which is debugging, which is exploring an unfamiliar API, which is most of software.
The basic cycle: intent, then context (gather the code, the docs, the errors, the constraints), then action (edit a file, run a command, call a tool), then observation (test output, a compiler error, a diff), then adjustment. A good loop has a concrete goal with a checkable stop condition, enough tools, context management so it does not drown, an explicit exit on failure so it cannot run forever, and error handling that adapts rather than retrying the thing that just failed.
Three patterns recur. Maker and checker: one agent checks another’s work, and a separate verifier with instructions of its own does better than an agent grading itself. A spine: persistent state the agent writes to on every turn, a Markdown file, a memory store, a task tracker, so progress survives and old mistakes are not repeated. And the loop that refuses to end: a hook blocks the model’s attempt to finish and re-injects the original prompt into a fresh window, each turn starting clean but reading the last turn’s state from disk, with success decided by an external check rather than by the agent’s own opinion.
Harness engineering
If you learn one word, learn this one. The shortest statement of it, by now common currency: an agent is a model plus a harness. The model does the reasoning. The harness is everything else: how context is delivered, the tool interfaces, the plan artifacts, the verification loop, the memory, the sandbox. A production harness has five layers: tool orchestration, a verification loop, context and memory, guardrails, observability. Loop engineering is one layer inside it; context engineering is another. They do not compete.
The most useful framing I know is Birgitta Böckeler’s, from inside Thoughtworks: a harness is made of guides, which steer the agent before it acts, and sensors, which observe after it acts and let it correct itself, and the two are complementary. Only sensors, and the agent keeps repeating the same mistakes; only guides, and it encodes rules without ever finding out whether they worked. My own ranking, from using both, is narrower than hers and is mine: when a team can invest in only one thing next, invest in a sensor. A longer instruction file raises the odds. Deterministic feedback after the act, a linter whose message says how to fix the problem, a check on module boundaries, a mutation score, closes the loop. An agent does not absorb a team’s culture by sitting near it. It absorbs what the harness enforces.
On standing: context and harness engineering are settled vocabulary, with surveys of harness systems and formal semantics for the agent loop. “Loop engineering” lives mostly in vendor writing; academics say agentic loop engineering and mean the discipline of making an agent’s work auditable and reproducible, inherited from DevOps. Do not be surprised when someone senior has never used the phrase.
Where it breaks
The layer to study is the verification loop, because that is where most agents fail, and it is where the next piece starts.
Rindo’s share of this map is the context layer of the harness, kept where the team can read it: a Guidance page with the project’s conventions, and an instructions page for each work role, that every connected assistant is pointed at before it acts. The agent does not learn the project by sitting near it. It reads what the team wrote down.