feat(tools): Add AgentDispatcherToolset for runtime agents

[a2105z]

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Related: Dispatch Arbitrary Agents for complex non deterministic workflows #4759

Note: This issue is assigned for internal review. This is a community proposal for design feedback — happy to adjust or close if you’d rather keep the design internal.

Problem:
Static sub_agents must be known at construct time, and AgentTool creates a fresh in-memory session per call. Orchestrators need runtime specialists that can run in the background, in parallel, with persistent follow-ups and completion signaling.

Solution:
AgentDispatcherToolset exposes:

1. dispatch_agent — create a runtime LlmAgent on a persistent child session. Background by default (wait=false) so the orchestrator continues; wait=true for sync. Supports tool_names + skill_names from constructor allowlists/registry.
2. get_agent_result — poll latest status/result.
3. await_agent — wait for background completion (optional timeout).
4. message_agent — follow-up on the same child session.

Also:

• Parallel multi-dispatch via concurrent background tasks
• on_complete sync/async callback
• Shared session_service (parent’s by default) + serializable registry under session.state["_adk_agent_dispatcher"] for rebuild/follow-up

Remaining bounds / non-goals

These are intentional for a reviewable first cut; calling them out so reviewers know what this does not claim:

1. Skills are named + allowlisted, not free-form paths.
   Dispatched agents can only attach skills from skill_allowlist and/or a skill_registry lookup by name. The model cannot load arbitrary filesystem/GCS skill paths. That keeps the surface safer; broader skill discovery can be a follow-up if desired.

2. Cross-process restart needs a durable session service.
   Child sessions and the dispatcher registry are persisted through the configured BaseSessionService. With in-memory services, state dies with the process. For true restart survival, use a durable backend (e.g. database / Vertex session service) shared by parent and children, and reconstruct the toolset with the same allowlists/model.

3. Rebuild still requires the same toolset config.
   After a process restart, follow-ups rebuild the child Runner from session-state metadata (instruction, mode, tool_names, skill_names, etc.). The new process must construct AgentDispatcherToolset with compatible tool_allowlist / skill_allowlist / skill_registry / model so those names resolve.

4. Completion signaling is callback + poll/await, not parent-LLM push mid-turn.
   on_complete notifies application code; the orchestrator LLM observes completion via get_agent_result / await_agent on a later turn. This does not inject a spontaneous model turn into the parent when a background child finishes.

5. Not a replacement for Workflow ctx.run_node.
   This targets chat-style orchestrators that want tool-driven spawn. Graph/Workflow dynamic nodes remain the right primitive for interrupt/resume-heavy workflows.

Testing Plan

Unit Tests:

• Added/updated unit tests
• All unit tests pass locally

pytest tests/unittests/tools/test_agent_dispatcher_toolset.py -v
# 8 passed

Coverage: wait/background/await, parallel dispatch, on_complete callback, persistent message follow-up, rebuild from session state, skill allowlist, unknown tool rejection.

Manual E2E:

adk run contributing/samples/tools/agent_dispatcher

Checklist

• CONTRIBUTING.md
• Self-review
• Comments in hard-to-understand areas
• Tests proving the feature works
• Unit tests pass locally
• Manual E2E
• Dependent changes merged

Additional context

RFC on issue: #4759 (comment)

cc @klateefa @wuliang229 — concrete API sketch for review, not a claim on assigned work.