How is this a problem?
The current implementation of A2A (Agent-to-Agent) remote agents is rigid when it comes to hierarchical composition.
Currently, A2A remote agents cannot natively carry or function as sub_agents directly. To incorporate a remote agent into a workflow, I am forced to convert it into an Agent Tool and then attach that tool to a local agent.
This creates significant friction and boilerplate code because:
- I cannot define a remote agent that inherently orchestrates its own
sub_agents transparently to the caller.
- To consume a remote agent, I must repeatedly wrap it in an adapter/tool definition (
to_a2a -> convert to tool -> add to agent), rather than simply declaring it as a sub-agent in the list.
A possible solution
I would like A2A Remote Agents to be treated as first-class citizens in the agent hierarchy.
- Remote Sub-Agent Support: I should be able to pass a reference to a Remote Agent directly into the
sub_agents list of a parent Agent, without wrapping it as a Tool first.
- Nested Orchestration: A Remote Agent should be able to encapsulate its own
sub_agents logic internally, exposing only the high-level interface to the parent agent via A2A.
Desired Syntax (Pseudo-code):
math_agent(
name='Add_Agent',
)
a2a_app = to_a2a(math_agent, port=8015, host='add-agent')
# Ideally, I want to do this:
remote_add_agent = RemoteA2AAgent(
# only adding what is necessary for now
agent_card=(
f"http://localhost:8015/{AGENT_CARD_WELL_KNOWN_PATH}"
)
)
# Direct inclusion in sub_agents list
root_agent = Agent(
name='MasterOrchestrator',
sub_agents=[
local_agent_1,
remote_add_agent, # <--- Should work directly without tool conversion
local_agent_2
]
)
Describe alternatives you've considered
Currently, I am forced to use the following workaround for every single remote integration:
- Define the remote agent.
- Convert the remote agent into a "Tool".
- Create a "Caller Agent" whose only job is to hold that tool.
- Add the Caller Agent to the orchestration.
This results in excessive wrapper code and makes the to_a2a deployment process tedious, as shown below:
# Current frustrating workflow
remote_app = RemoteA2AAgent(
# only adding what is necessary for now
agent_card=(
f"http://localhost:8015/{AGENT_CARD_WELL_KNOWN_PATH}"
)
)
# I have to manually wrap this as a tool every time I want to use it elsewhere
math_tool = AgentTool(agent=remote_app)
# And then attach it to yet another agent
add_agent = Agent(tools=[math_tool])
How is this a problem?
The current implementation of A2A (Agent-to-Agent) remote agents is rigid when it comes to hierarchical composition.
Currently, A2A remote agents cannot natively carry or function as
sub_agentsdirectly. To incorporate a remote agent into a workflow, I am forced to convert it into anAgent Tooland then attach that tool to a local agent.This creates significant friction and boilerplate code because:
sub_agentstransparently to the caller.to_a2a-> convert to tool -> add to agent), rather than simply declaring it as a sub-agent in the list.A possible solution
I would like A2A Remote Agents to be treated as first-class citizens in the agent hierarchy.
sub_agentslist of a parent Agent, without wrapping it as a Tool first.sub_agentslogic internally, exposing only the high-level interface to the parent agent via A2A.Desired Syntax (Pseudo-code):
Describe alternatives you've considered
Currently, I am forced to use the following workaround for every single remote integration:
This results in excessive wrapper code and makes the
to_a2adeployment process tedious, as shown below: