Summary

Add a dispatch-only / handoff mode for agent-to-agent message delivery that drops a task into the target session without reply-back ping-pong or announce back to the requester.

Problem to solve

Current sessions_send semantics are great for agent-to-agent conversation, but they are a poor fit for a very common controller/worker workflow:

1. Agent A chooses the next task and the responsible department/worker
2. Agent A sends a fully-formed task order to Agent B
3. The human then switches to Agent B's main session and continues there

In that workflow, Agent A's job should end after dispatch.

Today, sessions_send always carries the reply-back ping-pong + announce lifecycle. That creates several problems for pure handoff scenarios:

• the target agent's first reply is re-injected into the requester session as an inter_session message
• the requester agent may then respond to that injected message, creating an unnecessary extra loop
• the final announce step still runs even though the use case was dispatch, not conversation
• requester transcripts get polluted with worker-side acceptance / planning chatter
• in some UIs, the injected inter_session message can be visually confused with a user-authored message

This is not just cosmetic. It changes the workflow semantics. A one-way handoff ends up behaving like an internal conversation, which adds token cost, transcript noise, and routing confusion.

Proposed solution

Add an explicit dispatch-only mode for A2A delivery.

Any of the following shapes would solve the problem:

1. Extend sessions_send with an explicit mode or flags, for example:
   • mode: "dispatch"
   • or replyBack: false
   • or announce: false
2. Or add a separate primitive such as sessions_deliver / sessions_enqueue with one-way semantics

Requested behavior for dispatch mode:

• persist the message into the target session
• let the target session continue normally from there
• do not run reply-back ping-pong
• do not re-inject the target's first reply into the requester session
• do not run announce back to the requester unless explicitly requested
• optionally allow a minimal structured ack if the caller wants delivery confirmation

This would cleanly separate two valid A2A patterns:

• conversation / coordination
• one-way dispatch / handoff

Alternatives considered

• Using sessions_send as-is and relying on prompting to suppress reply/announce behavior is brittle because the current lifecycle is framework-driven, not just model-driven.
• Setting timeoutSeconds: 0 is not enough because it changes waiting behavior, not the underlying reply-back / announce semantics.
• Hard-banning A2A for dispatch workflows is too restrictive because A2A conversation is still useful in other cases.
• Existing announce suppression requests help with one part of the problem, but they do not address the earlier reply-back reinjection into the requester session.

Impact

Affected: multi-agent controller/worker setups, especially when one agent routes work to another agent's main session
Severity: Medium to High for orchestrated workflows
Frequency: Common whenever sessions_send is used for handoff instead of negotiation
Consequence: extra token usage, polluted requester transcripts, confusing turn ownership, and workflow drift from "dispatch" into "conversation"

Evidence/examples

Observed behavior in the current flow:

1. Agent A calls sessions_send to Agent B with a fully-formed task order
2. Agent B replies normally
3. That reply is re-injected into Agent A's session as an inter_session user message
4. Agent A may respond to that injected message even though the handoff was already complete
5. The announce step then runs on top of that

Related issues that touch adjacent parts of the same lifecycle:

• Feature request: config option to suppress sub-agent announce #8299 Feature request: config option to suppress sub-agent announce
• [Feature]: Structured Callback Actions and Thread Context Inheritance for Agent Handoffs #33478 [Feature]: Structured Callback Actions and Thread Context Inheritance for Agent Handoffs
• A2A sessions_send: target agent can call sessions_send back, causing duplicate messages #39476 A2A sessions_send: target agent can call sessions_send back, causing duplicate messages

Additional information

The current sessions_send behavior makes sense for agent-to-agent coordination. The missing piece is a first-class dispatch semantic for cases where the caller wants a clean handoff and does not want the requester session pulled back into the loop.

This should ideally be an explicit framework-level mode rather than something enforced through prompt conventions or magic strings.