Baton
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.
How large can the difference be?
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.
Three representative gaps
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 |
What should improve in a real before/after test?
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/.
The problem
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.”
What this skill changes
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 |
Why it is different
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.