Skip to main content

AI agent memory, handoffs, and local guardrails for Codex, Claude Code, OpenCode, Hermes, and OpenClaw.

Project description

Brigade

Brigade CLI

One canonical source for the MCP servers, tools, and memory your AI coding agents share, merged into each tool's native config with a review gate and a receipt for every change. Local files, no daemon, no lock-in.

CI status PyPI version Python 3.10+ MIT license

Your agents run loops. Brigade keeps the receipts.

What it does

You run more than one agent CLI. Each one keeps its MCP servers in its own config file, its memory in its own silo, and writes to both without review. Brigade is the local layer that fixes that. You keep one canonical source for your MCP servers, your tool and skill catalog, and your memory, and Brigade merges each into the tools you actually use: MCP servers into each tool's native config, tools and skills projected into each harness, and one shared memory owned in one place. A review gate sits in front of anything that gets written, and every consequential change lands a receipt you can grep, diff, and roll back. No daemon, no hosted service, no vendor lock-in: it writes plain files in your repo when you run a command, and that is all it does.

Try it in 60 seconds

pipx install brigade-cli
pipx ensurepath          # then open a new shell so `brigade` is on PATH
brigade operator quickstart --target ./my-repo --harnesses codex      # wire one repo
brigade operator doctor --target ./my-repo --profile local-operator   # verify

That installs the CLI, wires memory, handoffs, and local guardrails into one repo for a single harness, and prints a readiness check. Nothing leaves your machine and no daemon is started. Add --dry-run to preview the file-by-file plan before anything is written. More harnesses, workspace setups, and the homegrown-adoption path are under Install.

One MCP catalog, synced into every tool

Every agent tool reads its MCP servers from a different file in a different shape. The same servers wired across Claude Code, Cursor, Codex, VS Code, OpenCode, and Antigravity means hand-editing six configs and keeping them in sync forever. Brigade keeps one canonical catalog and merges it into each tool's native config for you.

brigade mcp init                  # scaffold .brigade/mcp.json
brigade mcp add --name github --command npx \
  --args "-y @modelcontextprotocol/server-github" \
  --env GITHUB_TOKEN=ref:GITHUB_TOKEN
brigade mcp sync                  # dry-run: show the diff for every tool
brigade mcp sync --write          # merge into each tool's config

One catalog (.brigade/mcp.json), six native targets:

Tool File it writes
Claude Code .mcp.json
Cursor .cursor/mcp.json
Codex CLI .codex/config.toml (merged surgically, other tables preserved)
VS Code .vscode/mcp.json (secrets become inputs[])
OpenCode opencode.json
Antigravity ~/.gemini/config/mcp_config.json (user-scoped, --user-scope)

It is dry-run by default and never runs from doctor or brief. It merges by server key, so servers you added by hand are never touched, and ones you edited are left alone unless you pass --force. Secrets are written as ${VAR} references (or VS Code ${input:VAR}), never inlined. Ownership is tracked in a gitignored sidecar, so re-syncing on a fresh clone does not spuriously conflict. Full behavior in docs/mcp-sync.md.

Tools and skills get the same treatment: brigade tools sync projects one reviewed catalog into each harness's native format.

brigade mcp requires brigade 0.13.0 or newer (pipx upgrade brigade-cli).

Shared memory, with a guard in front

Writer harnesses leave handoff notes as they work. Brigade lints, guards, and classifies each one, then files the safe, targeted notes into durable memory on its own. A memory owner (OpenClaw, Hermes, or just you) only steps in for the ambiguous few. Every consequential action lands a receipt in a plain file you can grep, diff, and prune.

  1. agents write handoff notes into their own local inboxes
  2. Brigade lints and classifies each one before it can become memory
  3. safe, targeted notes file themselves into durable memory automatically
  4. only the ambiguous or risky few wait for your review
  5. future sessions start with better context, and receipts show what happened
flowchart LR
    WRITERS["writer harnesses<br/>Codex · Claude Code · OpenCode · ..."]
    BRIGADE["Brigade<br/>lint · guard · classify · receipts"]
    OWNER["memory owner<br/>OpenClaw / Hermes / you"]
    MEM["durable memory<br/>MEMORY.md index · memory cards"]
    REVIEW["review inbox<br/>ambiguous · risky"]

    WRITERS -- handoff notes --> BRIGADE --> OWNER
    OWNER -- safe targeted, auto-filed --> MEM
    OWNER -. ambiguous or risky .-> REVIEW
    MEM -. context .-> WRITERS

    classDef brigade fill:#2563eb,stroke:#1d4ed8,color:#fff;
    classDef memory fill:#ecfdf5,stroke:#059669,color:#064e3b;
    classDef gate fill:#fff7ed,stroke:#ea580c,color:#7c2d12;
    class BRIGADE brigade;
    class OWNER,MEM memory;
    class REVIEW gate;

