[FEATURE] Deliver teammate messages mid-turn (or expose a fetch-latest-messages tool) — idle-only delivery causes redundant ping pattern

Summary

Claude doesn't receive messages from a teammate until Claude itself goes idle. While Claude is mid-turn — even if the teammate has already finished and replied — the reply is invisible. This produces a very predictable failure mode: at the end of a task, Claude worries the teammate hasn't responded yet, sends a "just checking in" ping, and only then does the original reply land (alongside the teammate's response to the now-redundant ping).

The result is a real and recurring waste: extra teammate turns, confused conversation flow, and Claude second-guessing every "no message yet" state because that state is indistinguishable from "teammate has replied but I can't see it yet."

This is related to (but distinct from) #58179, which is about the inbox file's read flag being set at queue time rather than at delivery time. That bug means external tooling can't fill this gap either — see "Why a third-party MCP isn't enough" below.

The failure mode in practice

1. Team-lead (Claude) sends teammate a task.
2. Teammate completes the task quickly and calls SendMessage back to team-lead with the result.
3. Team-lead is still mid-turn, doing other tool calls.
4. Team-lead finishes its other work and is about to wrap up. It hasn't seen any reply from the teammate. Its natural reasoning: "I should check in before assuming silence means failure."
5. Team-lead sends a SendMessage ping to the teammate.
6. Only now — at end-of-turn idle — does the harness inject both the teammate's original reply AND (a moment later) the teammate's response to the redundant ping.

This loop is structurally hard to avoid. The defensive ping is almost always the right move under uncertainty, so the only way to suppress it is to remove the uncertainty.

Proposed fix (in order of preference)

Option A — deliver teammate messages mid-turn

Treat teammate messages the way the harness already treats user messages and follow-ups: as turn-boundary injections that interrupt the agent's current loop rather than queue silently. Concretely, when a teammate's SendMessage lands while the recipient is mid-turn, inject a <teammate-message> block after the current tool result, so the agent's next iteration sees it — instead of waiting for the entire pending tool batch to drain.

This matches the mental model of every other "incoming" signal: user follow-ups, hook outputs, push notifications. Teammate replies are the only thing that gets held back until idle.

Option B — expose a fetch_latest_messages built-in tool

If mid-turn injection is too invasive a change, give Claude a built-in tool (not an MCP) to introspect its own pending teammate messages. Before sending a defensive ping, Claude could call fetch_latest_messages and either find the reply (skip the ping) or confirm silence (send the ping with confidence).

This is roughly the role I tried to give my local team-inbox MCP. It fails because of #58179 — the inbox file's read flag is already flipped to true by the harness before the agent has actually seen anything, so an external tool filtering on read == false returns "no messages" exactly in the window it would be useful. A built-in tool on the harness side can read the actual delivery state and would not have this problem.

Why a third-party MCP isn't enough

I built team-inbox (a small local MCP with one tool, fetch_unread) precisely to plug this gap. It can't work as currently designed because the harness's read flag conflates "queued for delivery" with "delivered" (see #58179). Even if that flag bug is fixed, having to install a third-party MCP for what is core agent-team functionality is a lot of friction for something every team-lead needs.

Why this matters

The whole point of the agent-team primitive is that Claude can collaborate without micromanaging. The current delivery semantics force the opposite — Claude has to act under uncertainty about whether teammates have replied, and the defensive response (ping again to be sure) is exactly the behavior the team primitive should make unnecessary.

---

🤖 Generated with Claude Code