Summary

Even with the SILENT guard in place (issue #N — Branch 2 parity), duplicate user messages still happen because the announce flow trusts the LLM to self-detect prior delivery. A structural short-circuit is the proper fix: the runtime should detect already-delivered results from observable transcript state and skip the announce entirely.

Problem

The subagent-announce flow currently fires the completion-delivery prompt regardless of what the parent agent has already said in its session. The only suppression mechanism is the SILENT_REPLY_TOKEN, which depends on the LLM noticing it just answered the same question. This is unreliable across:

• Long contexts (the prior assistant message may be far back in the window)
• Compactions (the prior message may have been summarised away)
• Stylistic differences (the LLM may not recognise its own paraphrase as "the same")

Proposed fix — runtime-side dedup

In subagent-announce-4mg0K78I.js, inside runSubagentAnnounceFlow, before buildAnnounceSteerMessage:

const recentAssistant = await getMostRecentAssistantMessage(targetRequesterSessionKey);
if (
  recentAssistant &&
  params.endedAt &&
  recentAssistant.ts >= params.endedAt &&
  fingerprintMatches(recentAssistant.text, findings)
) {
  // Parent already delivered after the child finished. No announce needed.
  return true;  // treat as delivered, allow cleanup, exit silently
}

fingerprintMatches design

Conservative match. Both strings normalised to lowercase + collapsed whitespace. Match if any of:

• A contiguous 60+ character window of findings appears in assistant.text, OR
• A contiguous 60+ character window of assistant.text appears in findings, OR
• (Optional, lower priority) Cosine similarity of trigram-shingled vectors > 0.7

The 60-char window threshold is empirical — long enough to avoid trivial coincidence (URLs, common phrases), short enough to catch paraphrase. False positives (skip when not actually duplicate) are far worse than false negatives (announce when parent already covered it), so err toward announcing.

Why it's safe

• The parent session jsonl is already accessible to the runtime; reading the last assistant message is cheap.
• If the parent did NOT cover the substance, fingerprint won't match → flow proceeds normally.
• If the runtime can't read the parent transcript (race, missing file, etc.), fail-open to current behaviour.

Why the SILENT-token-only fix is not enough

We applied per-AGENTS.md "Duplicate Detection Discipline" prose plus the Branch 2 SILENT guard upstream. Both help. Neither eliminates the failure mode because:

1. After compaction, the LLM's "most recent assistant message" view may be the summary, not the actual delivered text.
2. LLMs paraphrase. Self-recognition of prior delivery is unreliable across stylistic variation.
3. Multi-step orchestration (parent waits on grandchild → delivers progress → waits again → child finally completes) creates ambiguous "did I already cover this" cases the LLM gets wrong ~10% of the time, and 10% of completion events is a lot of duplicates in production.

The runtime can do this reliably. The LLM cannot.

Effort

~30 lines core + ~50 lines tests. New helper fingerprintMatches should live near the existing announce utilities; getMostRecentAssistantMessage likely already exists or is one wrapper away from existing transcript-read helpers.

Acceptance test

1. Spawn a child that produces output X.
2. While child is running, parent agent sends a user-facing message containing X verbatim.
3. Child completes.
4. Expected: announce flow detects fingerprint match, exits silently. Parent does NOT receive the "deliver result" prompt.
5. Negative test: parent sends an unrelated message, child completes — announce fires normally.

Context

Companion to the SILENT-guard parity issue. Both should land; this one is the actual structural fix.