Memory has two layers: knowledge cards under memory/cards/ hold the detail, and MEMORY.md stays a slim one-line-per-card index that loads every session. brigade memory care scan flags stale, contradictory, or undersourced cards for review instead of letting them rot. Brigade never edits canonical memory itself; the owner does the writing. It all runs on the machine you control: laptop, workstation, or VPS.

Verified learning

Filing notes is the first loop. The second loop earns trust. Brigade can promote a learned skill on its own, but only when a real signal proves it helped, and it rolls one back the moment a signal says it broke. The model never grades its own work.

  • brigade outcome capture records the result of a verify run (a real exit code, not an opinion) against the skill that produced it.
  • brigade outcome score ranks each skill by a Wilson lower bound, so something that passed twice never outranks something vetted across twenty runs.
  • brigade outcome reconcile is the gate. Dry-run by default; with --apply it installs a skill that earned it across your harnesses, or rolls a regressed one back to its last good version.
  • brigade outcome explain prints the full signal trail behind any decision: which run produced each result, the threshold it crossed, and the reversible action taken.

The whole ledger is plain JSON and markdown under memory/outcome/, tracked in git and readable without Brigade. Schedule brigade outcome reconcile in your own cron to run it hands-off; Brigade still installs no daemon.

Sidecars

Brigade is the hub. Each station wires an optional standalone tool, installed with brigade add <station> and health-checked by brigade status and brigade doctor. Every tool is its own repo, independently installable, with no library coupling back into Brigade.

brigade add Tool What it does
guard content-guard scans handoffs and content for secrets and PII before anything leaves the machine
tokens tokenjuice tracks token spend across your harnesses and compacts noisy output
memory memory-doctor, bootstrap-doctor validates memory cards and bootstrap files for staleness and contradictions
pantry agentpantry syncs browser sessions and auth across an agent's machine
search code-search local semantic code search over your repos
evidence miseledger a local-first evidence ledger with receipts and source exporters

Harness support

Each writer gets its own local inbox; one canonical owner ingests. Brigade keeps the note format consistent so different tools can contribute without inventing their own styles.

Writer Harness id Inbox
Codex CLI codex .codex/memory-handoffs/
Claude Code claude .claude/memory-handoffs/
OpenCode opencode .opencode/memory-handoffs/
Antigravity antigravity .antigravity/memory-handoffs/
Pi pi .pi/memory-handoffs/
Cursor cursor .cursor/memory-handoffs/
Aider aider .aider/memory-handoffs/
Goose goose .goose/memory-handoffs/
Continue continue .continue/memory-handoffs/
GitHub Copilot CLI copilot .copilot/memory-handoffs/
Qwen Code qwen .qwen/memory-handoffs/
Kimi Code kimi .kimi/memory-handoffs/
AdaL adal .adal/memory-handoffs/
OpenHands openhands .openhands/memory-handoffs/
Grok CLI grok .grok/memory-handoffs/
Amp amp .amp/memory-handoffs/
Crush crush .crush/memory-handoffs/
Hermes hermes .hermes/memory-handoffs/
OpenClaw openclaw usually the memory owner, not a writer

All of them get handoff templates and ingest source coverage. Most also get projected tools and skills in their native format; the per-harness matrix is in the technical guide. Hermes is validated against a real install: handoffs land in .hermes/memory-handoffs/, and reviewed skills install into your Hermes store (~/.hermes/skills).

More

The same review-and-receipt pattern covers the rest of an operator's day, and you can ignore all of it until you need it.

  • Cross-model runs: brigade run "<task>" plans, dispatches, and synthesizes one bounded task across the agent CLIs in your roster, so an expensive model can think while cheaper ones do the grunt work. --worktree runs everything in a detached git checkout that comes back as a reviewable changes.patch.
  • Daily loop: brigade work brief shows pending work, imports, and warnings; brigade daily status keeps it bounded and cheap.
  • Friction logs: brigade friction scan mines recent notes, handoffs, and session artifacts for reviewable workflow friction.
  • Security and scrub: brigade security scan is a local read-only scanner for agent workspaces; brigade scrub gates content before it leaves the machine.
  • Research: brigade research run turns a question into a cited local report and a reviewable memory handoff.
  • Fleet and release: health evidence across your local repos and release-readiness receipts, with no publish step.

The full tour of every station lives in docs/overview.md.

