Skip to main content

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

Project description

Brigade

Brigade CLI

AI agent memory, handoffs, and local guardrails for Codex, Claude Code, OpenCode, and over a dozen other harnesses.

CI status PyPI version Python 3.10+ MIT license

Your agents run loops. Brigade keeps the receipts.

Try it in 60 seconds

pipx install brigade-cli
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.

Why I built this

I run an always-on OpenClaw agent next to daily Codex and Claude Code sessions, and I have since January. Every one of those tools wakes up empty. Whatever a session learned about my machine, my rules, or yesterday's dead ends scattered across tool-specific folders and died there.

So I hand-rolled the fixes, one incident at a time: a slim MEMORY.md index pointing at small memory cards instead of one giant file, a handoff note format every harness could write, an ingest cron that filed the good notes into durable memory every 30 minutes, staleness checks so old cards stopped being trusted forever.

Two incidents shaped the design more than anything I planned. First, a nightly "dreaming" job that promoted raw session fragments straight into memory bloated MEMORY.md to 41KB, way past the 12KB bootstrap budget, so every session started with truncated memory and nobody noticed for weeks. Blind auto-promotion died that day. Now nothing reaches memory unlinted: a note has to name a target and clear the guards, the safe ones file themselves, and only the risky few wait for review. Second, I found 195 handoff notes sitting unread across 35 repos because the ingester had a hardcoded three-repo allowlist and nothing warned about the coverage gap. Silence is the failure mode. Every part of Brigade that lints, warns, or writes a receipt exists because something once failed in silence.

That system now runs 482 memory cards and survives daily multi-agent work. But explaining it to anyone meant: clone six repos, write these crons, keep your index slim, watch for staleness, and never let a note reach memory unlinted. Brigade is that setup packaged as one installable CLI. The full production stack is documented in the solos-cookbook if you want to see where it came from.

The loop

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. Local by default, loud about the exceptions.

Install

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

For an OpenClaw or Hermes workspace instead of a code repo:

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; brigade init --target ./my-repo --harnesses codex --dry-run shows the full file-by-file list. 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.

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 (some as rules or instructions, a few not yet); the per-harness matrix is in the technical guide.

Beyond memory

The memory loop is the core. Around it, 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:

  • Daily loop: brigade work brief shows pending work, imports, and warnings; brigade daily status keeps it bounded and cheap.
  • Friction logs: brigade friction scan --days 30 --import-candidates mines recent notes, handoffs, session artifacts, and optional local agent logs for reviewable workflow friction.
  • Security: brigade security scan is a local read-only scanner for agent workspaces (secrets, risky hooks, MCP configs, prompt-injection patterns); brigade scrub gates content before it leaves the machine.
  • Tools and skills: one reviewed catalog projected into every harness's native format, with approval gates for anything that executes.
  • Research: brigade research run turns a question into a cited local report and a reviewable memory handoff.
  • 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. Rosters pin a model per agent, plans can stage dependent workers, and --worktree runs everything in a detached git checkout that comes back as a reviewable changes.patch. A dirty-tree guard and a run lock keep agents away from your work in progress.
  • 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.
  • A plain CLAUDE.md / AGENTS.md works great until it bloats past the context budget and goes stale. Brigade exists because mine hit 41KB. It 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.

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.12.0.tar.gz (857.5 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.12.0-py3-none-any.whl (744.7 kB view details)

Uploaded Python 3

File details

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

File metadata

  • Download URL: brigade_cli-0.12.0.tar.gz
  • Upload date:
  • Size: 857.5 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.12.0.tar.gz
Algorithm Hash digest
SHA256 65e920883f166c3c15ce3a750f91e4789fbc8f65293f07fe73d3d9abe353c6bb
MD5 52ff2d496d983e9c8ed0ac5eff5c6e8c
BLAKE2b-256 43083f1cc10b884665cdeeb9d6dc83109585208744f4e418524835d922373e2c

See more details on using hashes here.

Provenance

The following attestation bundles were made for brigade_cli-0.12.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.12.0-py3-none-any.whl.

File metadata

  • Download URL: brigade_cli-0.12.0-py3-none-any.whl
  • Upload date:
  • Size: 744.7 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.12.0-py3-none-any.whl
Algorithm Hash digest
SHA256 0f36172a9fb547f9888620d9319d7f4d286438d54acae2aa809aca106491e199
MD5 0de968ed8e766a27707e484f9fbe47b4
BLAKE2b-256 fd609b7bc8550193d2e89b752e80e9bd58e35083b1be40b151750dbcb3a18191

See more details on using hashes here.

Provenance

The following attestation bundles were made for brigade_cli-0.12.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