When a process dispatches an agent task with external: true, the effect resolution pipeline must route through adapters instead of the internal agent-core session. Most of the infrastructure already exists in agent-platform's adapterBridge.

Extend the agent task kind with responderType routing metadata so tasks-adapter can route work to an internal responder, human, external agent, tracker, or automatic choice. This supersedes the older 603 external: true proposal.

Allow babysitter processes to discover what agents and models are available in the environment and dispatch work to them. When adapters is installed, processes gain access to external agents (claude-code, codex, gemini-cli, copilot, etc.) as first-class task targets alongside the internal genty-core session.

When babysitter runs as a plugin inside another agent (claude-code, codex, gemini-cli, copilot), the SDK operates in "plugin mode" — effects are delegated to the host agent, capabilities are discovered via environment variables, and the hook lifecycle is driven by hooks-adapter.

Update process creation prompts, templates, and validation to expose external agent capabilities when adapters is detected. The LLM authoring the process should know what agents are available and how to use them.

Add an optional discovery layer to the SDK that detects adapters availability and queries installed agents, supported models, and capabilities. This data feeds into process creation context.

Instead of the SDK talking to adapters directly, tasks-adapter becomes the single routing layer for all task dispatch — human responders, adapters adapters, and external issue trackers. The SDK only needs to know about tasks-adapter.

Runtime effect-routing tests are part of the tasks-adapter follow-up work. The SDK