Spawn cloud subagents from any MCP-capable lead agent.

AgentDispatch is the provider-neutral control plane for long-running agent work. A lead agent calls one MCP tool, gets a durable task handle back, and can keep interacting with the spawned cloud subagent through A2A, MCP, AG-UI, or HTTP metadata when the runtime supports it.

Local agents are great planners. Long-running work needs different execution properties:

• cloud isolation for expensive, slow, or stateful tasks
• durable status, logs, artifacts, cancellation, and cleanup
• named account profiles instead of raw cloud credentials in prompts
• provider portability across AWS, GCP, Azure, Kubernetes, and local runtimes
• native follow-up with the cloud subagent after spawn

V1 targets AWS Bedrock AgentCore Runtime with a cloud-neutral contract:

provider + capability + task_type + target.mode

That means new providers become adapter packages, not new tool names every agent needs to learn.

For copy-paste lead-agent prompts, use the Lead agent prompt kit. For demo paths and claim boundaries, use the Examples index. For a sanitized no-cloud demo transcript plus JSON report, use the Launch evidence workflow. For concrete background-task prompts, use the Use cases playbook.

• Verification matrix explains what local E2E proves and what still requires live AWS.
• Launch evidence shows how to retain local demo, local E2E, npm, and live AWS proof artifacts.
• Live AWS verification is the opt-in runbook for real AgentCore preflight and dispatch evidence.
• Release runbook documents package order, Trusted Publisher setup, and npm provenance.
• The docs repo owns the manual Live AWS Verification workflow for producing the JSON evidence artifact when real AWS secrets are configured.

npm install -g @agent-dispatch/cli
agentdispatch init \
--region us-west-2 \
--runtime-arn arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-runtime \
--protocol a2a
agentdispatch doctor

Then connect your lead agent to @agent-dispatch/mcp-server and ask it to call spawn_cloud_agent for work that should run outside the local session.

AgentDispatch makes cloud delegation feel like a normal agent tool call, while preserving the production properties teams need: account boundaries, durable handles, normalized events, cleanup, artifacts, and a path to multiple clouds.

Good first contribution paths are intentionally concrete:

• Contributor map
• Contributor issue bank
• New provider adapter
• Worker framework integration
• Architecture improvement