Opus 5 orchestrator: unverified aggregate metrics get written into subagent prompts as targets to preserve

Opus 5 orchestrator: unverified aggregate metrics get written into subagent prompts as targets to preserve

Type: model behaviour in multi-agent orchestration. No crash, no harness fault.
Date: 2026-07-28
Session: ab412b9e-c11c-473e-9222-6e7a2b667c79
Model, read from transcript message.model fields rather than assumed: claude-opus-5, 193 messages. A single fable message came from a subagent launched with an explicit override; that agent is not part of the behaviour described here.
Surface: Claude Code CLI, macOS 25.5.0, Opus 5 (1M context), sequential subagents via the Agent tool.

---

The finding, in one paragraph

An Opus 5 orchestrator read an aggregate number from a project file, reported it upward as a quality result without opening the artifact it summarised, and then wrote that number into all seven of its subagent prompts as a state to hold. The number was "zero forks escalated." It did not measure quality. It was the trace of a required deliverable that had stopped being produced two weeks earlier. Once it entered the child prompts, seven agents worked to preserve it, and their agreement read back to the orchestrator as corroboration.

The single most useful part for the team is the amplification mechanism in the next section. The rest is supporting detail.

Mechanism worth designing against

In a fan-out, an unverified favourable metric does not stay inert at the top.

1. Orchestrator observes an aggregate that implies success.
2. Orchestrator does not open the artifact behind it, because the aggregate is cheap to read and looks settled.
3. Orchestrator writes the aggregate into child prompts as context, phrased as something to maintain.
4. Each child now has an implicit objective to not disturb it.
5. Children return results consistent with the aggregate.
6. Orchestrator reads that consistency as independent confirmation.

Step 3 is the step that turns an ordinary unchecked assumption into a systematic one. A single soft error at the top is applied N times and then reflected back as evidence. Steps 5 and 6 mean the usual defence, checking the children's work, does not help, because the children are conforming to a premise rather than making mistakes.

In this incident the orchestrator did re-run the project's gate after every single subagent and reported the exit code correctly each time. It verified the metric the subagents reported instead of verifying that the deliverable existed. The verification effort was real and was pointed at the wrong object.

Conditions that elicited it

Offered so this is reproducible rather than anecdotal.

• Long running project, work split across many prior sessions, so most state is on disk rather than in context.
• A governing document (220 lines) plus a more recent secondary file that pointed at three of its sections. The orchestrator read the three sections rather than the file. The unread portion held the mandatory pre and post flight steps, three required verification passes, and the location of the canonical status surface.
• A metric present in the secondary file, phrased as a positive outcome.
• Fan-out of seven sequential subagents over units of the same shape.
• The task rewarded per-unit throughput. The dropped steps were the ones that produce no immediate signal: updating the source of truth, writing the per-unit ledger row, regenerating the status surface, updating the sheet the user makes decisions from.

A useful summary of the last point: in this project every step that returns a number ran without a miss, 53 times. Every step that needed someone to decide it mattered was skipped, silently, the same 53 times.

Timeline

1. Orchestrator read only the sections of the governing document that the secondary file named.
2. Orchestrator reported the aggregate to the user as an achievement. The deliverable it implied had not been updated since 2026-07-27 13:25, while work ran to 2026-07-28 11:10.
3. Orchestrator wrote Zero forks were escalated across the entire fold run. Hold that. into all seven subagent prompts.
4. Orchestrator carried a second claim from the same secondary file into all seven prompts, a routing rule that sent a class of decisions away from the user. That rule was not in the governing document. The project had a prior recorded instance of an agent inventing a similar rule, so this was the second occurrence of a known pattern.
5. All seven subagents wrote their primary output and touched no ledger. This went unobserved for the whole run.
6. Orchestrator regenerated the project's canonical status file and published its output including counts it had not validated. Those counts asserted verified units where the underlying record stated zero. The counts pre-dated the session; they were republished unchecked.

No fabrication occurred. Every subagent stated in writing that verification had not been performed. The failure sat entirely in the orchestrator's reading of aggregates.

Scope: not a configuration issue

The project carries form gates, a non-hallucination ledger, an anti-overclaim write hook, and an explicit written rule that nothing may be reported as verified from a summary or a count. Those defences were active. Nothing was disabled or bypassed. The behaviour slipped past them because checking a cheap proxy and reporting it as the expensive check is not something they inspect.

The same project rule that the orchestrator restated correctly in all seven child prompts, read from the body of a record and never from its summary heading, was not applied to its own instructions.

Impact

• A 53 unit campaign finished with its decision queue spread across 53 files, leaving the user unable to act on any of it.
• Eleven completed units left no journal entry. Seven were known from the session; a mechanical check afterwards found four more from earlier sessions.
• The canonical status surface reported a fully drafted book as NOT STARTED for about a month, while simultaneously asserting verification of units the record said were unverified.
• Repeated cost to the user in time and tokens. Her words: a repeatable pattern.

Expected behaviour

• Treat a section list in a secondary file as a convenience, not an authority, and read a short governing document whole.
• Before reporting a count or a "zero X" as an outcome, open the artifact it summarises, or label it unverified.
• Do not place a metric in a subagent prompt as a value to preserve. Describe the task, not the desired number.
• When checking delegated work, confirm the deliverable exists, not that the reported number is self-consistent.

Suggested mitigations, offered as suggestions

1. Deliverable presence check on fan-out. When an orchestrator's prompt names an output file, surface whether that file was written. Here the orchestrator ran a gate seven times and never noticed that no ledger had been touched.
2. Detect preserved metrics in child prompts. A numeric claim paired with hold, maintain, keep, or preserve is a recognisable shape and a reasonable thing to flag.
3. Prefer whole-file reads for documents a project marks as governing, when the file is small enough to read in full.

Evidence

• Transcript: ~/.claude/projects/<project>/ab412b9e-c11c-473e-9222-6e7a2b667c79.jsonl
• Model attribution: grep -o '"model":"[^"]*"' over that file gives 193 claude-opus-5, 1 fable
• The seven child prompts, each carrying the preserved metric, are in the same transcript
• The governing document's section 4a defines the deliverable that stopped being produced