Agent Teams: Lead check-in polling + between-turn-only delivery creates feedback loop of stale messages, false unresponsiveness, and duplicate teammates

Summary

When the team lead sends check-in messages to a working teammate, a destructive feedback loop emerges from the interaction between the lead's monitoring behavior and the between-turn-only message delivery architecture. This consistently leads to duplicate teammates fighting over the same work.

The Cascade

1. Lead sends check-in — The lead has no visibility into whether a teammate is actively working (mid-turn). It interprets silence as potential unresponsiveness and sends a "status check" via SendMessage (often every 2-3 minutes).

1. Messages queue silently — The teammate is mid-turn (executing tools, reasoning). Messages are only delivered between turns (#30992), so check-ins accumulate in the inbox unread.

1. Teammate reads stale messages first — When the teammate finishes its turn and polls the inbox, it processes messages in FIFO order. The first message is a stale "are you still working?" from 10 minutes ago. The teammate responds to it — wasting a turn on outdated context.

1. Lead interprets silence as death — The lead sent 4 check-ins over 12 minutes with no response. It concludes the teammate is stuck/dead (#29271). It either:

• Sends a shutdown_request (which also queues and arrives late)
• Spawns a replacement teammate with the same task

1. Duplicate teammates conflict — Both the original teammate (still alive, still working) and the replacement now operate on the same task. They read the same files, make competing edits, and produce conflicting outputs. The lead now has two agents reporting different results for the same task.

Root Causes

This is a composite issue — a feedback loop emerging from several known infrastructure limitations interacting:

• Between-turn-only delivery (#30992, #28075): Messages cannot interrupt a working teammate
• No liveness/progress signal (#29271): Lead cannot distinguish "working" from "stuck" from "dead"
• FIFO message ordering: Stale check-ins are processed before current redirections, wasting turns on outdated questions
• No delivery receipt/read receipt: Lead has no way to know if a message was delivered, read, or still queued

Impact

• Token waste: Lead burns turns on check-in messages that queue up. Teammate burns turns responding to stale check-ins. Duplicate teammates double the total work.
• Incorrect results: Competing teammates may produce conflicting outputs
• Session degradation: The more the lead checks in, the worse the problem gets (positive feedback loop)
• User must manually intervene: Pressing Escape to interrupt and break the cycle

Why This Is Not a Duplicate

This issue describes an emergent feedback loop between the lead's behavior and infrastructure limitations. The related open issues each document individual symptoms or root causes, but none capture the full cascade or the FIFO-ordering dimension:

| Issue | What It Covers | What This Issue Adds |
|-------|---------------|---------------------|
| #30992 — Real-time inter-agent messaging | Messages only delivered between turns | Describes the behavioral consequence: the lead's check-in cadence interacts with this to create an ever-deepening stale message queue |
| #32996 — Teammates systematically duplicated | Lead spawns each teammate twice | Documents why the lead spawns duplicates: it misreads queued-but-undelivered silence as teammate failure, a direct result of the feedback loop |
| #34668 — Teammates stop receiving SendMessage | Delivery mechanism breaks after extended polling | This issue shows that even when delivery works, the FIFO ordering means the teammate responds to the oldest (stalest) message first, compounding the problem |
| #31389 — Teammate ignores shutdown_request | Shutdown messages don't get processed; idle notification loops | Shutdown requests are just another message in the queue — this issue explains why they arrive too late (buried under check-in messages) |
| #32663 — TaskUpdate auto-sends confusing messages | System-generated task_assignment messages waste lead tokens | Those auto-messages add more noise to the inbox queue described here, accelerating the feedback loop |
| #35072 — Reliable interrupt/notification mechanism | Proposes infrastructure fixes for message delivery | Feature request for a fix; this issue documents the specific user-facing failure mode that fix would address |
| #36849 — SIGUSR1 handler for immediate channel check | Signal-based trigger for message delivery | Another proposed fix mechanism; this issue provides the behavioral evidence for why such a fix is needed |

Suggested Mitigations

Infrastructure-level

1. Teammate activity signal — Expose a lightweight status visible to the lead (e.g., "teammate X is mid-turn, last tool call: 30s ago") so the lead can distinguish "working" from "stuck"
2. LIFO or coalesced inbox — Process newest messages first when a backlog exists, or auto-discard older check-in messages when a newer one supersedes them
3. Delivery receipts — Return "queued (recipient busy)" vs "delivered" so the sender knows not to re-send
4. Duplicate spawn guard — Warn or block spawning a teammate with the same task assignment as an existing alive teammate

Model-level (system prompt / CLAUDE.md guidance)

1. Patience heuristic — Instruct the lead to use TaskList and file-activity checks (git status) instead of sending check-in messages. Reserve SendMessage for genuinely new information.
2. Rate limit self-awareness — "If you have an unacknowledged message in a teammate's queue, do not send another until they respond."

Environment

• Claude Code CLI (v2.1.x)
• Agent Teams (TeamCreate / SendMessage / TaskCreate)
• macOS
• Observed across multiple sessions with 2+ teammates
• Affects both in-process and terminal backends