This article may contain affiliate links. We may earn a small commission at no extra cost to you if you make a purchase through these links.
Mid-Conversation Effort: Claude's Orchestration Pattern
Claude Opus 4.8 can change an agent's effort mid-task and grant standing consent to fan out. Here's the pattern that makes it work.

Claude Opus 4.8 shipped something subtle but consequential for anyone building agents: the ability to change a model's reasoning effort partway through a conversation, and to hand that model standing permission to spawn its own sub-agents. Anthropic's published orchestration mode example assembles the pattern in full — and it reframes the question every agent builder is wrestling with in 2026.
That question is no longer how capable is the model. It is how much should the model decide for itself, and how do you keep it honest when it does? The orchestration example answers both with three documented API behaviors and one disciplined habit: adversarial verification. None of it is magic. All of it is reproducible. And taken together, it is a cleaner blueprint for production multi-agent systems than most teams are running today.
What does "mid-conversation effort" actually change?
Effort is Claude's reasoning-depth dial. As of June 2026, the documented effort levels are low, medium, high (the default), xhigh, and max, set through the output_config parameter. Anthropic's guidance is direct: start at xhigh for coding and agentic work, use high for most other intelligence-sensitive workloads, and step down only after your evals prove the cheaper level holds quality.
The new capability is mid-conversation control. A harness can now update Claude's instructions partway through a task — adjusting permissions, token budgets, or environment context — without breaking the prompt cache and without routing the change through a fake user turn. The top-level system field never changes, so the cached prefix stays intact; the update arrives as a system message inside the messages array instead. This matters more than it sounds. Long-running agents accumulate context, and the old workaround — editing the system prompt — silently invalidated the cache and re-billed the entire prefix on every change.
| Effort level | Best for | Relative token spend |
|---|---|---|
low | Cheap, mechanical, latency-sensitive calls | Lowest |
medium | Routine workloads where evals confirm quality holds | Low |
high (default) | Most intelligence-sensitive tasks | Moderate |
xhigh | Coding, long-horizon agentic work, async workflows | High |
max | The hardest single problems where cost is no object | Highest |
Anthropic exposes the same machinery inside Claude Code as "ultracode" — a mode that pairs the xhigh effort level with standing permission for the agent to launch multi-agent workflows, granted through exactly these mid-conversation system messages. The orchestration example is the documented, build-it-yourself version of that idea.
How orchestration mode is built from three documented pieces
The example calls "orchestration mode" a session-level switch that grants the model standing consent to fan out. When it is on, the model runs multi-agent workflows for every substantive task without asking first. When it is off, it reverts to per-request opt-in. Critically, the switch is not a hidden model setting — it is composed from three pieces a developer can read and reproduce:
- An effort level. The example pins both the main loop and its sub-agents to
xhigh. There are no undocumented levels above the published ones. - Mid-conversation system messages. A system message announces the mode — a full explanation when it turns on, a one-line refresher every ten turns, an exit notice when it turns off. The top-level
systemfield never moves, preserving the cache. - Standing consent written into a tool description. The Workflow tool's own description tells the model that while the mode is active, it should author and run workflows without pausing to ask. Consent lives in the tool contract, not in hidden behavior.
That third piece is the quiet design lesson. Instead of burying "act autonomously" in a model fine-tune or an opaque flag, the behavior is declared in plain text the model reads at call time — and that a human auditor can read too. It is the same philosophy behind open agent protocols: make the contract explicit. We covered why that explicitness is becoming a competitive battleground in the AI agent protocol war, and orchestration mode is a small, self-contained proof of the principle.
Each sub-agent the Workflow tool spawns is deliberately spartan. It receives a sandboxed shell tool and a single report_findings tool that forces structured output instead of prose. Findings come back as JSON — a one-sentence claim, the evidence that verified it (a file, a line, a command's output), and a severity of high, medium, low, or info. The system prompt pushes each sub-agent to investigate rather than narrate. The orchestrator gets data, not essays.
Why the verification wave is the real innovation
Fanning out parallel agents is not new. The orchestration example's most transferable idea is what happens after the first wave returns: a second wave of agents whose only job is to try to refute the first wave's claims. Verifiers re-derive each claim from the source, and — this is the important bit — they default to "refuted" when uncertain. The output is a verdict, "confirmed: <why>" or "refuted: <why>," and both the original result and the verdict go back to the orchestrator.
This inverts the usual failure mode of multi-agent systems. A single confident agent that hallucinates a finding has no adversary; its mistake becomes the answer. Recent 2026 research has converged on the same conclusion from the safety angle — papers like "Verified Multi-Agent Orchestration" formalize a plan-execute-verify-replan loop precisely because compromised or simply wrong sub-agents can corrupt a collective answer. The orchestration example bakes the verify step into the default rather than treating it as an optional add-on.
Two more habits in the example are worth stealing. A "completeness critic" runs a final agent whose entire prompt is to hunt for what the others missed. And multi-phase work is sequenced as separate Workflow calls — understand, then design, then implement, then review — rather than one sprawling fan-out. If you have ever tried to coordinate agents by hand, you already know why this beats a single monolithic dispatch. For a fuller map of when each topology fits, our decision-tree guide to agentic design patterns walks through the trade-offs.
When does self-orchestration actually pay off?
Standing consent to fan out is powerful and expensive. A single request can spawn dozens of sub-agent conversations, each consuming its own token budget. The example acknowledges this bluntly and caps it: in the documented harness, concurrency is limited to ten simultaneous sub-agents, total sub-tasks per call top out at 200, and individual sub-agents and the main loop have turn ceilings. Those are example guardrails, not API limits — but the instinct to bound the blast radius is the right one.
The economics are not subtle. One 2026 analysis of production deployments found that independent multi-agent setups carry roughly 58% extra token overhead versus a single agent, and heavily centralized orchestration can run closer to 285% extra. The same survey pegged the orchestrator-worker topology — one coordinator dispatching specialized workers — at about 70% of production multi-agent systems. The takeaway is consistent across the research: multi-agent fan-out earns its cost only when the task genuinely benefits from parallelism, specialization, or critique. For everything else, it is a tax.
So the honest decision rule is narrow. Reach for self-orchestration on exhaustive audits, multi-component reviews, and research syntheses where being thorough and correct matters more than being fast or cheap. Keep it off for conversational turns and trivial mechanical edits. The mid-conversation switch exists precisely so you can toggle that posture inside a single session instead of committing to one mode for the whole conversation — a flexibility that pairs naturally with the large working sets we discussed in Claude's 1M-token context window.
How do you keep a fan-out resumable?
Long fan-outs fail. A network blip, a rate limit, or a manual interrupt can kill a run that has already spent real money on completed sub-tasks. The example's answer is a content-addressed journal: before dispatching a sub-agent, the orchestrator hashes the sub-task prompt with SHA-256 and checks a journal file for a cached result. Re-runs recompute only the uncached sub-tasks; deleting the journal starts fresh.
This makes fan-outs idempotent, which is the property that turns a fragile demo into something you can run in production. It also makes cost predictable — you never pay twice for the same sub-task. The pattern is simple enough to port to any agent framework, and it is the kind of unglamorous engineering that separates a reliable system from an impressive one.
What builders should do now
- Set effort deliberately, not by default. Start agentic and coding workloads at
xhigh, then use your evals to justify stepping down. Don't leave it implicit. - Move dynamic instructions out of the system prompt. If your harness changes permissions or budgets mid-task, use mid-conversation system messages so you stop re-billing the cached prefix on every update.
- Put consent in the tool contract. Declare autonomous behavior in tool descriptions the model reads at call time — auditable text beats hidden flags.
- Make verification the default, not an option. Add a refute-first second wave to any fan-out whose findings you intend to act on. Default verifiers to "refuted" under uncertainty.
- Bound the blast radius and journal the run. Cap concurrency and total sub-tasks, and hash-key a journal so interrupts cost you nothing on re-run.
The bottom line
Mid-conversation effort steering is a small API change with an outsized design consequence: it lets an agent adjust its own reasoning and authority inside a live task, cache intact. Anthropic's orchestration example shows the responsible way to use that power — standing consent declared in plain text, parallel work bounded by hard caps, every finding checked by an adversary, and the whole run made resumable by a hash-keyed journal. As of June 2026, the headline feature is only available on Claude Opus 4.8. But the pattern is model-agnostic, and it is the one worth copying.
Frequently asked questions
What is mid-conversation effort steering in Claude?
It is the ability to change Claude's reasoning effort level — and other instructions like permissions or token budgets — partway through a conversation, delivered as a system message inside the messages array. Because the top-level system field stays unchanged, the prompt cache is preserved and the cached prefix is not re-billed. As of June 2026 it is documented on Claude Opus 4.8.
What are the Claude effort levels?
The documented levels are low, medium, high (the default), xhigh, and max, set via the output_config parameter. Anthropic recommends starting at xhigh for coding and long-horizon agentic tasks, using high for most other work, and dropping to medium or low only after evaluations confirm the lower level maintains output quality on your workload.
Is orchestration mode a hidden Claude setting?
No. The published example builds it entirely from three documented pieces: an effort level pinned to xhigh, mid-conversation system messages that announce the mode, and standing consent written into the Workflow tool's description. There are no undocumented effort levels and no hidden autonomy flag — the behavior is reproducible and auditable.
When is multi-agent fan-out worth the token cost?
Only when a task genuinely benefits from parallelism, specialization, or critique — exhaustive audits, multi-component reviews, and research synthesis. One 2026 analysis found independent multi-agent setups add roughly 58% token overhead and centralized ones up to 285%. For conversational turns and simple edits, a single agent is cheaper and just as good.
How does adversarial verification reduce agent errors?
After a first wave of agents produces findings, a second wave attempts to refute each one by re-deriving the claim from the source, defaulting to "refuted" when uncertain. Both the original finding and the verdict reach the orchestrator. This gives every confident-but-wrong result an adversary, catching hallucinations that an unchecked single agent would pass through as fact.
Enjoying this article?
Get more strategic intelligence delivered to your inbox weekly.
Enjoyed this article?
VentureBeast.Tech is independent and reader-supported. If this saved you time, you can buy us a coffee — it keeps the research deep and the site ad-light.
Support us on Ko-fi


Comments (0)
No comments yet. Be the first to share your thoughts!