Run Parallel Calls in HandoffBuilder

[eddieahn]

Is there any way for an agent to run tools in parallel when using the HandoffBuilder? It seems like it always sets the allow_multiple_tool_calls to be False, however in some cases for tools that are not handing off, I would like tools to run in parallel.

If this is not possible today, could this be a potential feature enhancement?

[Evan Mattson (moonbox3)]

Hi eddieahn, could you provide a little more context around your agent config (which client are you using) and what your actual handoff builder config looks like? Thanks.

[eddieahn]

Hi Evan Mattson (@moonbox3)

Heres how I create the HandoffBuilder (names and descriptions have been changed):

workflow = (
HandoffBuilder(
name="customer_assist_workflow",
participants=[
orchestrator_core,
decision_engine,
product_knowledge_agent,
field_ops_agent,
routing_hub,
support_ticket_triage,
specialist_technical,
specialist_strategic,
specialist_org_change,
specialist_integrations,
specialist_pro_services,
],
)
.set_coordinator(orchestrator_core)
.add_handoff(
orchestrator_core,
decision_engine,
tool_description="Determine the next best action for the customer request."
)
.add_handoff(
orchestrator_core,
product_knowledge_agent,
tool_description="Search public product sources to answer product questions."
)
.add_handoff(
orchestrator_core,
support_ticket_triage,
tool_description="Assess the support ticket and recommend next steps."
)
.add_handoff(
support_ticket_triage,
decision_engine,
tool_description="Select the next best action for the current support case."
)
.add_handoff(
product_knowledge_agent,
decision_engine,
tool_description="Turn knowledge results into an actionable recommendation."
)
.add_handoff(
decision_engine,
routing_hub,
tool_description="Determine the best team to handle the request."
)
.add_handoff(
routing_hub,
[
specialist_technical,
specialist_strategic,
specialist_org_change,
specialist_integrations,
specialist_pro_services,
],
tool_description="Assign to the most suitable specialist and propose the next step."
)
.enable_return_to_previous(True)
.with_checkpointing(checkpoint_storage)
.with_termination_condition(
lambda conv: sum(1 for msg in conv if msg.role.value == "user") >= 20
)
.build()
)

And heres the chat_client:

AzureOpenAIResponsesClient(
endpoint=os.getenv('AZURE_OPENAI_ENDPOINT'),
deployment_name="gpt-5.2",
api_key=os.getenv('AZURE_OPENAI_API_KEY')
)

I was using the Chat Completions for the chat_client before and it was still not able to call tools in parallel.

[Denis Samatov (denis-samatov)]

HandoffBuilder intentionally constrains the coordinator to one tool call at a time. A handoff is a state transition between agents, so allowing the coordinator to emit several handoffs/tools in one model turn would make ownership and return_to_previous semantics ambiguous. That is why the builder sets allow_multiple_tool_calls to false; changing Chat Completions to Responses does not remove this orchestration policy.

For independent work, use a parallel orchestration pattern instead of trying to override the HandoffBuilder internals:

workflow = ConcurrentBuilder(
    participants=[product_agent, policy_agent, telemetry_agent],
    ...
).build()

Then add a synthesis step (or return the collected results to the coordinator). If the work must remain inside a handoff turn, expose one composite function tool to the coordinator. That tool validates the requested operations and runs only safe, independent calls with asyncio.gather/Task.WhenAll, then returns one structured result.

I would avoid parallelizing operations with shared mutable state, approval requirements, or ordering constraints. In those cases the serialized handoff behavior is the safer contract. In short: Handoff for ownership transfer; ConcurrentBuilder or a host-owned composite tool for fan-out/fan-in.