Questions regarding _find_agent_to_run function

[maheshwaritanay]

From the code I understood that the agent is selected according to the following priority criteria-

1. If last event is function response we check the corresponding function call ID. The next agent to run is the author of this function call
2. Else filter only agent events and sort in reverse order. Iterate sequentially, if the author is root agent return it
3. Else check if the agent is "transferrable". If yes, return this agent
4. Default to root agent

I have several questions in this flow-

1. In the function to check matching call ID, we pick the first part.function_response from the last event. From this code it appears that an event can have multiple function call and responses. If that is the case, how are we handling agent transfers for function responses other than the first function response.
2. We are iterating in a nested loop to find the function ids, the complexity will grow (No.of events)*(number of function calls)^2 with higher number of events and function calls. Would it be better to store the ids in a map?
3. I am not able to visualize the flow of is_transferrable_across_agent_tree function. For eg-
   a. is_transferrable_across_agent_tree function checks for "disallow_transfer_to_parent" flag for each agent node from current to parent. So in a case where we have Agent -> sub_agent1(disallow_transfer_to_parent=True) -> sub_agent_of_sub_agent_1, I would expect the final control to remain with sub_agent1, but according to the code the control goes back to the root_agent

   if self._is_transferable_across_agent_tree(agent):
     return agent
   # Falls back to root agent if no suitable agents are found in the session.
   return root_agent```
   
   

Therefore I am confused about the thought process behind this architecture. I would greatly appreciate if someone can explain this to me

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: Thank you for your detailed questions. Here’s a summary of the design philosophy behind the _find_agent_to_run function:

1. Function Response Handling: The logic prioritizes the most recent tool usage to determine the next agent, and for simplicity, it currently inspects the first function response in the last event.
2. Performance vs. Simplicity: The use of loops is a deliberate design choice that prioritizes code clarity and simplicity over micro-optimizations in a non-bottleneck area.
3. Transferability (is_transferrable_across_agent_tree): The disallow_transfer_to_parent flag is designed to create encapsulated agent sub-trees. When control leaves such a tree without a specific next destination, it correctly reverts to the root_agent to re-evaluate the overall task, rather than getting stuck with a mid-level agent.

---

Here are the detailed answers to your questions:

1. Handling of Multiple Function Responses

You are correct in observing that the logic often selects the first function call or response from an event (e.g., using event.get_function_calls()[0]). While the framework can execute multiple tool calls in parallel, the agent selection process needs to determine which agent should act next. The design simplifies this by linking the next turn to the author of the most recently completed tool. In a scenario with multiple function responses in a single event, the current implementation focuses on the first one as the primary signal for handoff. This reflects a design that prioritizes a clear and simple signal for agent transition.

2. Performance of Nested Loops

Your point about the computational complexity of nested loops is valid. However, in the context of a typical agent interaction, the number of events and function calls within a single turn is usually small. The developers likely made a trade-off, prioritizing code readability and maintainability over the performance gains of using a map. For the expected scale of inputs, the performance impact of the loops is negligible, and the straightforward loop structure is easier to understand and debug.

3. The is_transferrable_across_agent_tree Flow

Your confusion about this flow is understandable. The purpose of the disallow_transfer_to_parent = True flag is to create a boundary around an agent and its descendants, effectively encapsulating a sub-task.

Let's trace your example: Agent -> sub_agent1(disallow_transfer_to_parent=True) -> sub_agent_of_sub_agent_1.

1. The last agent to run was sub_agent_of_sub_agent_1.
2. The system checks if control can be transferred from this agent. The _is_transferable_across_agent_tree function traverses up the agent hierarchy from sub_agent_of_sub_agent_1 towards the root.
3. On its way up, it encounters sub_agent1 which has disallow_transfer_to_parent=True. This flag breaks the transferability chain, causing _is_transferable_across_agent_tree to return False.
4. Because the last active agent is not transferable, the system does not hand control to its parent. Instead, as you noted, it falls back to the root_agent.

This is the intended behavior. The rationale is that if a self-contained sub-task (encapsulated by sub_agent1) is complete, control should return to the main orchestrator (root_agent) to decide what to do next with the full context of the overall goal. Handing control to an intermediate agent (sub_agent1) could leave the system stuck in a state where the mid-level agent doesn't have enough context to proceed. This fallback to the root is confirmed by unit tests for the runner. [1]

I hope this clarifies the design decisions behind the agent selection logic.

[1] https://github.com/google/adk-python/blob/main/tests/unittests/test_runners.py

[maheshwaritanay]

I would like further clarification here

[maheshwaritanay]

If the only intended behaviour of disallow_transfer_to_parent is to create self contained subtask and return the control back to root, I believe it should be named something like transfer_to_root. Current variable name of disallow_transfer_to_parent gives impression that the control should be contained at that agent level.