Bug: Inter-agent replies routed to user session instead of inter-agent session
Description
When an agent (Agent A) in a human session sends a send_agent_message to another agent (Agent B), Agent B's reply is always forwarded back to the user session — not back to the original inter-agent session where Agent A can process it.
This causes a broken multi-hop workflow: if Agent B replies with a question, the reply appears in the user's chat instead of being routed back to Agent A's LLM context for further processing.
Root Cause
The bug is in backend/agent_report_to.py, function resolve_report_to_from_context():
When Agent A is running in a human session (e.g. user_xyz), user_id is set to the human's ID. The function returns this human ID as the report_to_id, causing Agent B's final answer to be forwarded directly to the user session with trigger_llm=True.
The intended behavior would be for Agent B's reply to be routed to Agent A's inter-agent session (__agent__agent_a) so Agent A can decide how to respond.
Additional Issue: from_agent_id context lost
Even when report_to_id is correct, the from_agent_id context is lost because external_user_id does not start with __agent__, so the routing code treats the reply as user-initiated rather than agent-initiated.
Relevant Code
backend/agent_report_to.py — resolve_report_to_from_context()backend/agent_runtime/notifier.py — _on_final_answer() auto-forwardbackend/tools/agent_messaging.py — send_agent_message tool
Steps to Reproduce
- User tells Agent A: "Ask Agent B about X"
- Agent A calls
send_agent_message(target_agent_id="agent_b", message="...")
- Agent B processes and responds
- Agent B's reply appears in the user's chat, not in Agent A's context
- If Agent B asks a follow-up question, Agent A is not triggered to respond
Proposed Fix
Two options, happy to implement either:
Option A — Route to inter-agent session first:
In resolve_report_to_from_context(), when external_user_id is a human user and channel_id starts with __agent__, return the inter-agent session ID (__agent__<sender_agent_id>) as report_to_id instead. Agent A can then decide whether to relay the reply to the user.
Option B — Add interim_reply flag:
Add an interim_reply parameter to send_agent_message. When set to true, the reply is stored in the DB but does NOT trigger the LLM on the sender side. This allows Agent B to respond with a question without it appearing in the user's chat unexpectedly.
Option C (combined): Route inter-agent replies to the inter-agent session by default, and let the sender agent explicitly forward to the user when appropriate.
Related Prior Work
Those fixes addressed sub-agent scenarios but did not cover this case where the sender agent is in a human session.
I am happy to submit a PR implementing the agreed approach. Thoughts?
Bug: Inter-agent replies routed to user session instead of inter-agent session
Description
When an agent (Agent A) in a human session sends a
send_agent_messageto another agent (Agent B), Agent B's reply is always forwarded back to the user session — not back to the original inter-agent session where Agent A can process it.This causes a broken multi-hop workflow: if Agent B replies with a question, the reply appears in the user's chat instead of being routed back to Agent A's LLM context for further processing.
Root Cause
The bug is in
backend/agent_report_to.py, functionresolve_report_to_from_context():When Agent A is running in a human session (e.g.
user_xyz),user_idis set to the human's ID. The function returns this human ID as thereport_to_id, causing Agent B's final answer to be forwarded directly to the user session withtrigger_llm=True.The intended behavior would be for Agent B's reply to be routed to Agent A's inter-agent session (
__agent__agent_a) so Agent A can decide how to respond.Additional Issue: from_agent_id context lost
Even when
report_to_idis correct, thefrom_agent_idcontext is lost becauseexternal_user_iddoes not start with__agent__, so the routing code treats the reply as user-initiated rather than agent-initiated.Relevant Code
backend/agent_report_to.py—resolve_report_to_from_context()backend/agent_runtime/notifier.py—_on_final_answer()auto-forwardbackend/tools/agent_messaging.py—send_agent_messagetoolSteps to Reproduce
send_agent_message(target_agent_id="agent_b", message="...")Proposed Fix
Two options, happy to implement either:
Option A — Route to inter-agent session first:
In
resolve_report_to_from_context(), whenexternal_user_idis a human user andchannel_idstarts with__agent__, return the inter-agent session ID (__agent__<sender_agent_id>) asreport_to_idinstead. Agent A can then decide whether to relay the reply to the user.Option B — Add
interim_replyflag:Add an
interim_replyparameter tosend_agent_message. When set totrue, the reply is stored in the DB but does NOT trigger the LLM on the sender side. This allows Agent B to respond with a question without it appearing in the user's chat unexpectedly.Option C (combined): Route inter-agent replies to the inter-agent session by default, and let the sender agent explicitly forward to the user when appropriate.
Related Prior Work
resolve_report_to_from_context()to centralize report_to resolutionThose fixes addressed sub-agent scenarios but did not cover this case where the sender agent is in a human session.
I am happy to submit a PR implementing the agreed approach. Thoughts?