The one-sentence version of each
Loop engineering
Designing how an agent moves from step to step — planning, calling tools, observing results, and deciding when to stop.
Harness engineering
Designing the constraints, docs, linters, and approval gates that govern what an agent — and its loop — is allowed to do.
Side-by-side comparison
| Loop engineering | Harness engineering | |
|---|---|---|
| Question answered | How does the agent move from step to step? | What is the agent allowed to do? |
| Primary artifacts | Termination conditions, retry logic, state management, step ceilings | AGENTS.md, linters, policy gates, audit trail |
| Operates at | Per session — while one loop is running | Persistent — across every session |
| Failure without it | Infinite retries, tool thrashing, unbounded cost | Unaudited actions, privilege escalation, silent policy violations |
| Typical owner | AI infrastructure / agent runtime engineer | Platform, security, or harness engineer |
| Changes how often | Per agent, per workflow | Org-wide, changes less frequently |
Where they overlap
The two disciplines meet at exactly one point: every step the loop wants to take, the harness has to approve — implicitly or explicitly. A loop that wants to call a tool has to pass through whatever policy gate the harness has placed around that tool. A harness that permits an action has no opinion on how many times the loop calls it, in what order, or whether it ever converges.
This is why treating them as one system, not competing terms, matters in practice. As we wrote in agent loops, tokenomics, and the harness: "the loop is how raw intelligence becomes finished work; the harness is the runtime that makes the loop safe and useful." Loop engineering without a harness is a loop with no brakes. A harness with no loop engineering is a set of rules with nothing well-formed to apply them to.
Which do I need to build first?
If your agent is still doing one-off tasks with a human reviewing every output, invest in the harness first — AGENTS.md, conventions, a policy boundary. That is where most of the risk and most of the value sit today. See the harness engineering checklist for the order of operations.
The moment you move to a standing loop — an agent that keeps running across many steps without a human re-prompting each one — loop engineering becomes urgent, because that is exactly where infinite retries, tool thrashing, and runaway cost show up. Build the loop design and the harness together for any workflow that runs unattended; see the loop engineering checklist for what to put in place before you ship one.
Frequently asked questions
Which came first, harness engineering or loop engineering?
Harness engineering entered common usage first, gaining traction in February 2026 after Ryan Lopopolo's account of building a production product with OpenAI's Codex and Birgitta Böckeler's analysis on martinfowler.com. Loop engineering emerged as teams running standing agent loops in production found that the loop's internal design — termination, retries, state — needed its own vocabulary distinct from the governance layer around it.
Can I have loop engineering without harness engineering?
Technically yes — you can design a well-formed loop with clean termination and retry logic that has no policy gates or audit trail around it. But that loop is unsafe the moment it touches production systems: nothing stops it from taking an action it shouldn't, and there's no record of what it did. Loop engineering without a harness works fine in a sandbox and fails the first time it runs against something that matters.
Can I have harness engineering without loop engineering?
Yes, and it's common: a harness with policy gates, approval workflows, and audit logging wrapped around a single tool call that isn't a loop at all. The harness is still valuable — it governs that one action. But once the agent starts taking multiple sequential steps, the harness alone doesn't tell you whether the loop itself is well-designed; a badly designed loop can still exhaust its budget or thrash between tool calls even inside a well-governed harness.
Do the same engineers own both disciplines?
Often, yes, especially on smaller teams — both tend to sit with whoever owns the agent runtime rather than whoever writes prompts. On larger teams they can split: an AI infrastructure engineer owns loop design (state, retries, termination) while a platform or security engineer owns the harness (policy, approvals, audit). The two need to stay tightly coordinated either way, since a change to one affects what's safe in the other.
Related reading: What Is Loop Engineering?, Harness Engineering: 30 Questions Answered, and the Harness Engineering Glossary.