English | 繁體中文
Dispatch less. Deliver more.
A governance skill for deciding whether to delegate, how to divide the work, how far to parallelize, and how to bring the result back under control.
Install Baton · Run the smoke tests · Benchmark protocol · Trust & security · Changelog
More agents do not automatically mean faster delivery.
Subagents often reread the same documents and code, only to perform slightly different work. That means duplicated tokens, overlapping writes, repeated verification, and more results for the main agent to reconcile.
Baton makes an AI answer the important questions before delegation: Is delegation worth the cost? Which work can safely run in parallel? Which context should be shared? Who owns each write, verification step, and final decision?
Baton does not help an AI dispatch more agents. It helps every dispatch earn its cost.
Technically, Baton adds a dispatch control plane above subagents, workflows, agent teams, worktrees, and code-intelligence tools. It guides the AI toward the smallest reliable execution structure, then applies context boundaries, artifact ownership, stop conditions, centralized verification, and final synthesis.
It is not a swarm framework. It is the judgment layer that prevents a swarm from becoming the default answer to every large-looking task.
Star this repository if your agents can already spawn workers but still need better judgment about when, where, and how to use them. Fork it when you want to encode your own platform limits, review gates, ownership rules, or workflow adapters without rebuilding the dispatch model from scratch.
There is no honest universal multiplier. The impact ranges from negligible on a task that was already well scoped to run-saving when an ungoverned workflow would have produced conflicts, retry cascades, or results too expensive to verify.
The strongest published boundary condition comes from Anthropic: multi-agent systems can outperform a single agent on highly parallel research, but Anthropic reports roughly 15× the token use of ordinary chat interactions and warns that heavily shared context and inter-agent dependencies are poor fits. This skill is designed to protect that large coordination investment.
Think of total execution cost as:
useful work
+ repeated context reconstruction
+ coordination and handoffs
+ duplicated verification
+ conflict rework
+ failed retries
+ synthesis debt
The skill cannot make the useful work disappear. Its job is to reduce the other six terms—and to refuse multi-agent execution when those terms would exceed the benefit.
These are operational models, not benchmark claims:
| Scenario | Without dispatch governance | With this skill | Practical difference |
|---|---|---|---|
| Known one-file fix | Investigator → builder → verifier, each rebuilding context | Main agent edits and runs one focused check | Avoids unnecessary cold starts, handoffs, and review overhead |
| Multi-surface refactor | Builders independently discover architecture and collide on shared types, registries, or lockfiles | Shared contract converges first; each artifact has one owner; integration gate runs once | Often the difference between clean parallel progress and conflict-driven rework |
| Large homogeneous audit or migration | Item count becomes agent count; strict output failures and rate limits amplify retries | Representative small slice → bounded batches → explicit failure threshold → centralized synthesis | Often the difference between a controllable run and an expensive result set that cannot be trusted |
Measure the same task twice and compare:
- total tokens or model cost;
- elapsed time to a verified result, not merely first output;
- repeated reads of shared sources;
- overlapping writes, merge conflicts, or reverted work;
- duplicate repository-wide verification and silently missing results.
Expected direction:
- On small or tightly coupled work, the skill should choose fewer agents and sharply reduce coordination overhead.
- On genuinely independent work, it should preserve parallel speed while reducing repeated context and verification.
- On high-risk workflows, its largest value may be preventing a failed run rather than making a successful run marginally faster.
- If an existing agent already makes all of these decisions well, the measurable delta should be small. In that case, the skill still makes the policy explicit, reviewable, and portable.
That last point matters: this repository is not claiming that every multi-agent task becomes faster. It makes the decision auditable enough to discover when multi-agent execution is actually worth its cost.
Benchmark status: the first reproducible protocol is published, but paired trials have not yet been run. Baton does not claim a measured savings percentage until raw evidence exists. See benchmarks/.
Most agent platforms are optimized to answer:
How can I run multiple agents?
The harder operational question is:
Should this task use multiple agents at all—and if so, what is the minimum reliable design?
Without an explicit dispatch policy, capable agents repeatedly fall into the same traps:
- delegating a five-minute fix to three cold-start workers;
- asking every worker to reread the same architecture;
- parallelizing work that shares contracts, registries, or files;
- scaling an untested prompt or strict schema across a large batch;
- running the same expensive build or live test in every worker;
- treating worker reports as verified facts;
- silently losing failed or partial results during synthesis;
- continuing to fan out after integration becomes the bottleneck.
Anthropic's published multi-agent research is unusually candid about this tradeoff: its multi-agent research system achieved major quality gains on highly parallel research, but used roughly 15× the tokens of ordinary chat interactions, and Anthropic notes that tasks with heavily shared context or inter-agent dependencies are poor fits. The lesson is not “avoid multi-agent systems.” It is “spend that coordination budget only where the task shape earns it.”
User request
│
▼
Dispatch brake
├── Is the outcome clear?
├── Is direct execution cheaper?
├── Are workstreams genuinely independent?
├── Can writes have exclusive owners?
└── Who integrates and verifies?
│
▼
Smallest useful primitive
├── main agent
├── one worker
├── bounded parallel workers
├── batch / workflow
├── collaborative team
├── isolated workspace
└── shared-workspace builders
│
▼
Context pack → ownership → briefs → monitored execution
│
▼
Main-agent synthesis → centralized verification → honest evidence
The result is a behavioral change:
| Without this skill | With this skill |
|---|---|
| “This is large; spawn more agents.” | “Which parts are independent enough to justify delegation?” |
| Every worker reconstructs the project | Shared conclusions are curated once and referenced narrowly |
| Work is divided by vague roles | Work is divided by sources, artifacts, and ownership |
| Parallelism follows item count | Parallelism follows independence and integration capacity |
| Builders verify everything independently | Local checks stay local; expensive gates run centrally |
| Reports are concatenated | Conflicts are adjudicated and coverage gaps remain visible |
| Failure triggers more retries | Same-cause failure changes the design or falls back to direct work |
The ecosystem already has excellent orchestration mechanisms:
- OpenAI Agents SDK distinguishes manager-style “agents as tools,” handoffs, and code-driven orchestration.
- LangChain and LangGraph provide subagents, routers, handoffs, skills, and custom graph workflows, with context engineering at the center.
- AutoGen documents concurrent agents, sequential workflows, group chat, handoffs, debate, and reflection patterns.
- CrewAI Flows provides stateful, event-driven control flow with branching and persistence.
- Claude Code and Ultracode-style workflows can execute sophisticated batches and pipelines.
Those systems primarily provide execution primitives. Baton sits one level above them:
| Concern | Orchestration frameworks | This skill |
|---|---|---|
| Run agents, routes, graphs, or flows | Primary strength | Uses what is available |
| Decide whether delegation is economically justified | Usually application-defined | Core responsibility |
| Measure shared-context overlap before fan-out | Sometimes supported | Required decision |
| Assign exclusive artifact ownership | Usually application-defined | Required for writes |
| Centralize verification based on cost | Usually application-defined | Explicit policy |
| Detect integration backlog as a stop signal | Runtime-dependent | Global invariant |
| Preserve failed and minority results in synthesis | Implementation-dependent | Explicit reporting rule |
| Fall back cleanly when orchestration fails | Application-dependent | Mandatory exit |
The advantage is composability: this skill does not compete with an agent runtime. It improves the decisions made before and during runtime use.
Before fan-out, require five answers:
- What observable outcome counts as done?
- Why is delegation better than direct execution?
- Which workstreams can progress independently?
- Can every writable artifact have one owner?
- Who will synthesize and verify the final result?
If an answer is missing, clarify, scout, converge the shared contract, or design ownership first.
| Task shape | Preferred primitive |
|---|---|
| Small task, final judgment, synthesis | Main agent |
| Bounded scouting or independent validation | One worker |
| A few low-overlap perspectives or surfaces | Bounded parallel workers |
| Repeated homogeneous items | Batch or workflow |
| Workers must challenge or coordinate | Collaborative team |
| Competing or overlapping implementations | Isolated workspace or branch |
| Shared uncommitted state, disjoint writes | Shared-workspace builders |
For work with shared background, create a compact context pack containing conclusions, constraints, rejected directions, and minimum reading sets. For write tasks, create an ownership map that names allowed and forbidden artifacts—including secondary writes such as indexes, generated files, configuration, and lockfiles.
Workers produce scoped changes or findings. The main agent checks ownership, samples evidence, adjudicates contradictions, and runs integration-wide verification once. Results are classified as:
- verified;
- consistent but not independently rechecked;
- reasoned but unverified;
- needs human testing.
Every delegated phase stops on success, budget exhaustion, repeated no-progress, same-cause failure, invalid ownership boundaries, or integration cost exceeding remaining benefit.
The core skill is platform-neutral. Adapters are loaded only when relevant.
The Ultracode adapter improves workflow use without freezing this skill to a particular Claude Code version. It requires current-capability discovery, a representative small-slice trial, bounded batches, phase boundaries, stop conditions, explicit treatment of partial results, and a direct-execution fallback.
This is especially valuable when “Ultracode” would otherwise be interpreted as permission to maximize fan-out.
The CodeGraph adapter uses repository-graph evidence at three points:
- build bounded task context;
- improve impact and ownership maps through caller and dependency analysis;
- select affected tests from the actual changed-file set.
CodeGraph improves the evidence available to the dispatcher. It does not replace source verification or artifact ownership.
For the safest path, ask your agent to inspect the versioned runbook, show an exact plan, and wait for approval before writing:
Read https://raw.githubusercontent.com/cablate/baton/v0.1.1/install/AGENT-INSTALL.md
and prepare a plan to install Baton as $baton-dispatch.
Inspect my current skill directories first. Do not overwrite existing files.
Show the source, destination, changed files, non-changes, and verification steps.
Wait for my approval before writing anything.
The runbook is idempotent, refuses to overwrite modified or unrelated directories, and installs only one baton-dispatch skill directory. Review the exact installation manifest and trust boundary first.
Clone the tagged release into the skill directory used by your agent harness:
git clone --branch v0.1.1 --depth 1 https://github.com/cablate/baton.git baton-dispatchThen place or link the cloned folder where your environment discovers SKILL.md packages. Common examples include a personal skills directory or a project-local skills directory. Exact discovery paths vary by product, so follow the current documentation for your harness.
The installable skill entrypoint is SKILL.md. Human-facing documentation such as this README is not required at runtime.
After installation, start a fresh session if your product caches skill discovery, then run the three smoke tests. To update, repeat the runbook with a newer tag after reviewing CHANGELOG.md. To remove Baton, follow UNINSTALL.md.
Invoke it explicitly when planning complex execution:
Use $baton-dispatch to decide whether this migration should
use direct execution, workers, a workflow, or isolated branches. Include
ownership, verification, synthesis, and stop conditions.
Other useful prompts:
Use $baton-dispatch before launching Ultracode. Start with
a small slice and show me the dispatch design.
Use $baton-dispatch with CodeGraph evidence to divide this
repository refactor without overlapping writes.
Use $baton-dispatch to audit this proposed multi-agent plan
for context duplication, verification waste, and integration risk.
.
├── SKILL.md
├── VERSION
├── agents/
│ └── openai.yaml
├── references/
├── dispatch-planning.md
├── context-and-briefs.md
├── execution-and-verification.md
├── examples.md
├── claude-code-ultracode.md
└── codegraph.md
├── install/
│ ├── AGENT-INSTALL.md
│ ├── MANIFEST.md
│ ├── SMOKE-TESTS.md
│ └── UNINSTALL.md
├── benchmarks/
└── docs/
This skill synthesizes recurring lessons from agent orchestration, context engineering, and production workflow systems. Recommended primary sources:
- Anthropic, How we built our multi-agent research system — parallel research gains, orchestrator-worker design, coordination limits, and token cost.
- Anthropic, Effective context engineering for AI agents — context as a finite resource with diminishing returns.
- OpenAI Agents SDK, Agent orchestration — manager agents, handoffs, and deterministic code orchestration.
- LangChain, Multi-agent systems — subagents, handoffs, routers, skills, custom workflows, and context engineering.
- Microsoft AutoGen, Multi-agent design patterns — concurrent, sequential, handoff, group-chat, debate, and reflection patterns.
- CrewAI, Flows — stateful event-driven workflows and control flow.
- CodeGraph, local code knowledge graph — repository indexing, graph context, and local code intelligence for agents.
- Dispatch is a costed decision, not a display of effort.
- Parallelize independent work, not merely divisible-looking work.
- Share conclusions; do not multiply rediscovery.
- Own artifacts explicitly before writing concurrently.
- Verification is part of orchestration design.
- The main agent owns synthesis and truth claims.
- A clean fallback to direct execution is a feature.
MIT © 2026 CabLate. See LICENSE.