Inconsistent Tool Invocation Behavior in AG-UI (with ADK Root Agent and Subagents)

[marttinslucas]

Hi everyone, could you please help me with an unexpected behavior I’m seeing when using AG-UI?

I have a root agent (ADK) that orchestrates four subagents, which are used as tools.
I’m including a custom tool directly in the body of the /ag-ui request.

I tested two approaches:
1. In the messages field, I added a system role defining how the custom tool should be used, and also described it under "description".
2. In the second test, I removed the system role completely.

This custom tool must always be called at the end of the agent’s reasoning, to “format” the response for the frontend.

However, I’ve noticed some inconsistent behavior:
• Sometimes, the root_agent returns SSE messages (TEXT_MESSAGE_CONTENT) before calling the custom tool (which is fine).
• Other times, after a subagent response, the system calls the tool directly, without any assistant message being streamed beforehand.

Questions
• What is the expected behavior here?
Should the tool defined in the body request be visible to all agents (including subagents used as tools), or only to the root agent?
• Is there a way to force the execution of a tool through a request parameter?

ag-ui-adk==0.3.1
ag-ui-protocol==0.1.9

[contextablemark]

Hi @marttinslucas,

These both sound like questions about ADK functionality rather than the integration. However, given that the subagents are already initialized before being added to the parent, I would not expect them to inherit any parent tool definitions since the relationship between the agents is purely hierarchical (in answer to the first question).

In regards to the second question, if you're relying upon the LLM to invoke the tool, the best you can do is create a well-crafted prompt and hope that the LLM will follow that prompt - there's no guarantee. If you want a guarantee, you're better off calling the tool explicitly as part of an after_model_callback (see https://github.com/google/adk-python/blob/6dcbb5aca642290112a7c81162b455526c15cd14/contributing/samples/callbacks/agent.py#L195), but then you'll be responsible for calling the function directly and incorporating any response, as the LLM will have already run.

• Mark

[trend-denny-lee]

@contextablemark
The first question is that we are thinking about how to do it better: trendmicro/adk-agui-middleware#9

[marttinslucas]

Thanks for the previous responses, everyone! 🙏
I still have a few doubts regarding the AG-UI behavior.

I’ve noticed that the "assistant" sometimes streams partial messages (TEXT_MESSAGE_CONTENT) before invoking the dynamic tool defined in the request body — but other times, no assistant stream appears at all, and the tool is invoked directly after the internal reasoning.
I’d like to confirm whether this is expected behavior, or if there’s any difference in execution between the root agent and the subagents in this flow.

Another question:
Is the "assistant" in the streamed responses actually my root_agent, or could it be a subagent being surfaced depending on how AG-UI handles the dispatch?

Lastly, I’ve noticed that even without any dynamic tool added, the response behavior differs when calling the same agent directly through /run (pure ADK) versus via the /ag-ui route.
I’m wondering if the AG-UI protocol can modify how an agent behaves or interprets a user query — for example, in terms of tool invocation order, streaming, or context control.

[contextablemark]

@marttinslucas - a lot to unpack here, but I'll try

I’ve noticed that the "assistant" sometimes streams partial messages (TEXT_MESSAGE_CONTENT) before invoking the dynamic tool defined in the request body — but other times, no assistant stream appears at all, and the tool is invoked directly after the internal reasoning. I’d like to confirm whether this is expected behavior, or if there’s any difference in execution between the root agent and the subagents in this flow.

I'd like to know more about what's meant by "partial messages" - do you mean messages that are somehow truncated?

Another question: Is the "assistant" in the streamed responses actually my root_agent, or could it be a subagent being surfaced depending on how AG-UI handles the dispatch?

It's possible for it to be a sub-agent, but the ADK middleware as currently implemented (and, by extension AG-UI) wouldn't currently have visibility into this.

Lastly, I’ve noticed that even without any dynamic tool added, the response behavior differs when calling the same agent directly through /run (pure ADK) versus via the /ag-ui route. I’m wondering if the AG-UI protocol can modify how an agent behaves or interprets a user query — for example, in terms of tool invocation order, streaming, or context control.

When you mention "/run (pure ADK)", how is the toolset being injected in this case? When invoked via AG-UI, any server side tools come first, followed by the AG-UI-provided client tools (which are also filtered to remove any client-side tools where there is a naming clash). There's also the possibility (by adding a SystemMessage as the first message in the message list) of adding a system prompt, which will certainly alter the way the agent behaves.

In any case, you're likely getting to the point where some sort of instrumentation (e.g., OpenTelemetry) combined with the AG-UI trace is going to be needed to dig further. Have you tried that yet?