async-agent-dispatch

name	async-agent-dispatch
model	sonnet
description	Produces a structured background-dispatch handoff — task description, output contract, success criteria, and timeout — so long-running work completes without blocking the user. Use when: "run this in the background", "dispatch agent for long task", "I need this to run async", "parallel agent dispatch".
category	agent-orchestration
triggers	["run this in the background","dispatch agent for long task","I need this to run async","parallel agent dispatch"]
tier	1
agents	["primary"]
tool_dependencies	["file_system"]
inputs	[{"name":"task_description","type":"string","description":"Description of the long-running task to dispatch","required":true},{"name":"expected_duration_minutes","type":"number","description":"Estimated task duration in minutes","required":false}]
outputs	[{"name":"dispatch_plan","type":"string","description":"Structured handoff block with task description, output contract, success criteria, and timeout"}]

Async Agent Dispatch

I. Philosophy

The user's attention is the scarcest resource. Long tasks that block interaction waste it. Background dispatch turns sequential bottlenecks into parallel throughput -- but only if the handoff is clean enough that results integrate without re-explanation.

The key insight is the control plane / data plane separation: the foreground agent manages intent and coordination (control plane), while background agents execute work and produce artifacts (data plane). A clean boundary between them means neither blocks the other.

This is not about making things faster. It is about making long work invisible to the user until results are ready.

II. When to Use

• Task will take more than 2 minutes (large codebase scans, multi-file generation, test suites)
• User needs to continue interacting while work proceeds
• Multiple independent tasks can run in parallel
• Task produces file artifacts that can be read after completion
• Work is well-defined enough to run without mid-task clarification

Do NOT use when:

• Task requires iterative user feedback during execution
• Task is under 2 minutes (overhead of dispatch exceeds benefit)
• Task modifies shared state that the foreground agent also reads
• Results need real-time streaming to the user (use foreground with progress updates)
• Task definition is ambiguous and likely to need clarification

III. Workflow

Step 1: Classify Task Duration

Before dispatching, estimate whether background execution is warranted:

Duration	Mode	Rationale
< 30 seconds	Foreground, inline	Dispatch overhead exceeds task time
30s - 2 min	Foreground, with progress	User can wait if they see movement
2 - 10 min	Background, single agent	Clear win for async dispatch
10+ min	Background, consider splitting	May benefit from parallel tracks

Heuristics for estimation:

• File count * 0.5s per file for read-heavy tasks
• Test count * 2s per test for test suites
• API calls * latency per call for network-bound work

Step 2: Choose Dispatch Mode

Option A: Bash with run_in_background=true Best for: shell commands, build processes, test suites, scripts. The command runs in background and you receive a notification when complete.