Loop engineering is fast becoming a popular and trending term in the AI space. In the following note, I attempt to explain what it is, why it matters, and the key insights when applying it.
Caleb Writes Code has two short videos that frame the last few years of AI engineering as a ladder: Agent Harness explained in 8min and Agent Loop explained in 8min. The ladder is prompt engineering → context engineering → harness engineering → loops. Each layer wraps the one before it, and most failures come from treating one layer as if it were another. This post uses that frame to keep four ideas apart: prompt, context, harness, and loop.
Intro
To understand loop engineering, you need a good grasp of the trends that came before it. Over the recent years we have had prompt engineering, context engineering, harness engineering, and now loop engineering. The loop is not a replacement for the earlier layers; it wraps them.
"From tool calls to external environment and now to loop outside of the harness itself to help increase the scope of what AI agents can handle is the next evolution in how we are stacking loop on top of loops." — Caleb Writes Code
1. Prompt Engineering — the ask
A prompt is what you say to the model in a single turn. A good prompt includes the role, instructions, format, examples, constraints, and so on. It is the craft of steering the LLM's response.
Prompts are local. A good prompt improves the LLM's response, but it does not give the model memory, tools, or persistence. Relying on prompt engineering is like tuning the wording of one email and expecting it to run your whole business.
2. Context Engineering — the background
Context is everything the model gets to access during a run: the system prompt, the conversation history, retrieved documents, tool outputs, files you upload, and any state you may be loading at the start.
Context is finite and ephemeral. It lives in the context window and disappears when the run ends. You can stuff more into it with RAG, summaries, or selective file reads, but the limitation is working memory — i.e. RAM.
Context engineering is about getting the right information into the window and keeping the wrong information out. It can work well for short tasks. But long tasks hit two walls:
- Context rot. Too much information in the window makes the model behave worse. (Capping context to 50–100k tokens is best.)
- False completions. When the window fills up, the model may summarize badly and may even decide that tasks are done when they are not.
Prompt and context are often confused because both appear at input time. The difference is simple: a prompt is something you write; context is something the model sees. A prompt is one ingredient of context. Context also includes memory, tool outputs, and state that you did not write by hand.
3. Harness — the structure around the model
The harness is everything that turns a model into a reliable agent. If the model is the engine, the harness is the chassis, steering, brakes, and fuel system. It is durable; unlike context, it survives after the run ends. It is architecture; unlike a prompt, it is not one message.
A harness has at least these parts:
- Memory. Procedural instructions, semantic facts, and episodic logs that outlive a single run.
- Tools and skills. Defined capabilities the agent can call: search, code execution, APIs, browsers.
- Guardrails. Rules that prevent bad outputs, unsafe calls, or runaway behavior.
- Evaluation and verification. Tests, traces, and checks that prove whether the agent did what it was supposed to do.
- Connectors. Interfaces to the systems the agent must use: GitHub, Stripe, Slack, your own database.
A good harness separates what the model knows from how it is allowed to act. Procedural memory tells it the rules. Semantic memory gives it facts. Tools give it powers. Guardrails constrain the powers. Verification keeps it honest.
Examples of harness engineering are Claude Code or Kimi Code.
4. Loop engineering — the work across time
Loop engineering is the orchestration layer. It is how an agent keeps working after the first answer, across sessions, triggers, and tasks. A loop is not the model thinking harder inside one run. It is an outer cycle.
At its core, a loop is a recursive goal: you define a purpose, and the AI iterates until complete. The canonical cycle is:
- Reason — plan what to do next.
- Act — implement the step.
- Observe — check the result.
- Repeat until the stop condition is met.
Every practical loop needs two pillars:
- Goal. What "done" looks like, stated as objectively as possible.
- Verification. How the agent knows it has reached done.
The best loops use objective verification: "keep iterating until X metric equals Y result." Subjective criteria like "until you're satisfied" are weaker and can lead to runaway loops.
Loop engineering is, in a sense, replacing yourself as the person who prompts the agent. You design the system that does the prompting instead.
Why loops matter
If you plot quality against attempts, a single prompt might get you to 50% quality. Human feedback pushes quality up slowly over several turns. A loop with built-in verification can reach high quality faster because the agent supplies its own feedback.
"Prompting = hope. Harness = Work."
A loop without a harness is automated hope. A loop with a harness is work.
Loop patterns
Not every task needs a complex multi-agent architecture. A single agent in a reason-act-observe loop is often enough. Common patterns include:
- Solo loop. One agent reasons, acts, observes, and repeats.
- Maker-checker. One agent does the work; a second agent grades it and gives feedback.
- Manager with helpers. A central agent orchestrates sub-agents, each with a narrow role.
Practical examples
- Thumbnail generator. Create 10 thumbnail concepts, score each against a rubric — clarity at small size, curiosity, emotional pull, visual contrast — select the top three, improve them, rescore, and iterate on the strongest until the score is high enough.
- Website builder. Reason about what to build, generate HTML, screenshot the result, review it, and iterate. The final output is often version 7, not version 1.
Stop conditions
A loop must know when to exit. Common stop conditions:
- Objective metric met.
- Maximum iterations reached.
- Wall-clock timeout.
- No further tool calls needed.
- The agent detects it is stuck or repeating itself.
A simple maturity ladder for loops looks like this:
| Rung | Control | What it means |
|---|---|---|
| 0 | No governor | The bare while loop. Do not ship this. |
| 1 | Stop on green | Stop when the tests pass. |
| 2 | Tests + review | One agent reviews what another wrote. |
| 3 | Bounded + verify | Budget caps plus external verification the agent cannot touch. |
Role separation matters here. The agent that writes code should not be the agent that writes tests. If one agent does both, it will write soft tests that wave its own code through. Coder edits source; tester edits tests.
The reason loops beat long single-session runs is that they reset context. Instead of stretching one conversation until it rots, you split the task into many short iterations. Each iteration starts from a clean context, reads the state it needs from files or memory, does one thing, verifies it, and writes the result back. The continuity comes from the system, not from the model's memory.
How the layers stack
| Layer | Scope | Persistence | Question it answers |
|---|---|---|---|
| Prompt | One turn | None | What do I ask right now? |
| Context | One run | Ephemeral | What can the model see right now? |
| Harness | Many runs | Durable | What structure lets the model act safely and usefully? |
| Loop | Across runs and time | Durable, time-aware | How does work keep happening without me prompting it? |
You need all four. A brilliant prompt is useless if the context is wrong. Perfect context is wasted if the harness has no tools. A great harness does nothing without loops to run it.
Common mistakes at each layer
- Prompt layer: Believing a better prompt can substitute for memory, tools, or verification. It cannot.
- Context layer: Treating the context window as a database. It is RAM, not storage.
- Harness layer: Building tools without guardrails, or memory without an update system. Memories do not refresh themselves.
- Loop layer: Letting loops run without stop conditions, budget caps, or external verification. An uncontrolled loop is a bug, not a feature.
For practitioners
If you are building agents, decide which layer you are actually working on:
- Prompt. Get a single response right.
- Context. Make sure the model has the right information in the run — no more, no less.
- Harness. Add durable memory, tools, guardrails, and verification so the agent can be trusted.
- Loop. Connect the harness to triggers and shared state so work continues across time.
The models will keep getting better, but the layers do not go away. The people who build useful systems will be the ones who know when to tune a prompt, when to expand context, when to harden the harness, and when to engineer the loop.