How to pass the control back to triage agent

[sanjeev-kumar-4]

Please read this first

• Have you read the docs?Agents SDK docs : YES, I checked the document about handoff
• Have you searched for related issues? Others may have had similar requests : YES, could not find one related to my question.

Question

I have a main orchestration agent and another downstream agent. The handoff to the downstream agent works fine and the downstream agent is able to finish it's job well.
But how do we pass the control back to orchestration agent? I saw an example here where we add the instruction in the prompt of the downstream agent. I tried this but it does not work. Can someone help me figure out a way to do this? Has someone done this?

Thanks in advance

[sina-hartung]

Like in the example you reference, I use sub_agent.handoffs.append(triage_agent)

To get it to work, there's a couple of places where I added very specific instructions that allowed handoff back to triage_agent. For example, adding the following to the instructions "You only do sub_task. If the user requests something else, refer back to the Triage Agent."

I also added this snippet for specific instructions relevant to our use case:

<handoff> 
# Handoff rules:     
- If the user aborts the request, you refer back to the triage agent.
- If the users asks something that is not directly related a XXX request, you refer back to the triage agent.
</handoff>

Adding explicit verbiage like this allowed me to invoke handoff back to the orchestrator though there are edge cases where handoff is still fickle and unpredictable.

Also add the RECOMMENDED_PROMPT_PREFIX you can find in OpenAI's docs.

[cm2435]

@sina-hartung https://openai.github.io/openai-agents-python/tools/#agents-as-tools might be what you're looking for?

[sanjeev-kumar-4]

@sina-hartung Thanks for the pointers on promt. I tuned those. Also, there was a bug in my code where I was not passing the correct instance of the orchestration agent. Made some progress and stuck on some other issue now, but that is resolved.

@cm2435 Agents as tool are useful when the Agent(tool) does one single thing rather than handling some sub-flow of the entire functionality. In the second case I still feel having a separate downstream agent, with it's own tools, is more helpful.

[cm2435]

@sanjeev-kumar-4

In my testing, you can handle entire subflows with the "agents-as-tools" pattern. For example:

Agent A (with tools 1, 2, 3) calls Agent B (with tools 4, 5, 6). You can get flows like:

• A calls 1
• A calls 3
• A calls B as a tool
• B calls 5
• B calls 6
• B runs out of tool calls in its context loop, so hands back to A
• A completes

All "agent-as-tool-call" means is there is a guarantee of context deferral from B → A at the end.

[sanjeev-kumar-4]

Got it. Does this provide any gains over having B as agent only? Like simplified flow?

[cm2435]

@sanjeev-kumar-4 gives you a deterministic return, which is nice.

Drawback however- agents-as-tools are tools, and tools aren't streamed. So you'll have a blocking return waiting for the return of agent B

[ch-royde]

Yes, when using the agent as a tool, we need a streaming response from the tool.

[github-actions]

This issue is stale because it has been open for 7 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 3 days since being marked as stale.