Research report, v1, issued 3 August 2026. Written for engineers building agent workflows. The report has 21 sources, cited inline.
What agentic engineering actually runs on in 2026 is not a smarter prompt. It is a loop with a stopping condition, a graph of agents with isolated context, and enough trace data to know which part of the system worked. This report covers ten findings on agent loops, subagent graphs and the cost of both, each traced to a source and marked where the evidence runs thin.
The agent loop is the whole machine
Every agentic system in production reduces to one cycle. The model receives a prompt together with its system prompt, tool definitions and conversation history, calls a tool, reads the result, and repeats until it judges the task complete. [2] What gives the loop its power is that tool results become context: a bash command, a test run or a web fetch writes fresh evidence into the next iteration, so the model reasons about the state of the world rather than its memory of the world. [1]
| Stage |
Role in the loop |
| Prompt |
Goal, constraints, system prompt, tool definitions and conversation history |
| Inference |
The model decides the next action |
| Tool call |
Bash, tests, search, file read or another external action |
| New context |
The tool result becomes evidence for the next iteration |
| Done? |
The loop continues until a stop condition holds |
The loop also carries the limits that everything above it exists to fix. In a single growing context the model runs its tool calls in sequence when two searches could run at once, has no way to express "try A or B, whichever works", and holds its dependencies implicitly, so a long window raises the odds it forgets that an analysis needed both files. [20]
Goal loops decide when to stop
A goal loop wraps the agent loop and asks whether the task is genuinely finished. The Ralph loop, published by Geoffrey Huntley in July 2025, is the plainest version: re-run a single agent with a fresh context each iteration and track progress in files and git. [9, 19] Agents ran for hours without the output getting worse, because the window never filled with stale reasoning and dead ends. [19]
Premature termination is the failure this addresses, and it is well documented: the agent declares done having checked half the codebase. The reliable fix is a hard condition, zero test failures or zero lint errors, or a second agent that reviews the first one's work, rather than a soft judgement. [18] Frontier models need less nudging than they did, and the harnesses now ship the scaffolding anyway: Claude Code added /loop and cron scheduling, Codex added an Automations tab with recurring schedules. [18]
One prompt now spawns a graph
February 2026 was the step change: every major coding tool shipped multi-agent support inside the same two-week window. [13] With dynamic workflows, generally available in Claude Code from 8 June 2026, a single request can fan out across dozens or hundreds of subagents, each making its own model calls and tool calls. [10] The unit of interaction is no longer a turn in a conversation. It is a graph you are implicitly designing every time you write a prompt.
| Graph element |
What it does |
| Orchestrator |
Receives the original goal and coordinates work |
| Subagent |
Starts with fresh context and runs its own loop |
| Summary |
Returns about 1,000 to 2,000 tokens to the parent |
| Parent context |
Stays cleaner because detailed exploration remains isolated |
Each subagent starts a fresh conversation. It loads its own system prompt and project context but sees none of the parent's turns, and only its final response returns to the parent as a tool result. [2] That is what makes depth worth more than width: rather than one orchestrator spawning six workers and fragmenting its own context, spawn two feature leads that each spawn their own specialists. The parent talks to two agents and never sees the detail. [15]
The graph is programmed in plain English
None of this requires orchestration code. Agent Teams runs behind an environment variable, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS set to 1 on Claude Code v2.1.32 or later, after which you describe the team you want in natural language: three teammates refactoring these modules in parallel, or a reviewer that batches finished work. [14] Be prescriptive about the roles. Left open-ended, the harness will spawn eight teammates where three would do. [13]
Autoresearch loops optimise a number, unattended
The strongest public evidence for loop engineering comes from the pattern with the tightest feedback: propose a change, measure it, keep it if the number improved, revert it if not, repeat. Andrej Karpathy's autoresearch script established the shape. In his own run, roughly 700 experiments over two days found 20 stackable improvements that cut GPT-2 training time by 11%. [8]
Shopify's Tobi Lutke pointed the same pattern at Liquid, the 20-year-old Ruby template engine behind every Shopify storefront. Around 120 experiments produced 93 surviving commits: combined parse and render time fell from 7,469 to 3,534 microseconds, and object allocations from 62,620 to 24,530, which matters because garbage collection accounted for 74% of CPU time. [5] The enabling condition was not the model. It was 974 existing unit tests plus a benchmark script, which together turn "make it faster" into an actionable goal. [4]
The pattern generalises past code. Optimal Intellect ran autonomous agents on six Macs over a single weekend to optimise DistilBERT inference on Apple's Neural Engine, beating Apple's own CoreML path on every chip tested, from 1.14x on an M4 to 6.31x on an M4 Max. The winning insight came from shared memory across the swarm rather than from more experiments in isolation: one agent's dead end became another's breakthrough. [7] Scaling is mechanical rather than clever. The SkyPilot team parallelised autoresearch across 13 H100s and 3 H200s and ran about 910 experiments in eight hours, 9x the throughput of a single sequential GPU run, for roughly $300. [8]
The loop optimises exactly what you measure, which is the caveat and the mechanism at once. Lutke called his own result "probably somewhat overfit", and as of May 2026 the pull request was still unmerged, with an independent review calling the code quality poor. [6] A study of 403 AI agent commits presented at MSR 2026 found the Maintainability Index fell in 56.1% of cases and cyclomatic complexity rose in 42.7%. [6] Gate on wall-clock time with a passing test suite, which is close to ground truth, rather than on a benchmark score a change can overfit.
Subagents exist because context degrades
As a loop runs, its window fills, and the model gets worse. Anthropic describes the effect directly: despite handling larger and larger volumes of data, models lose focus or become confused past a certain point, and needle-in-a-haystack benchmarking has given the phenomenon a name, context rot, where recall accuracy falls as token count rises. [1] Quality degradation is not only about total length. Older context loses weight and earlier instructions get deprioritised, so the instruction you gave at the start is the one most likely to be dropped. [11]
A subagent is the cheapest available fix, because it buys back attention. Each one may explore with tens of thousands of tokens and return only a distilled summary of 1,000 to 2,000 tokens, keeping the detailed search context isolated while the lead agent synthesises. [1] Chained stages get the same benefit: a research subagent that has read fifty paper summaries does not pollute the planning subagent that follows, and the boundary between stages is a natural place to insert verification. [21]
Fresh context is what you pay for
The isolation that keeps subagents sharp is the same property that makes them expensive. Parallel agents cannot share a window, so each one re-establishes its own baseline: system prompt, project context files, and whatever it must read to start work. Anthropic notes that agent teams can consume around 7x the tokens of a standard session when teammates operate in plan mode. [10] Operator reports put three subagents on one task at roughly four times the spend of a single-thread session, and subagent-heavy sessions at up to 85% of a token bill. [12]
| Session pattern |
Relative token consumption |
| Standard chat turn |
Baseline |
| Single agent loop |
About 4x |
| Agent teams, plan mode |
About 7x |
| Multi-agent system |
About 15x |
Token consumption is relative to a standard chat turn. Single-agent and multi-agent multipliers come from Data Science Dojo, June 2026; the agent-teams figure is Anthropic's, for plan mode. [9, 10]
Two consequences follow for anyone on a subscription plan rather than the API. Loops make 10x to 100x more API calls than a chatbot, so failover and rate limits become design concerns rather than operational details. [18] And running large parallel fleets is genuinely costly: the engineers who pioneered these workflows report monthly token bills into seven figures. [9]
Clearing context on purpose is a performance lever
Automatic compaction is a safety net, not a strategy. Reports put the autocompact trigger at around 187,000 tokens, submitting the whole bloated context for summarisation at a cost of 100,000 to 200,000 tokens per compaction and up to three times in a turn; on a million-token Opus window it has been observed firing at 76,000 tokens. [11] In long sessions with retries, a single prompt can burn 50,000 to 300,000 tokens, which is the mechanism behind users reporting one prompt eating 30% to 90% of a five-hour budget. [11]
Clearing at a task boundary, once progress is written to files and git, avoids paying that toll and starts the next task with the attention profile of a fresh session. Session cost totals reset when /clear starts a new session, so the accounting matches the mental model. [3] For scale, Anthropic's own enterprise figures average about $13 per developer per active day and $150 to $250 per month, with 90% of users under $30 per active day, so the outliers are behavioural rather than structural. [3]
Mix models inside one graph
Planning and execution have different value per token, so price them differently. Put the plan on a frontier model and the execution on cheaper workers. With Haiku roughly 5x cheaper than Opus, three Haiku workers running in parallel finish three tasks for about $0.135, still less than the $0.225 of one serial Opus call for one task: about 2x billable work per dollar. [12] Audit CLAUDE_CODE_SUBAGENT_MODEL first, because that one variable silently overrides the routing you just designed. [12]
Cross-vendor mixing is now normal rather than exotic: shipping orchestration surfaces drive Gemini 3.1 Pro and Claude Opus 4.6 from the same control centre, and practitioners run Claude Code, Codex CLI and Gemini CLI side by side on isolated branches, each on the model that suits the work. [13] Parallel writes to one repo collide, so isolation is part of the design: a git worktree gives each agent its own checkout sharing one .git directory, and Claude Code supports it natively through isolation: "worktree" in a subagent definition. [19]
One billing detail decides where a graph should run. Managed agent sessions run on the vendor's infrastructure and can grind through hours of tool calls while your app streams events, but they bill as pay-as-you-go API tokens rather than against a Pro or Max plan, which stays materially more price-efficient for personal use. [19] Run your own repo work locally with worktrees, and reserve managed sessions for graphs that have to outlive your terminal.
Traces make the bottleneck visible
A graph you cannot see is a graph you cannot tune. An execution trace is the time-ordered record of what every agent and tool call did, and the instrumentation is already in the harness: SessionStart, SubagentStart, SubagentStop, PreToolUse and PostToolUse hooks stream into local dashboards that draw execution trees, token burn charts and error replay, with each subagent shown as a node and every tool invocation as a child. [16] Managed sessions expose the same thing server-side through a console timeline and raw event API. [2]
Mining history rather than watching live is where the redesign decisions come from. CASS indexes local session history across eleven or more agents, Claude Code, Codex, Cursor, Aider and Gemini among them, and its analytics subsystem reports token usage and tool usage per agent over a window. [17] Read its coverage flags before quoting a number: api_token_coverage_pct tells you how much came from real API accounting, and estimate_only_pct how much is a characters-divided-by-four estimate. [17] Per-model attribution matters too, so an Opus orchestrator driving Sonnet subagents is costed at each model's own rate instead of a blended average. [18a]
Terms used in this report
| Term |
What it means here |
| Agent loop |
Prompt, inference, tool call, new context, repeat until a stop condition holds. |
| Goal loop |
A verification wrapper that decides whether the task is done. Ralph loop is the canonical case. |
| Autoresearch |
A goal loop aimed at a number: change, benchmark, keep or revert, unattended. |
| Subagent |
A child agent with a fresh window that returns only a summary to its parent. |
| Context rot |
Falling recall as a window fills, measured in needle-in-a-haystack tests. |
| Execution trace |
A time-ordered graph of agents and tool calls in one session. |
What to do on Monday
- Put a hard stopping condition on every loop: zero failing tests or zero lint errors, never the model's own judgement.
- Before spawning subagents, ask whether the task fits one window. If it does, parallelism only costs money.
- Prefer depth over width: leads that spawn their own specialists keep the orchestrator's context clean.
- Give autoresearch a benchmark script, a fast test suite and a metric close to wall-clock time.
- Review agent-optimised diffs for maintainability, not only the metric that moved.
- Clear context at task boundaries once state is on disk, rather than waiting for automatic compaction.
- Route the plan to the frontier model and execution to cheaper ones, then audit
CLAUDE_CODE_SUBAGENT_MODEL.
- Describe teams prescriptively: name the roles and the batch size, or you will get more teammates than you need.
- Turn on session hooks now, and check an analytics tool's token-coverage flags before quoting its totals.
Where the evidence is thin
Three sets of figures here rest on operator reports rather than published measurement: the token multipliers for single and multi-agent sessions, the autocompact thresholds, and the share of a bill attributed to subagents. They agree across independent write-ups and with vendor guidance, but no controlled study confirms them. The autoresearch results are public and reproducible in outline, though the Shopify pull request remained unmerged months after the benchmark was quoted. Treat the numbers in sections 7 and 8 as planning figures and measure your own with a trace.
Sources
Vendor documentation and peer-reviewed work carry the load here. Practitioner posts and aggregator write-ups are marked as such, and their figures are reported as claims rather than measurements. Where two sources disagreed, both readings appear in the body: the 53% Liquid result and the independent critique of it are the clearest example. All sources were retrieved on 3 August 2026.
| # |
Source |
| 1 |
Effective context engineering for AI agents, Anthropic Engineering, anthropic.com/engineering/effective-context-engineering-for-ai-agents |
| 2 |
How the agent loop works, Claude Code docs, code.claude.com/docs/en/agent-sdk/agent-loop |
| 3 |
Manage costs effectively, Claude Code docs, code.claude.com/docs/en/costs |
| 4 |
Liquid: 53% faster parse and render, Simon Willison, 13 Mar 2026, simonwillison.net/2026/Mar/13/liquid/ |
| 5 |
Shopify CEO uses an agent on Liquid, Awesome Agents, 13 Mar 2026, updated 8 Apr 2026, awesomeagents.ai |
| 6 |
Autoresearch spreading, 53% flagged overfit, Tech Times, 19 May 2026, citing Horikawa et al., arXiv:2603.13723 (MSR 2026) |
| 7 |
6x faster inference on Apple Silicon, Ensue with Optimal Intellect, Apr 2026, ensue.dev/blog/6x-faster-inference-apple-silicon/ |
| 8 |
Karpathy autoresearch explained, Paperclipped, Mar 2026, paperclipped.de/en/blog/karpathy-autoresearch-autonomous-research/ |
| 9 |
Agentic loops: from ReAct to loop engineering, Data Science Dojo, Jun 2026, datasciencedojo.com/blog |
| 10 |
Claude Code token limits and AI coding spend, Faros AI, faros.ai/blog/claude-code-token-limits |
| 11 |
Claude Code pricing 2026, Finout, 31 May 2026, aggregating operator reports, finout.io/blog/claude-code-pricing-2026 |
| 12 |
Why Claude Code subagents burn so many tokens, youcanbuildthings, 30 May 2026, practitioner, youcanbuildthings.com |
| 13 |
AI agent orchestration and agent teams, Morph, updated Mar 2026, morphllm.com/ai-agent-orchestration |
| 14 |
Claude Code multi-agent orchestration, Tembo, Jun 2026, tembo.io/blog/claude-code-multi-agent-orchestration |
| 15 |
The code agent orchestra, Addy Osmani, Mar 2026, addyosmani.com/blog/code-agent-orchestra/ |
| 16 |
claude-session-visualizer, anaypaul, GitHub, github.com/anaypaul/claude-session-visualizer |
| 17 |
CASS: coding agent session search, v0.2.7 analytics, Dicklesworthstone, GitHub, github.com/Dicklesworthstone/coding_agent_session_search |
| 18 |
Loop engineering: agent loops that run themselves, Requesty, Jun 2026, requesty.ai/blog |
| 18a |
agent-sessions: per-model burn attribution, jazzyalex, GitHub, May 2026, github.com/jazzyalex/agent-sessions |
| 19 |
30 core agentic engineering concepts, System Design Newsletter, Jun 2026, newsletter.systemdesign.one/p/agentic-engineering |
| 20 |
From agent loops to structured graphs, arXiv:2604.11378 |
| 21 |
Glite ARF: verifier-driven parallel coding agents, arXiv:2606.27416 |
The loop is the design surface
Every result in this report came from someone shaping the loop rather than the prompt: a stopping condition, a fresh context, a metric worth optimising, a trace to read afterwards. That is the work now.
