Brigade：multi-agent coding に receipts を残す local control plane

今の coding agent 利用は、だんだん一つの tool だけでは済まなくなっている。Claude Code、Codex、Cursor、OpenCode、VS Code、Grok CLI は、それぞれ MCP config、instruction file、memory の置き方、plugin の形が違う。単体で使うなら問題は小さい。だが同じ toolset と context を共有させようとすると、手で同期する text file の山になる。

さらに厄介なのは、agent が自分で「今回はうまくいきました」と言っても、それ自体にはあまり価値がないことだ。本当に残したいのは、どの command を実行したのか、exit code は何だったのか、どの file を変えたのか、ある skill や memory card が次回の作業に本当に役立ったのか、という receipts だ。それがなければ、self-improvement は prompt の積み増しになりやすい。

今日メモしておきたい escoffier-labs/brigade は、この問題に向けた local CLI control plane だ。README の位置づけははっきりしている。Brigade は hosted memory service でも MCP server でもない。local repository の中で .brigade/ state、AGENTS.md、safety rules、handoff、MCP catalog、tool sync plan、verification receipts を管理する。dry-run diff、plain files、no daemon、no lock-in を重視し、multi-agent coding workflow のための audit-friendly な workbench を作ろうとしている。

2026-07-13 時点で GitHub repository API、README、release API、tags API、commits API、languages API、LICENSE から確認できる公開情報では、escoffier-labs/brigade は 59 stars、4 forks。主言語は Python、license は MIT。repository 作成日は 2026-05-13 21:55:58 UTC、最近 push は 2026-07-12 14:59:31 UTC。default branch main の現在の最新 commit は e2547edd、commit time は 2026-07-12 14:51:51 UTC。GitHub Releases page の latest release は v0.21.1 で、公開時刻は 2026-07-09 19:00:29 UTC。Tags page の最新 tag も v0.21.1 だ。

プロジェクト概要

項目	内容
リポジトリ	escoffier-labs/brigade
位置づけ	multi-agent coding workflow 向けの local control plane / receipt system
Stars	59
Forks	4
主言語	Python
ライセンス	MIT
リポジトリ作成日	2026-05-13 21:55:58 UTC
最近 push	2026-07-12 14:59:31 UTC
最新 main commit	e2547edd、2026-07-12 14:51:51 UTC
Latest GitHub release	v0.21.1
主な入口	pipx install brigade-cli、brigade operator quickstart、brigade operator doctor
キーワード	MCP catalog、handoff、memory、file receipts、dry-run diff、local-first

問題は agent が足りないことではなく、それぞれが別の引き出しを持つこと

Brigade の一番直接的な入口は次のような形だ。

pipx install brigade-cli
brigade operator quickstart --target ./my-repo --harnesses codex
brigade operator doctor --target ./my-repo --profile local-operator

README によれば、quickstart は target repository に memory、handoff、local MCP catalog、work loop、guardrails を接続する。default footprint は小さめで、AGENTS.md、SAFETY_RULES.md、handoff template、そして .brigade/ state が中心だ。書き込み前の dry-run も重視している。

この tool の面白さは、「また一つ agent wrapper が増えた」ことではない。agent ecosystem で面倒な部分そのものを一級の問題として扱っていることだ。harness ごとに config file が違う。Claude Code は .mcp.json、Cursor は .cursor/mcp.json、Codex CLI は .codex/config.toml、OpenCode はまた別の形を読む。Brigade は一つの .brigade/mcp.json catalog を持ち、それを各 tool の native config に投影する。

派手ではないが、実用的だ。多くの AI tool 管理は model capability ではなく、「この MCP server は一つの client にしか入っていない」「ある agent の rule file だけ更新し忘れた」「前回の handoff が別 tool の private corner に残った」というところで崩れる。Brigade はその corner を local files として並べ直そうとしている。

self-evaluation より receipts が重要

README で一番注目したいのは “prove” と “improve” の二層だ。Brigade は verify run --capture で command、real exit code、変更内容を記録し、そのうえで outcome ledger を使い、ある skill や card が本当に work に役立ったかを追う。主張はかなり抑制的だ。skills と cards は real exit code だけで promote / rollback され、model self-score では評価されない。

これは普通の agent memory より少し硬い。memory は「前回の会話要約を入れる」だけになりやすいが、その要約が有用とは限らないし、次回の context を汚すこともある。Brigade は learnable object と verification signal を結びつけようとしている。ある skill が test passing run に役立ったなら positive signal を得る。verification が失敗したなら、model が「役に立ったと思います」と言っても通らない。

