Executive summary
Mode 2, the agentic-loop operating model defined in Part 1, hands an agent the plan-build-verify cycle and asks humans to steer at the boundary instead of inside the steps. The production form is bounded autonomy: the agent works unsupervised while humans hold the edges, and the playbook is mostly those edges. Three pieces make it run. The cage comes first: action tiers that send reversible work to the agent and irreversible work to a human gate, enforced by sandboxes, deterministic verifiers, and audit trails. The pattern comes second: four orchestration shapes, each fitted to a kind of work. The meter comes third: agentic loops burn tokens at multiples of chat, and how to bill that consumption is unsettled enough that Anthropic paused its own June 15 repricing. Beneath all three sits the platform, where standardization more than size decides whether the loop is safe to close.
Conditions before engagement
The warp drive covers distance the impulse engine cannot, and it engages only when the conditions allow: a charted heading, a clear field, and a helm that can drop out of warp on command. The engine matters less than the conditions that justify using it. Mode 2 inverts the intuition most teams bring to it. The agent running unattended is the easy part, and the work that makes it safe to run happens before the loop ever starts. 🖖
The loop must be caged
Part 2 ended where the human leaves the loop. Bounded autonomy fills the space the human vacated, and the work of building it is mechanical. The delegation gap that Part 1 quantified becomes the design problem here: an agent trusted with too much fails at machine speed, and an agent trusted with too little is a slower assistant. The fix is to grade actions by reversibility instead of difficulty.
PCAS frames the grading as three action tiers. Always-safe actions read state, run in sandboxes, and write only to disposable branches; the agent performs them without asking. Conditionally-safe actions write to shared state behind a deterministic verifier, a test suite or a type checker or a schema diff, plus an audit trail that records what changed and why; the agent proceeds, and the record keeps it reviewable. Approval-required actions are the irreversible ones: production deploys, schema migrations, data deletion, outbound calls with side effects. Those stop at a human gate regardless of the agent’s confidence.
Spotify’s background agent shows the discipline in production. By design it can see the relevant codebase, edit files, and run verifiers as tools, and nothing more: no external context, no open-ended tool access. The narrow surface is the safety property. Mode 2 is not the absence of control. It is control relocated from the steps to the boundary, and the agent earns its freedom inside the cage because the cage gets built first.
Four patterns, not one
“Agentic” labels a category, not a shape, and four orchestration patterns recur across the confirmed production cases. Each calls for different infrastructure.
Background batch runs one well-scoped change across many repositories on a schedule, with a human orchestrating targets and the agent doing the edits. Spotify’s split between its Fleetshift orchestration layer and its Honk agent is the working example: the orchestration picks targets and tracks progress while the agent makes each change. The pattern holds only where build-time tests exist to verify every result.
Long-horizon single session points one agent at one hard problem for hours inside a mature codebase. Rakuten’s vLLM work is the case in point, and the precondition is the codebase, not the model: strong conventions and comprehensive tests gave the agent references it could check itself against across a long run.
Multi-agent orchestration splits a large job across subagents that fan out, reduce, and synthesize under a supervisor. The Bun runtime’s Zig-to-Rust port ran this way, and its status carries the lesson: the rewrite merged but ships canary-only while cleanup lands. The orchestration moved the work; verification still decides when it counts. Claude Code’s dynamic workflows, released with Opus 4.8 in May, productized the same shape, with the supervisor as the 2026 default.
Fleet automation is background batch’s standing form: continuous, policy-driven maintenance across an estate instead of a one-off campaign. Most enterprises meet it first, because dependency bumps and config migrations are where the verification is already mechanical. The planning move across all four is to inventory work by pattern, since one repository can host several at once and each pattern carries its own verification and cost profile.
Warp fuel is metered
Mode 2’s economics overturn Mode 1’s predictability. An agentic loop re-sends its accumulated context on every tool call, so token use runs 5 to 30 times a comparable chat exchange, and a single complex task can push 400,000 to 2 million cumulative input tokens. Pilots routinely surface multiples above the budget, because the loop iterates as far as the task resists. The metered pricing covered in Part 1 has proved hard to land. Anthropic announced a separate Agent SDK credit billed at full API rates, then paused the change on June 15, the day it was to take effect: the third programmatic-usage move it has pulled back since January. The meter keeps getting built and withdrawn, and that whiplash is the signal that agentic-loop consumption is large and unpredictable enough to resist clean pricing. The token reality below does not wait for the billing model to settle.
Cost governance is therefore a FinOps discipline, and three controls hold the bill. Per-task budgets cap the tokens a single loop may spend before it halts for review. Kill switches stop a runaway session the verifier cannot bound. Effort controls, exposed directly in Opus 4.8, tune how deeply the model reasons per call, trading tokens for thoroughness at the same per-token rate. The caution lives in the orchestration: dynamic workflows are deliberately token-intensive, and Anthropic’s own evaluation recorded roughly three times the baseline consumption for a comparable task. Multi-agent throughput is real, and so is its meter.
Foundation, not codebase age
The flagship cases share a trait that is easy to misread as scale. Rakuten’s target ran to millions of lines, yet the property that mattered was structure: conventions an agent could follow and tests it could trust. The counter-example comes from Spotify, which kept one class of data pipeline on manual work because it lacked standardization and the agent could not pull the external context each variant needed. Same company, same agent, and the unstandardized corner stayed human.
| Estate property | Mode 2 readiness |
|---|---|
| Structural standardization | ● |
| Test coverage an agent can run | ● |
| Component catalog and conventions | ◕ |
| Observability and audit trail | ◕ |
| Raw codebase size | ○ |
| Codebase age | ○ |
The grid is the section’s argument: the properties at the top decide whether the loop closes safely, and the two at the bottom barely register. A large, standardized estate is readier for Mode 2 than a small, idiosyncratic one. The build-versus-maintain contrast from Part 2 carries through with higher variance, because an unattended loop does not slow down on weak foundations, it fails on them unsupervised. Mode 1’s hybrid stack extends here too, as human-owned evaluation becomes the control system the loop reports into.
Where the playbook ends
One sentence carries the discipline: the agent runs, the harness verifies, the spec defines done, and the platform makes all three repeatable. Both playbooks now exist, which leaves the question that opens Part 4, the selection framework: which mode does any given piece of work actually deserve?