Salta ai contenuti
← Torna al sito
Soleri | Docs

Tutorial: Your First Subagent Dispatch

Questi contenuti non sono ancora disponibili nella tua lingua.

This tutorial walks you through a real subagent dispatch. You’ll see how the orchestrator decomposes work, routes tasks, dispatches workers, and merges results — all while keeping state clean.

You want to add a CONTRIBUTING.md file to three packages in your monorepo: core, forge, and cli. Each file is independent — different directories, no overlap, no dependencies. Perfect for parallel dispatch.

You: “Add CONTRIBUTING.md files to the core, forge, and cli packages with setup instructions and guidelines.”

The agent recognizes this as 3 independent tasks and activates the subagent-driven-development skill.

Before dispatching anything, the agent reads your existing code, checks the vault for contribution guidelines patterns, and makes all design decisions:

  • What content goes in each file
  • Which conventions to reference (from your project config)
  • File locations

You don’t see this — it’s the orchestrator doing its homework.

Step 3: The agent shows the dispatch table

Section titled “Step 3: The agent shows the dispatch table”

Agent: I’m using the subagent-driven-development skill to dispatch isolated agents.

Dispatching 3 tasks in parallel:

#TaskAgentWhy
1CONTRIBUTING.md for coreWorkerSingle file, clear spec
2CONTRIBUTING.md for forgeWorkerSingle file, clear spec
3CONTRIBUTING.md for cliWorkerSingle file, clear spec

All three are Claude Code workers because they’re single-file tasks with fully decided specs. No design decisions needed.

All three workers launch simultaneously, each in its own git worktree. They create their file and return. They don’t:

  • Create plans
  • Make design decisions
  • Modify other files
  • Commit changes

The orchestrator reads the actual file changes from each worktree — not just the worker’s self-report. It checks:

  • Did the file get created?
  • Does the content match the spec?
  • Were any other files modified? (They shouldn’t be.)

The orchestrator copies the files from each worktree into the main tree, then reports:

✓ 3/3 complete. 0 patterns captured (simple task).
→ Decisions: none — all specs were pre-defined.

The worktrees are automatically removed. Three layers of cleanup ensure nothing accumulates:

  1. Each worktree is removed right after its task completes
  2. A batch cleanup runs after all workers finish
  3. The session-start hook catches anything that slipped through

You can verify with git worktree list — only your main working directory remains.

A worker encounters ambiguity: It returns to the orchestrator with a question. The orchestrator either resolves it or asks you. Then re-dispatches.

A worker modifies the wrong file: The orchestrator catches this during review and re-dispatches a fix subagent (max 2 retries).

A merge conflict: The orchestrator resolves it manually, re-runs tests, and captures the conflict as an anti-pattern for future planning.

A worker fails entirely: The orchestrator reports the failure and either retries or asks you how to proceed.

When to use a Soleri agent instance instead

Section titled “When to use a Soleri agent instance instead”

If one of those packages needed a complex CONTRIBUTING.md that required checking your vault for team conventions, making architectural decisions about the contribution workflow, or touching multiple related files — the orchestrator would route that task to a Soleri agent instance instead of a worker.

The instance would:

  1. Activate with vault and brain access
  2. Search for relevant patterns
  3. Execute the task with full context
  4. Run orchestrate_complete to capture knowledge

You don’t need to specify this — the orchestrator routes automatically.

StepWhat happensWho does it
Research & decideRead files, check vault, make decisionsOrchestrator
RouteClassify each task by complexityOrchestrator
DispatchLaunch workers/instances in parallelOrchestrator
ExecuteCreate files, write codeSubagents
ReviewRead actual changes, verify correctnessOrchestrator
MergeCopy changes to main treeOrchestrator
ReportSummarize results, capture knowledgeOrchestrator
CleanupRemove worktrees, prune branchesAutomatic

The orchestrator does the thinking. The subagents do the work. Nobody freelances.