latest release v0.21.1 もこの方向を固めている。release note には memory-doctor、search station、tokens station、evidence station、pantry station、Hermes/Grok MCP adapter、そして outcome reconcile / fork の fingerprint-aware promotion ratchet が並ぶ。ざっくり言えば、Brigade は receipts を集めるだけでなく、書き換えられた skill が古い text の実績をそのまま使い続けないようにしている。

ここが Brigade の core feature だと思う。agent を「賢く見せる」のではなく、agent の作業後に、次の loop で使い、検査し、rollback できる evidence を残す。

MCP sync は最も分かりやすい入口

一つだけ試すなら、MCP catalog が一番入りやすいかもしれない。README の例はこうだ。

brigade mcp init
brigade mcp add --name github --command npx \
  --args "-y @modelcontextprotocol/server-github" \
  --env GITHUB_AUTH_ENV=ref:BRIGADE_GITHUB_AUTH_ENV
brigade mcp sync
brigade mcp sync --write

dry-run は各 tool にどの server entry を作る、あるいは更新するかを表示し、--write で初めて merge する。README は Claude Code、Cursor、Codex CLI、Grok CLI、VS Code、OpenCode、Antigravity を target として挙げ、secrets は inline せず variable reference にする、と説明している。

この部分は、すでに複数の agent client を行き来している人に向いている。Brigade の memory や outcome system をすぐ全部採用する必要はない。まずは「multi-harness MCP config synchronizer」として使えるかを見る。その入口で手作業の config copy が減るなら、次に handoff、receipt、station を見ればいい。

世界観はかなり完整で、そのぶん主張も強い

Brigade README には “stations” というまとまりがある。GraphTrail、MiseLedger、Agent Pantry、Content Guard、Skillet、Token Glace などだ。core repository は hub で、外部 sidecar は必要に応じて install する。たとえば GraphTrail は code graph、MiseLedger は evidence ledger、Agent Pantry は cross-machine session / secret sync、Content Guard は secrets と PII scan を担当する。

つまり、これは薄い script ではなく、multi-agent 操作環境のような workflow を作ろうとしている。利点は、share、remember、prove、improve、security scan、token compaction まで置き場所があること。欠点も同じ場所にある。極小 tool だけが欲しい場合、Brigade の concept density は高く感じる。

現実的には、分解できる toolbox として見るのがよいと思う。最初は operator quickstart --dry-run か mcp sync だけ試す。次に handoff と memory を見る。最後に outcome reconcile のような automated promotion / rollback mechanism を評価する。最初から世界観ごと production repository に持ち込まない方がいい。

向いている場面

第一の場面は、複数の coding agent client を使っていて、MCP、rules、handoff、tool config を何度も同期している場合だ。Brigade の catalog / sync はその重複作業を直接狙っている。

第二の場面は、agent の作業に audit trail を残したい場合だ。command、exit code、diff、receipt、outcome ledger は、「model が学んだと言っている」より team environment に向く。

第三の場面は、agent workflow を一回きりの chat から、継続的に改善する local process に変えたい場合だ。Brigade の memory、skills、cards、reconcile はそこに向けて設計されている。

第四の場面は、plain files と CLI-driven workflow を受け入れられる場合だ。Brigade は background daemon に頼らず、hosted dashboard も提供しない。local-first user には利点だが、GUI SaaS を期待する team には違う。

注意したいところ

第一に、project はまだ新しい。59 stars、4 forks で、作成日は 2026-05-13。最近の commit と release は活発だが、外部の採用事例は少ない。まず non-critical repository で検証したい。

第二に、concept が多い。MCP catalog、stations、handoff、memory owner、outcome ledger、receipt、ratchet を理解する必要がある。install したら command が一つだけ、という種類の tool ではない。

第三に、agent instruction と tool config に触れる。dry-run があっても diff は必ず見るべきだ。すでに厳密な AGENTS.md、MCP config、security rules を持つ repository では特にそうだ。

第四に、ecosystem はまだ速く動いている。v0.21.1 の release note だけでも station と adapter の変更が多い。採用するなら version pin し、.brigade/ state を code review の対象にした方がいい。

まとめ

Brigade が捉えているのは、かなり実際的な問題だ。coding agent が単一の chat window から、複数 tool、複数 session、複数 MCP server、複数 memory に広がると、team に必要なのはさらに多くの「ひらめき」ではなく、sync、verify、rollback できる local operation desk になる。

今一つの agent だけを使っているなら、Brigade は少し重く見えるかもしれない。だが、すでに複数の agent config を管理しているなら、あるいは agent の改善を real command result に基づかせたいなら、escoffier-labs/brigade は試験リストに入れる価値がある。まだ early stage だが、方向は明確だ。agent workflow に chat log だけでなく receipts を残す。