Migration from SequentialAgent to Workflow with AgentTools: Context is lost

[mariokorte]

🔴 Required Information

Please ensure all items in this section are completed to allow for efficient
triaging. Requests without complete information may be rejected / deprioritized.
If an item is not applicable to you - please mark it as N/A

Describe the Bug:
I am migrating my SequentialAgent to the new Workflow. Agent 1 has AgentTools.

After migration the Agent calling an AgentTool restarts without context:
START -> Agent1 -> calling Tool "agentTool1" -> Back to Agent1 (but this time the agents starts without any context. It just has its system instructions available).

Steps to Reproduce:
Before:

sequential_agent = SequentialAgent(
    name="Assistant",
    description="Sequential agent that orchestrates work and synthesizes final response",
    sub_agents=[orchestrator_agent, response_agent],
)

Iterating events:
async for event in sequential_agent.run_async(ctx):

After:

sequential_workflow = Workflow(
    name="Assistant",
    edges=[("START", orchestrator_agent, response_agent)],
)

Iterating events:
async for event in sequential_workflow.run(ctx=Context(ctx), node_input=ctx.user_content):

Expected Behavior:
Agent1 working on user query, calling agentTool1, returning to Agent1 with full context available (user query, tools calls, tool responses, etc), Agent1 continuing its task

Observed Behavior:
Agent1 working on user query, calling agentTool1, returning to Agent1 with no context available, therefore answering something like "Understood. Provide request"

In mlflow it can be seen, the user query is "Handle the requests as specified in the System Instruction.", which is inserted by litellm automatically, if no content parts are available.

Environment Details:

• ADK Library Version (pip show google-adk): 2.0.0
• Desktop OS:** macOS
• Python Version (python -V): 3.12.13

Model Information:

• Are you using LiteLLM: Yes
• Which model is being used: Mistral Models, but that's irrelevant

---

🟡 Optional Information

Providing this information greatly speeds up the resolution process.

Regression:
It works with sequential agent, it does not with worflow

Logs:
n/a

Screenshots / Video:
n/a

Additional Context:
n/a

Minimal Reproduction Code:
n/a

How often has this issue occurred?:

• Always (100%)

[mariokorte]

The highlighted call is the one with the empty content (second call_llm in Orchestrator)

[surajksharma07]

@mariokorte Looks like this is a known behavioral difference introduced in ADK 2.0 — when an LlmAgent is placed as a static Workflow graph node without an explicit mode, the framework silently forces mode='single_turn' and strips the full conversation history.

So after the AgentTool call returns, your orchestrator only sees the function response rather than the original query.

Worth trying as a workaround: add mode='chat' to your orchestrator_agent definition (e.g. Agent(name="orchestrator_agent", mode="chat", ...)).
That should preserve the full context across tool calls and restore the SequentialAgent behavior you're expecting.

Could you verify if that resolves it on your end before we push this as a framework fix?

[mariokorte]

@surajksharma07 That indeed worked on the empty context bit, and the orchestrator does its job, but now the next agent in sequence (in this case the "Response" agent) is not invoked anymore.

So - yeah - this error is gone now, but there's a new one 😅

[surajksharma07]

@mariokorte That side-effect is expected — when mode='chat' is set, the framework skips process_llm_agent_output() (which is single-turn only), so ctx.output is None after the orchestrator node.

The Workflow then passes node_input=None to response_agent, and since response_agent still defaults to single_turn + include_contents='none', it has no user content to act on and effectively produces nothing.

Worth trying: set mode='chat' on response_agent as well — that should let it read from the full shared session history instead of relying on node_input, which is how the old SequentialAgent handoff worked.

Could you verify if that gets both agents working end-to-end ?

[mariokorte]

unfortunately this does not make a difference: the Response agent is not invoked when mode='chat' is added.

[surajksharma07]

@mariokorte the root cause here is that mode='chat' nodes never set ctx.output (process_llm_agent_output() is single-turn only), so response_agent always receives node_input=None and has no user-role content to respond to regardless of its own mode.

A workaround worth trying: insert a small FunctionNode between the two agents that walks ctx.session.events in reverse, finds orchestrator_agent's last text event, and returns it as a string.
That string then arrives as node_input for response_agent and gets properly injected as a user-role message.

Something like:

edges=[("START", orchestrator_agent, extract_output_node, response_agent)]

where extract_output_node is a @node-decorated function reading from the session.

Could you verify if that restores the end-to-end behavior?

[mariokorte]

Next iteration:

Adding a FunctionNode like this:

@node
async def extract_output_node(ctx: Context, node_input: str) -> str:
    """
    Extracts the output node from the session state.
    """
    return None

putting it in-between the two agents like you told me to do.

When orchestrator_agent.mode="chat" this Function never gets called - just like the Responder agent never got invoked.

When I now remove the mode="chat" from Orchestrator the function gets called - AND the responder seems to get the context.

So, it somehow works this way, but I think it's not supposed to be this complicated to migrate from sequential agent.

[surajksharma07]

@mariokorte That's a really useful data point — the fact that mode='chat' blocks the FunctionNode too (not just response_agent) confirms this is a Workflow scheduler-level regression, not just an output-propagation gap. With mode='chat', something in the run loop (likely an unhandled exception setting error_shut_down=True, or long_running_tool_ids being set during the AgentTool call which puts ctx into a WAITING state) prevents _handle_completion() from ever triggering downstream edges — even though sequential edges with route=None are supposed to fire unconditionally per the graph logic.

So to confirm: mode='single_turn' (default) + your FunctionNode bridge is the most stable path forward right now.
It works because process_llm_agent_output() correctly sets ctx.output which flows downstream.

Your point about migration complexity is completely fair — both the chat-mode scheduler blockage and the context loss after AgentTool are framework regressions we'll track for a proper fix.

Flagging these internally!

Team is looking more into it.
Thanks!