baton

KO | EN

gitlite — search

#python #llm #go #golang #rust #linux #docker #windows #awesome #cli #vue #awesome-list #security #openai

(★ 66)

Dispatch less. Deliver more. Multi-agent dispatch governance for reliable delivery.

baton 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Baton

**English** | [繁體中文](README.zh-TW.md)

![Baton — Dispatch less. Deliver more.](https://raw.githubusercontent.com/cablate/baton/main/assets/baton-banner.png)

> **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**.

[![GitHub stars](https://img.shields.io/github/stars/cablate/baton?style=social)](https://github.com/cablate/baton/stargazers)
[![GitHub forks](https://img.shields.io/github/forks/cablate/baton?style=social)](https://github.com/cablate/baton/forks)
[![MIT License](https://img.shields.io/badge/license-MIT-blue.svg)](https://raw.githubusercontent.com/cablate/baton/main/LICENSE)

[Install Baton](#installation) · [Run the smoke tests](install/SMOKE-TESTS.md) · [Benchmark protocol](benchmarks/README.md) · [Trust & security](docs/TRUST.md) · [Changelog](CHANGELOG.md)

**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:

```text
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:

1. total tokens or model cost;
2. elapsed time to a **verified** result, not merely first output;
3. repeated reads of shared sources;
4. overlapping writes, merge conflicts, or reverted work;
5. 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/](benchmarks/README.md).

## 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

```text
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.

## Core operating model

### 1. Apply the dispatch brake

Before fan-out, require five answers:

1. What observable outcome counts as done?
2. Why is delegation better than direct execution?
3. Which workstreams can progress independently?
4. Can every writable artifact have one owner?
5. Who will synthesize and verify the final result?

If an answer is missing, clarify, scout, converge the shared contract, or design ownership first.

### 2. Choose the minimum useful primitive

| 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 |

### 3. Make context and ownership explicit

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.

### 4. Separate production from verification

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**.

### 5. Stop deliberately

Every delegated phase stops on success, budget exhaustion, repeated no-progress, same-cause failure, invalid ownership boundaries, or integration cost exceeding remaining benefit.

## Optional capability adapters

The core skill is platform-neutral. Adapters are loaded only when relevant.

### Claude Code / Ultracode Workflow

The [Ultracode adapter](references/claude-code-ultracode.md) 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.

### CodeGraph

The [CodeGraph adapter](references/codegraph.md) uses repository-graph evidence at three points:

1. build bounded task context;
2. improve impact and ownership maps through caller and dependency analysis;
3. 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.

## Installation

### Approval-gated agent install

For the safest path, ask your agent to inspect the versioned runbook, show an exact plan, and wait for approval before writing:

```text
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](install/MANIFEST.md) and [trust boundary](docs/TRUST.md) first.

### Manual install

Clone the tagged release into the skill directory used by your agent harness:

```bash
git clone --branch v0.1.1 --depth 1 https://github.com/cablate/baton.git baton-dispatch
```

Then 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](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](install/SMOKE-TESTS.md). To update, repeat the runbook with a newer tag after reviewing [CHANGELOG.md](CHANGELOG.md). To remove Baton, follow [UNINSTALL.md](install/UNINSTALL.md).

## Usage

Invoke it explicitly when planning complex execution:

```text
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:

```text
Use $baton-dispatch before launching Ultracode. Start with
a small slice and show me the dispatch design.
```

```text
Use $baton-dispatch with CodeGraph evidence to divide this
repository refactor without overlapping writes.
```

```text
Use $baton-dispatch to audit this proposed multi-agent plan
for context duplication, verification waste, and integration risk.
```

## Repository structure

```text
.
├── 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/
```

## Research basis

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](https://www.anthropic.com/engineering/multi-agent-research-system) — parallel research gains, orchestrator-worker design, coordination limits, and token cost.
- Anthropic, [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) — context as a finite resource with diminishing returns.
- OpenAI Agents SDK, [Agent orchestration](https://openai.github.io/openai-agents-python/multi_agent/) — manager agents, handoffs, and deterministic code orchestration.
- LangChain, [Multi-agent systems](https://docs.langchain.com/oss/python/langchain/multi-agent) — subagents, handoffs, routers, skills, custom workflows, and context engineering.
- Microsoft AutoGen, [Multi-agent design patterns](https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/design-patterns/intro.html) — concurrent, sequential, handoff, group-chat, debate, and reflection patterns.
- CrewAI, [Flows](https://docs.crewai.com/en/concepts/flows) — stateful event-driven workflows and control flow.
- CodeGraph, [local code knowledge graph](https://github.com/colbymchenry/codegraph) — repository indexing, graph context, and local code intelligence for agents.

## Design principles

- **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.**

## License

baton

baton 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

baton

baton 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README