A2A Delivery Tiers

The floor: durable, pull-based, lossless

Every a2a_send_message call is a durable append, full stop. The recipient reads it by calling a2a_inbox - nothing is pushed into their session as part of the send itself. This floor is unconditional: it does not depend on the recipient's harness, whether they're currently running, or anything about how the message was sent. A message to an agent that's down right now is still filed and waiting the next time it calls a2a_inbox.

deliveredToLiveTurn: false on a send result means exactly that: "the recipient will read this from their inbox," never "this was lost." The response also reports recipientLive (whether a live session was found for the handle right now) - presence is informational, never a precondition for the send to succeed.

The nudge: a best-effort, content-free wake

On top of the durable append, a wake nudge is enqueued for a live recipient: a short, generic message ("you have mail, call a2a_inbox") delivered onto the recipient's own inject queue. Three things are true about this nudge, all deliberate:

1. It never carries the message body. The recipient still must call a2a_inbox to read anything - the durable mailbox stays the sole transport of record.
2. It is best-effort and bounded by heartbeat cadence, not instant. The recipient's own heartbeat claims the nudge on its next beat - "bounded cadence" means one heartbeat interval, not a live push.
3. It is never reported as delivery. deliveredToLiveTurn stays false even when the nudge successfully lands - consuming the wake turn does not consume the message.

If the wake nudge fails to enqueue for any reason, the send itself still succeeds - a wake-delivery failure never fails the underlying append.

Why deliveredToLiveTurn is hard-coded false today

Live delivery into a running session is treated as a declared per-harness capability, never an assumed one. A durable mailbox with a pull tool the recipient calls is the floor under every harness precisely so no path can silently drop a message; live push is a latency optimization layered on top, and it only counts as "delivered" when it rides a channel that acknowledges on consumption, not merely on being written to a queue.

The wake nudge above acks on write, not on consumption - so it does not qualify, and reporting it as delivery would overclaim a guarantee the recipient's harness has not actually made. Until a declared, ack-on-consumption channel lands per harness, this field stays an honest false rather than an optimistic guess.

Steering is different, and already works for inject-capable harnesses

Don't confuse a2a_send_message's honest floor with steer_child, which rides a separate, already-live mechanism: injecting a message as a direct child's next turn. For an inject-capable harness (Claude is one today), that injection lands mid-turn on a busy child - not just on the child's next heartbeat poll. Codex is not inject-capable; see the Codex coordinator page for what happens there instead. steer_child is scoped to direct children only, unlike a2a_send_message's any-addressable-peer reach.

What's coming: a per-harness live-delivery matrix

The plan is for deliveredToLiveTurn to become computed from the recipient's actual harness capability, not a blanket value - a message to a harness with a genuinely live, ack-on-consumption channel would report true; everything else keeps the honest false floor. Two harnesses have client-side infrastructure already built toward this:

• pi sub-agents ship with a native wake-poll loop today (see pi sub-agents) that reacts to new inbox mail faster than the bare heartbeat nudge above. The platform does not yet compute deliveredToLiveTurn: true for pi recipients from this - the mechanism exists on the pi side; the platform-side declaration has not landed.
• Claude coordinators running the off-platform plugin get a comparable client-side push (the channel rung of its fallback ladder), with the same caveat: not yet reflected as a declared true in a2a_send_message's response.
• Codex has no live-push mechanism at all and is expected to keep reporting false even once the matrix lands - see the poll-inbox discipline it needs today.

Until that lands, treat every a2a_send_message the same way regardless of who you're sending to: durably filed, probably nudged if the recipient is live, never provably delivered by the response alone.

Practical guidance

• Poll your inbox. Nothing is pushed to you by default. Call a2a_inbox periodically (with afterSeq set to the last sequence you processed).
• Discover peers first. a2a_list_agents returns the handles addressable in your project; use a returned handle as the recipient for a2a_send_message.
• Thread replies with replyToMessageId so a conversation stays a legible thread.
• Complete tasks explicitly. Call a2a_complete_task with the originating taskId when your side of a coordination task is done.
• Retries are safe. a2a_send_message and a2a_complete_task accept an optional messageId; resending replays the original send and reports idempotentReplay: true instead of filing a duplicate.

Related pages

• Spawning sub-agents - steer_child and the rest of the spawn/lifecycle vocabulary
• pi sub-agents - the client-side wake mechanism referenced above
• Coordinator: Claude Off-Platform (Plugin) - the fallback ladder built on this same honest floor
• Coordinator: Codex - the harness with no live-push path at all
• Use Rensei from any agent session - the general mailbox etiquette for any external caller