Skip to content

AgentTool: option to propagate parent conversation history to child session #6019

@GiulioCMSanto

Description

@GiulioCMSanto

🔴 Required Information

Is your feature request related to a specific problem?

The problem is the following: AgentTool starts the child agent with a blank session. The child only sees args["request"], which is a string generated by the parent LLM and, therefore, that is rephrased. This means the following:

  • The child has no idea what the user actually said in prior turns.
  • Emphasis and constraints can get lost in the parent's rephrasing (For example, imagine the user said something like "MUST have 2 bedrooms, won't compromise" can become "find apartment with 2 bedrooms").
  • This also impact LLM-oriented Confirmation flows and multi-turn extraction tasks, because the child can't reference earlier messages.

Today the only workaround is subclassing AgentTool and manually injecting parent events into the child session — multiple people have done this independently (see #3878, where a contributor built a ContextAwareAgentTool and noted "For a long-term solution, we need a new pattern to be established in ADK").

PS: Although sub_agents share conversation context, they have fundamentally different dynamics — a sub-agent takes over the conversation via transfer_to_agent and the parent is out of the loop until control returns. AgentTool is the opposite: the parent calls the child, gets a result, and continues its own reasoning. It's a tool call, not a handoff. These are two distinct interaction patterns, and the tool-call pattern would benefit from optionally having conversation history available without changing its control-flow semantics.

Describe the Solution You'd Like

A new opt-in boolean on AgentTool:

AgentTool(agent=my_agent, propagate_conversation_history=True)

When True, user/model text events from the parent session are copied into the child's ephemeral session before execution. Same pattern as the existing propagate_grounding_metadata and include_plugins flags.

Key constraints:

  • Defaults to False — existing behavior unchanged.
  • Excludes function_call/function_response events (they'd reference tools the child doesn't have).
  • Creates fresh Event objects (no state_delta leakage).
  • Filters out thought parts.

Impact on your work

We have production agents where a parent routes to specialized tool agents for extraction tasks. Without conversation context, the tool agents consistently misclassify user intent. The subclass workaround works but breaks on ADK upgrades. A first-class parameter would let us remove fragile internal-API dependencies.

Willingness to contribute

Yes — I have a working implementation with tests and will open a PR right away.


🟡 Recommended Information

Describe Alternatives You've Considered

Alternative Why it doesn't work
sub_agents (handoff) Transfers full control to the child — parent can never route again. Incompatible with AgentTool's call-and-return contract.
mode='chat' Has unresolved scheduler bugs (#5780), only applies to LlmAgent callers, and changes semantics (multi-turn vs. single-turn with context).
Persistent sessions (PR #2849, closed) Solves a different problem (cross-invocation caching). We only need current-call context injection — no lifecycle or cleanup concerns.
Subclass workaround Brittle — duplicates framework internals, breaks on upstream refactors.

Proposed API / Implementation

The implementation is ~30 lines of new code, following the propagate_grounding_metadata pattern exactly:

  1. New kwarg on AgentTool.__init__ and _TaskAgentTool.__init__
  2. A small _inject_conversation_history helper
  3. A 3-line call site in run_async after create_session

No changes to _SingleTurnAgentTool, AgentToolConfig, or from_config (matching precedent).

Additional Context

Related issues:

Precedent:

  • d689a04fpropagate_grounding_metadata addition
  • 777dba30include_plugins addition

Metadata

Metadata

Assignees

Labels

core[Component] This issue is related to the core interface and implementation
No fields configured for Feature.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions