Realtime: Handoffs don't hand back up to original agent

[sibblegp]

Describe the bug

With v0.2.2, handoffs are working but unlike in the standard agent, once a handoff is made, it doesn't go back up the tree to the original agent when further requests are made.

I.e. I have one agent for getting crypto prices. If I ask for a crypto price, it gives it. I have another agent for stock prices but if I ask for a stock price, it still runs it in the crypto agent since it doesn't go back up to the "switching/orchestrator" agent, like in the normal agent SDK.

Debug information

• Agents SDK version: v0.2.2
• Python version: pyton 3.13

Repro steps

Make a call that hands off to another agent and calls a tool. Future calls will always go to that agent and not the one that made the handoff.

Expected behavior

The original requests should always go to the initial agent specified in .run() not the agent handed off to.

[kaka1nices]

You need to distinguish the meaning of handoffs and tool. As you said, Maybe you can use the agent as tool

[sibblegp]

I have a collection of agents that each have tools. In the text SDK, everything is first submitted to what I call the orchestrator agent which can then hand off to any other agent. This works well. With the new realtime setup, the system gets stuck once it hands off and doesn't work again.

I just think it should be consistent with how the normal agent SDK works which is it all goes back to the original agent you are launched with. Otherwise, how would you ever escape a handoff?

[Kunmeer-SyedMohamedHyder]

I have a collection of agents that each have tools. In the text SDK, everything is first submitted to what I call the orchestrator agent which can then hand off to any other agent. This works well. With the new realtime setup, the system gets stuck once it hands off and doesn't work again.

I just think it should be consistent with how the normal agent SDK works which is it all goes back to the original agent you are launched with. Otherwise, how would you ever escape a handoff?

Hello @sibblegp! This is the expected behavior of handoffs. If you wish to have the handle always with your orchestrator agent, you can attach all your assistant agents as tools to the orchestrator (like mentioned by @kaka1nices). This is just one of the agent patterns available. To know more on how to achieve this, please have a look at - https://github.com/openai/openai-agents-python/blob/main/examples/agent_patterns/README.md#agents-as-tools

[sibblegp]

@Kunmeer-SyedMohamedHyder Really? Interesting. I don't think that's how it should be. That means any realtime conversation handed off to another agent is stuck with that agent and cannot switch agent contexts. I suppose in one call of .run() that makes sense but is a bit odd.

I've reported before that it's odd that once you get handed off it won't hand back up the chain. I'd love to be able to have work done by multiple agents in one .run() with text. Could we look into this possibility?

[kaka1nices]

@Kunmeer-SyedMohamedHyder Really? Interesting. I don't think that's how it should be. That means any realtime conversation handed off to another agent is stuck with that agent and cannot switch agent contexts. I suppose in one call of .run() that makes sense but is a bit odd.

I've reported before that it's odd that once you get handed off it won't hand back up the chain. I'd love to be able to have work done by multiple agents in one .run() with text. Could we look into this possibility?

Two weeks ago, I also encountered this problem. After my research, I found that OpenAI's design philosophy is correct. Firstly, the sub agent cannot determine whether it is appropriate to return the results to the multi-agent or directly deliver them to the user, which can create a great illusion; The second issue is token overload caused by long context.

Perhaps you can refer to the previous official response from @rm-openai
links: #955 #847

[sibblegp]

@kaka1nices That's a good way of putting it. It all works fine if they are just a list of tools. Interesting design philosophy that I can't say I totally agree with. In the context of the session, it knows what other handoffs and agents there are so it should be able to decide "transfer to this agent which has this capability" but I can see how it kind of doesn't.

I cheat on this with our text based agent by having sub-handoffs inside of handoffs. Then they can all hand off to each other. Can't do that with Voice though because there would be circular imports.

[rm-openai]

You can always do:

agent_1.handoffs.append(agent_2)
agent_2.handoffs.append(agent_1)

If there is a circular dep, just do it from a third place that imports both.

[sibblegp]

It's just easier to have them all as tools. It makes logical sense too.

[yashika-git]

@rm-openai @seratch @sibblegp, can a handoff agent handoff to another agent?

For example: Agent A → Agent B → Agent C (i.e. a linear chain with no bidirectional handoffs)

agent_c = Agent(name="Agent C")
agent_b = Agent(name="Agent B", handoffs=[agent_c]) 
agent_a = Agent(name="Agent A", handoffs=[agent_b])

Is this nested handoff pattern supported? If yes, will the final output be returned by Agent C?