What is it? A comprehensive survey of two rapidly converging disciplines in production AI agent development. Harness engineering is the practice of designing the software infrastructure around an LLM — tooling, sandboxes, memory, state, permissions, observability. Loop engineering is the practice of designing the iterative execution cycle that governs how an agent perceives, acts, and reflects. In 2026, these two fields are merging into a unified engineering discipline: the agent execution system as a first-class software artifact.
This page summarises findings from 40+ distinct sources: research papers, engineering blogs from Anthropic, OpenAI, and MongoDB, GitHub repos and awesome-lists, Hacker News discussions, practitioner guides, and production postmortems.
The key idea that every source converges on: the LLM is the smallest part of the agent system. The MongoDB/Bazeley 2026 piece puts it bluntly: the harness comprises six components around the model, and the layer underneath them — durable state, governance, cost control — is what turns a harness into a platform. The arXiv survey by Tang et al. (2026) formalises this as an ETCSL+ tuple (Execution, Tool, Context, Strategy, Learning, Verification).
The literature converges on this decomposition (from Tang et al. survey, MongoDB, Firecrawl, Snowan):
The sandbox or container where agent code runs. Debates centre on whether the harness lives inside or outside the sandbox. The HN discussion ("The agent harness belongs outside the sandbox") surfaces the key tension: you need the harness outside for safety, but inside for performance and access. The emerging pattern is a layered approach — core harness outside, execution sandbox inside, with structured handoffs.
How tools are registered, discovered, called, and governed. Anthropic's managed agents architecture decouples "brain" (model + harness) from "hands" (tools + sandboxes). Key patterns include MCP (Model Context Protocol) for standardised tool interfaces, curated tool registries with permission boundaries, and row-level access control baked into every tool call rather than at the LLM level.
Anthropic's 2025-2026 harness posts identify this as the hardest problem. Key techniques: context resets (tear down session mid-task, rebuild from compact handoff file), AGENTS protocol for inter-agent messaging, sliding context windows, and structured summarisation to compress history. Claude Code and Codex both implement context window rotation with summarisation layers.
The Planner/Generator/Evaluator pattern from Anthropic's harness design. An initializer agent sets up the environment once, hands off to a coding agent that makes incremental progress per session. Addy Osmani documents that all major coding agent products (Claude Code, Codex, Cursor, Windsurf, Copilot) now ship the same five loop patterns — the shape is identical across products.
Reflection loops, self-correction, anti-drift mechanisms. The Augment Code guide articulates PEV loops (Plan → Execute → Verify) as the core pattern. Six research-backed mechanisms from OpenClaw Index: structured reflection prompts, external verifier models, execution trace analysis, test-failure-driven retry, confidence-threshold gating, and human-in-the-loop escalation.
Quality gates, output validators, permission boundaries. Anthropic's harness design treats verification as a first-class component: "verifier separation" is named as one of the six shared patterns across production agent deployments. Every source agrees: guardrails must be built before complexity.
The Tang et al. arXiv paper (2026) provides the most rigorous formalisation. An agent execution harness is a six-component tuple:
Harness = ⟨E, T, C, S, L, V⟩ Where: E = Execution environment (sandbox model, isolation level) T = Tool registry & orchestration layer C = Context management (window, memory, summarisation) S = Strategy & planning (task decomposition, workflow) L = Learning & reflection (self-correction, feedback) V = Verification & guardrails (validation, safety, cost control)
The survey catalogs 110+ papers and 23 production systems mapped against this framework.
Loop engineering is the systematic design of the iterative cycle that governs how an agent perceives, reasons, acts, and reflects. The term was coined in early 2026 and rapidly became a distinct discipline. The core idea: you design the system that prompts the agent, not the prompt itself. The agent loop is a software engineering artifact, not a prompt engineering artifact.
From the Data Science Dojo guide, Remio.ai, and Youngju.dev (Jun 2026):
ReAct (Reasoning + Acting) was the baseline. The agent reasons, calls a tool, observes the result, reasons again. Simple, well-understood, but limited — no persistence, no state, no long-running capability.
Reflexion added self-correction: the agent evaluates its own outputs and retries. Plan-and-Solve emerged. Self-Reflexion and inference-time scaling extended the pattern. The agent gained the ability to catch its own mistakes — but only within a single context window.
Named after Ralph Wiggum ("I'm in danger!"), the Ralph Loop is deceptively simple: run the agent in a while loop. Feed it a spec, let it make one change, check in, repeat. The innovation is outsourcing context management to the loop — each iteration gets a fresh context window, with state persisted as files (DONE.md, SPEC.md, BLOCKED.md). Geoffrey Huntley's original description: "feed the agent the same prompt against a written spec, let it pick one task and implement it, then start a fresh instance."
Both Claude Code (/goal) and OpenAI Codex (/goal) now ship first-class Ralph loops. The loop is built into the tool: iteration counters, DONE/BLOCKED conventions, token budgets, audit logs — all handled by the harness. The product distinction between loop and harness disappears: the harness is the loop.
From Lushbinary, Youngju.dev, Addy Osmani's analysis (all Jun 2026):
| Component | Description | Failure Mode |
|---|---|---|
| 1. Goal definition | Clear spec, DONE criteria, termination conditions | Goal drift, unbounded iteration |
| 2. Context rotation | Fresh window per iteration, structured handoff file | Context loss between iterations |
| 3. State persistence | File-based (DONE.md, BLOCKED.md) or DB-backed state | State corruption, stale state |
| 4. Guardrails | MAX_ITER, token budgets, cost caps, timeout | Infinite loops, billing surprises |
| 5. Reflection | Self-evaluation, test-driven recovery, anti-drift | Degradation over time, uncorrected errors |
The clearest theme from this research: harness engineering and loop engineering are converging into a single discipline. In the earliest work (2023-2024), the harness was "everything around the LLM" — tools, sandbox, APIs — and the loop was just the model call. By mid-2026, the loop is the harness: context rotation is the loop iteration, state persistence is the harness data layer, guardrails are both loop boundaries and harness safety controls. The two terms describe the same system from different angles.
As Addy Osmani put it: "You stop arguing about which tool and start designing loops that work regardless of which agent you happen to be sitting in."
The HN thread (121 comments, June 2026) surfaces the core tension: harness outside vs harness inside the sandbox. The emerging consensus is three layers: (1) a hypervisor/safety layer outside everything, (2) the harness orchestrating the agent, (3) the sandboxed execution environment. As one commenter noted: "if your harness has an ability to do something the LLM can't, and it has a set of conditions under which the LLM can cause those to be invoked, you have to assume the LLM will work out those conditions." The key insight from the Mendral article: the harness belongs outside the sandbox because the harness is the trust boundary — it must not be subvertable by the agent.
Anthropic's harness post includes a sharp example: Claude Sonnet 4.5 tended to wrap up early near the context limit, so the harness added a context reset. With Claude Opus 4.5, that behaviour was gone — and the reset logic became overhead. The harness must adapt per-model. A static harness design that works for one model may be suboptimal or harmful for another.
SylphAI's paper "The Last Harness You'll Ever Build" (Apr 2026) argues that harness design is converging to a universal pattern: AdaL (SylphAI), Claude Code (Anthropic), Codex (OpenAI) — all share the same fundamental architecture. If this holds, harness engineering becomes a commodity and the competitive advantage shifts to data, models, and domain-specific loop design.
Most published harness engineering comes from coding agents (Claude Code, Codex, Cursor, Copilot). These are the most mature domain. General-purpose agent harnesses (research agents, email agents, business process agents) are 6-12 months behind. The patterns from coding agents — context rotation, file-based state, reflection loops — are expected to generalise but haven't been proven at scale outside software engineering.
All sources accessed June 2026.
Research Papers & Preprints
Engineering Blogs & Articles
Loop Engineering Guides
GitHub Repos & Awesome-Lists
Discussions & Community
Additional Sources Referenced by the Above
What we already do right: The Atto Corp harness (agent.py) already implements several patterns from the literature — tool calling with sandboxed execution, message persistence, context window management via STASH_MESSAGES, heartbeat triggers, background tool execution, and a formal life/logging mechanism. The agent-in-subconscious pattern mirrors the two-agent harness architecture from Anthropic.
What to explore next:
Verdict: Harness engineering and loop engineering are real, rapidly maturing disciplines. The literature is concentrated (mid-2026 is a peak), high-quality (Anthropic, OpenAI, and arXiv papers are primary sources), and immediately applicable. The convergence thesis — harness = loop — is worth betting on. For Atto Corp, the highest-leverage next step is implementing formalised handoffs and verification gates, which would bring our agent infrastructure in line with the documented best practices from the major labs.