You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’m working with the ADK TypeScript SDK and I’ve run into a behavior regarding state persistence that I’m trying to better understand.
The Scenario:
I have a parent agent (Agent A) that uses a sub-agent (Agent B) as a tool via AgentTool. Agent B is configured with an outputKey to persist its results into the session state.
What I'm observing:
When I run Agent B standalone, it works perfectly: the result is saved to the outputKey in the session state.
When Agent B is called as a tool by Agent A, it executes and returns the correct response to the parent, but the outputKey in the state is not updated.
It seems like the sub-agent might be running in an isolated or temporary session context (I've noticed some references to temp_user in logs), which prevents it from writing to the "real" parent session state.
My Questions:
Is it the expected behavior that sub-agents in AgentTool have an isolated state?
Is there a specific configuration required to "pass through" or inherit the sessionId and userId from the parent agent to the sub-agent so they share the same state?
Am I perhaps missing a step in how the Runner handles state updates from nested agents?
I’ve tried using afterModel callbacks to manually set the state, but while the state object changes during execution, those changes don't seem to persist back to the main session once the tool finishes.
Any guidance on the "canonical" way to handle shared state in multi-agent architectures would be greatly appreciated!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
I’m working with the ADK TypeScript SDK and I’ve run into a behavior regarding state persistence that I’m trying to better understand.
The Scenario:
I have a parent agent (Agent A) that uses a sub-agent (Agent B) as a tool via AgentTool. Agent B is configured with an outputKey to persist its results into the session state.
What I'm observing:
When I run Agent B standalone, it works perfectly: the result is saved to the outputKey in the session state.
When Agent B is called as a tool by Agent A, it executes and returns the correct response to the parent, but the outputKey in the state is not updated.
It seems like the sub-agent might be running in an isolated or temporary session context (I've noticed some references to temp_user in logs), which prevents it from writing to the "real" parent session state.
My Questions:
Is it the expected behavior that sub-agents in AgentTool have an isolated state?
Is there a specific configuration required to "pass through" or inherit the sessionId and userId from the parent agent to the sub-agent so they share the same state?
Am I perhaps missing a step in how the Runner handles state updates from nested agents?
I’ve tried using afterModel callbacks to manually set the state, but while the state object changes during execution, those changes don't seem to persist back to the main session once the tool finishes.
Any guidance on the "canonical" way to handle shared state in multi-agent architectures would be greatly appreciated!
Beta Was this translation helpful? Give feedback.
All reactions