Why not something else?

  • mem0, Letta, and friends are memory layers for apps you are building, usually behind an API or a server. Brigade is for the agent CLIs you already run, and it is file-first: your memory is markdown in your repo, reviewable in git, readable without Brigade.
  • Native harness memory (each tool's own auto-memory) is a per-tool silo. It does not cross harnesses, and it writes without review. Brigade gives every tool one shared format and one canonical owner, with a review gate in between.
  • Already running Hermes, or any self-improving agent? Keep it. Brigade is not a replacement, it is the verification layer on top. A built-in learning loop grades its own work and keeps what it learns inside one tool. Brigade promotes a skill only when a real signal confirms it, keeps every learned skill as portable markdown in your git, and runs one loop across your whole fleet.
  • A plain CLAUDE.md / AGENTS.md works great until it bloats past the context budget and goes stale. Brigade keeps bootstrap files slim, moves detail into indexed cards, and flags staleness instead of trusting last month's facts forever.
  • A daemon or hosted service would be simpler to demo and worse to trust. Brigade writes local files when you run a command, and that is all it does.

What Brigade is not

Brigade is not a hosted memory service, a daemon, or an automatic release bot.

It does not:

  • run in the background or install schedulers
  • push to GitHub or publish packages
  • send notifications by default
  • save every note automatically
  • turn memory ingest into a silent background process
  • skip review for ambiguous, risky, or failed notes

That pause is the point. Agent memory should be useful, not noisy.

Install

brigade operator quickstart (in Try it in 60 seconds) wires one code repo for one harness. For an OpenClaw or Hermes workspace instead:

brigade operator quickstart --target ~/agent-workspace --depth workspace --harnesses openclaw,hermes --owner openclaw

Use --dry-run first to preview the planned steps without writing anything. Pass more harnesses as a comma-separated list; quickstart only wires the harnesses you select and leaves the rest alone.

Write a handoff and check the wiring:

brigade handoff draft --target ./my-repo --inbox codex \
  --title "What changed" \
  --summary "Short note future agents should know." \
  --content "The durable note itself goes here."
brigade handoff lint --target ./my-repo
brigade handoff doctor --target ./my-repo

New here? Start with QUICKSTART.md for the five-minute install, then docs/first-10-minutes.md for the guided first session. Already have a homegrown setup with scripts, crons, and handoff folders? Brigade has an adoption path that inventories what you have before changing anything: start with brigade operator adopt plan and see the technical guide. Want an agent to set this up for you? Point it at this repo; AGENTS.md tells it exactly what to do and where to stop.

Why I built this

I run an always-on OpenClaw agent next to daily Codex and Claude Code sessions. Every one of those tools wakes up empty, and whatever a session learned scattered across tool-specific folders and died there. Two incidents shaped the design: a "dreaming" job that promoted raw session fragments straight into memory bloated MEMORY.md past the bootstrap budget, so every session started truncated and nobody noticed for weeks; and 195 handoff notes that sat unread across 35 repos because an ingester had a hardcoded allowlist and nothing warned about the gap. Silence is the failure mode. Every part of Brigade that lints, warns, or writes a receipt exists because something once failed in silence. The full production stack, now 482 cards across daily multi-agent work, is documented in the solos-cookbook.

Docs

Project identity: GitHub escoffier-labs/brigade, website brigade.tools, PyPI brigade-cli, command brigade. The name comes from the kitchen: a brigade de cuisine runs the line, and mise en place means the station is prepped before service. Set up the rules, memory, tools, and receipts before the session gets expensive.

It is early-stage and moving fast. If you hit a broken workflow, a confusing command, or a setup issue, open an issue and I will get it fixed.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

brigade_cli-0.13.0.tar.gz (896.8 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

brigade_cli-0.13.0-py3-none-any.whl (773.2 kB view details)

Uploaded Python 3

File details

Details for the file brigade_cli-0.13.0.tar.gz.

File metadata

  • Download URL: brigade_cli-0.13.0.tar.gz
  • Upload date:
  • Size: 896.8 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for brigade_cli-0.13.0.tar.gz
Algorithm Hash digest
SHA256 246fc49a480883cc9955ecf601c8180241741272af2bb9a97e20f59d7fa063bf
MD5 e78e06dd3366d72e355c13d6e8ae077d
BLAKE2b-256 ff6ed16e146b7ed27e757f71b70b1edd4090a492f124c88c3c1ec6c88288b052

See more details on using hashes here.

Provenance

The following attestation bundles were made for brigade_cli-0.13.0.tar.gz:

Publisher: publish.yml on escoffier-labs/brigade

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file brigade_cli-0.13.0-py3-none-any.whl.

File metadata

  • Download URL: brigade_cli-0.13.0-py3-none-any.whl
  • Upload date:
  • Size: 773.2 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for brigade_cli-0.13.0-py3-none-any.whl
Algorithm Hash digest
SHA256 89ae87c1dda404afffc91475f369f0c834cadd1381d9ade4492aed2da01f6064
MD5 64e052d73d5a1aa0a8ab62d383994935
BLAKE2b-256 d9dd060d759b4f1b7f3d28463ec551cfb6e482067e3304a8a6cb30cfe02c1ffd

See more details on using hashes here.

Provenance

The following attestation bundles were made for brigade_cli-0.13.0-py3-none-any.whl:

Publisher: publish.yml on escoffier-labs/brigade

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page