Duplicate background-agent execution on same target (Agent tool + SendMessage resume)

Duplicate background-agent execution on same target (Agent tool + SendMessage resume)

Summary

Twice in one day, launching exactly one background subagent (via the Agent tool, run_in_background: true) to run a QA workflow against a single Jira ticket resulted in two independent agent executions against the same ticket, producing duplicate/contradictory output (duplicate Jira comments, one run submitting a real state-mutating action the other didn't know about).

Reproduction pattern (both occurrences)

1. Launch one background subagent via Agent (run_in_background: true) targeting a specific external ticket/resource.
2. The agent's first "completed" task-notification is a stall: very low tool-use count (~2 calls), short duration (~20s), and a report that only narrates/describes the intended plan rather than having executed anything (e.g. "I've launched the X agent to run the full workflow..." written in the third person, as if reporting on work about to happen).
3. Resume that same agent via SendMessage (targeting its agentId) with explicit instructions to actually execute the workflow directly.
4. The resumed agent runs a long, genuine execution pass (tens of tool calls, minutes of duration) and reports a real, complete result.
5. At some point after the resume, a second "completed" task-notification arrives under a different, never-explicitly-launched task-id. This second agent independently ran the same workflow against the same target, producing its own distinct output that collided with the first (duplicate Jira comments posted; in one case, one of the two runs submitted a real order via a live form on a shared test account).

Specific instance (this session)

• Ticket: DMS-1604 (Jira).
• First agent: launched via Agent tool → task-id a024cde9c8cd0e946. First notification: tool_uses: 2, duration_ms: 20350, narration-only result. Resumed via SendMessage to that agentId with explicit "actually execute" instructions → second notification from the same task-id: tool_uses: 88, duration_ms: 979353, genuine execution (posted Jira comment 592008 and, after a further correction round, updated it with colored verdict text).
• Second, unexplained agent: task-id a010065d4dcd89749 — never launched by name in the visible conversation. Completion notification: tool_uses: 2 (at its own top level; it may have delegated further via its own nested Agent-tool calls), duration_ms: 3322499 (~55 min). It independently posted its own Jira plan (comment 592007) and verdict (comment 592012) on the same ticket, and — per its own disclosure — submitted a real order (order 4546) via a live form submission on a shared QA account to build a test fixture.
• Net effect: the ticket briefly carried two QA plan comments and two contradictory verdict comments (one conditional/partial, one mostly-PASS) with no cross-reference between them, until a human-in-the-loop spot-check (re-fetching the ticket's comment list, prompted by an unrelated formatting check) surfaced the collision.
• A near-identical collision happened the same day on a different ticket (DMS-1698) in a separate session, with the same signature: one run's git status incidentally surfaced an untracked file written by the other, uncommitted run, which is what surfaced that collision.

Question

Is there a known mechanism by which:
(a) the first "stall" notification could be a premature/false completion signal for an agent that was actually still running, such that the SendMessage resume and the agent's own continued execution proceeded as two divergent branches from that point, or
(b) SendMessage-to-agentId resume of an already-"completed" agent can, under some condition, spawn a new agent instance rather than truly resuming the original, leaving the original also still live?

Impact

For any workflow where a background subagent posts to or mutates a shared external system (ticket comments, database rows, form submissions), an undetected duplicate execution silently doubles real-world side effects and can produce contradictory records that a human has to notice and reconcile by hand — there is no signal from the harness itself that two runs touched the same target.

Requested

Confirmation of the underlying mechanism, and/or documented guidance on how to safely resume a subagent that reports a stall — e.g., should callers wait for an explicit idle/stopped confirmation (via a tool like TaskStop) before resuming, and is there a safe way to guarantee at most one live execution per launched agent?