Brigade
Coordinate coding agents with local work ledgers, verification receipts, shared memory, and synchronized tools.
Per-dimension scores and reasoning
The evidence presents a local-file authority model: ordinary operations do not start themselves, optional servers remain foreground processes, outbound sends and GitHub enqueueing require explicit actions, runbooks require an operator-supplied --approved flag, and harness projection is previewed before application. The security policy thoroughly documents arbitrary-shell execution, digests and HMACs, key permissions, same-UID exposure, symlink controls, and leak scanning. CI generally limits permissions and includes content and vulnerability checks plus some commit-pinned tooling. Deductions apply because supply-chain controls are uneven: several Actions use version tags rather than immutable commits, while development and optional components require external packages or tools. Rollback exists for promoted skills, projections, and some state, but no uniform recovery guarantee is shown for every write, and key rotation can make old signatures unverifiable. Repository, package, author, and source identities are explicit; the unverified registry identity is treated as unknown rather than suspicious.
The README, package metadata, security policy, and CI describe a broadly coherent local control plane, with atomic claims, receipt verification, locked builds, multi-version and multi-OS checks, and a coverage gate. Failure behavior is unusually explicit, including SIGNATURE-MISMATCH, nonzero verification exits, stale-document diagnostics, and template-audit failures. Deductions reflect versioning complexity: the README calls 0.27 stable and main the 0.28 beta line, pyproject declares 0.28.0, and the security policy still labels the product alpha. Full capability also depends on Git, external agent CLIs, Rust/Go components, optional MCP packages, or cloud services, so availability is not uniform in every environment.
The material directly addresses multi-agent, repository/workspace, multiple-harness, cross-repository, memory, verification, and tool-synchronization scenarios. It clearly separates the local ledger, optional fleet hub, external scheduling, and non-hosted responsibilities. Trigger boundaries are precise: commands or operator scheduling initiate activity, dangerous runbooks require explicit approval, scout ingestion and projection require --apply, and ambiguous or risky handoffs await review. The environment-fit deduction is due to incomplete parity: CI covers Linux, macOS, Windows, and Python 3.10–3.12, but Windows pytest is allowed to fail, and some scheduling, isolation, shell, and auxiliary-engine behavior is platform- or binary-dependent.
The README has strong installation, scope, comparison, documentation, identity, and licensing structure. Command, distribution, repository, and name-collision identities are stable and explicit. Installation covers pipx, uv, stable/preview channels, and quickstarts, while CI checks source installation across several profiles. A complete MIT license and detailed limitations are present. Deductions apply because the supplied material does not contain a conventional FAQ or a full user-example set, only links and CI-level examples; release information is distributed among the README, roadmap, and update-channel references without a supplied comprehensive changelog. Maintenance has a named author, security contact, acknowledgement target, and fix target, but appears centered on one contact, and enterprise publisher identity remains unverified.
Tasks, atomic claims, receipts, memory handoffs, tool projection, and machine-readable output provide directly usable artifacts for coding agents and operators, with auditable local persistence. Combining these otherwise separate workflows offers plausible marginal value, but the comparative and outcome claims remain project-authored and lack independent effectiveness measurements. The base Python package has no runtime dependencies and is easy to install, yet complete use introduces numerous commands, policies, optional engines, external harnesses, and operational concepts; consequently the cost-benefit case is adequate rather than exhaustively demonstrated.
Claims can be traced to concrete scope statements in the README, the SECURITY threat model, package configuration, and specific CI gates. These sources strongly corroborate installation, version channels, platform targets, audits, receipts, and component boundaries. The deduction is that many feature and competitor-comparison claims point to internal documents not included here or remain first-party assertions, so implementation-level support cannot be checked claim by claim from the supplied files. Fact/inference separation is strong: the text explicitly labels partial and undocumented capabilities, best-effort observations, advisory denylists, non-sandboxing, non-PKI signatures, unenforced budget dimensions, and the limits of its learning model.
- Runbooks execute arbitrary shell on the operator's machine. The --approved flag is a human-review gate, not a sandbox; inspect every command and any referenced scripts, environment behavior, and network content.
- Local digests alone detect ordinary drift. For stronger tamper resistance, use an external key and isolated scanners and retain old keys securely, or historical signatures can become unverifiable.
- The stated stable release is 0.27, while the reviewed revision belongs to the 0.28 beta/alpha development line. Pin a released tag and separately validate optional Rust, Go, MCP, cloud, and platform-specific components.
- Competitor comparisons, effectiveness claims, and several advanced capabilities are chiefly first-party assertions. This was a static review only; no commands, tests, or independent reproductions were run.
What does this agent do, and when should you use it?
Brigade is a local, file-first control plane for organizing coding-agent tasks, handoffs, shared memory, tool configuration, and verification evidence. Its primary interface is the `brigade` CLI for Python 3.10+, backed by a machine-local JSON work ledger and requiring no resident daemon. It computes ready work, uses atomic claims to prevent duplicate assignment, and records check commands, real exit codes, and Git state as verification receipts. Version 0.27 also covers parallel-safe repository waves, cross-repository campaigns, Memory Operations, run lineage, code-graph views, and an optional fleet hub. Work starts only when invoked by a command or an operator-owned scheduler; optional Center, Runs, and Fleet services remain foreground processes, while local journals stay authoritative.
Brigade reads tasks and dependencies from a local JSON work ledger, identifies the unblocked ready set, and assigns items through fail-closed local CAS claims. It partitions work within each repository into parallel-safe waves, while campaigns assemble ready work across repositories at query time. Checks executed through Brigade produce receipts containing the command, actual exit code, Git state, and optional impact data; the 0.27 line also exposes code-graph and blast-radius views plus run child, diff, and resume operations. Its memory path stores shared files and cards: handoffs are linted and routed according to the memory owner's policy, narrowly targeted safe notes may be filed automatically, and ambiguous or risky notes await review. MCP servers, tools, and skills are managed in the Brigade catalog and previewed before an explicit apply projects them into a harness, with preservation, gating, and rollback controls. An optional brigade fleet serve process aggregates run events, arbitrates repository claims, and displays external harness sessions; cloud registry commands track work executed by other providers rather than running that work themselves.
- A team moving between Codex, Claude Code, and other coding harnesses that needs task state, handoffs, and shared memory to survive tool and session changes.
- A maintainer dispatching several coding agents into one repository who needs atomic claims and parallel-safe waves to prevent duplicate work.
- An engineering organization auditing automated changes that wants evidence of the exact check command, actual exit status, Git state, and optional code impact.
- A lead responsible for several repositories who wants campaigns to aggregate ready work and compose waves from each repository's own partition.
- A developer distributing MCP servers, skills, and tool configuration across harnesses who wants a preview before writes and a rollback path.
- A team with governed memory practices that needs owner-mediated handoffs, bounded session-start recall, and review of ambiguous or risky notes.
What are this agent's strengths and limitations?
- It connects ready work, atomic claims, verification receipts, governed memory, and harness configuration in one local control plane instead of addressing only one layer.
- Receipts preserve the executed command, real exit status, and Git state, with optional impact information, providing concrete evidence that an agent ran its checks.
- The core is local-first and daemonless; local journals remain authoritative even when the optional fleet hub is introduced.
- MCP and tool projection is dry-run-first and includes preservation, gating, and rollback controls, reducing the risk of silently replacing harness configuration.
- Recall is bounded and handoffs are owner-mediated, while ambiguous or risky notes are held for review rather than automatically accepted.
- The local JSON ledger is not a distributed task database; coordination across machines needs the optional fleet hub, while separate local journals remain authoritative.
- Brigade is not an autonomous fleet runtime: work does not proceed without a command, an external scheduler, or an explicitly installed care registration.
- Budget enforcement is narrow, covering only wall-clock time and worker dispatches; model, tool, token, and cost dimensions are generally observational.
- Center and the fleet board are read-only, and observations of external activity are explicitly best-effort rather than a complete execution-control channel.
- It does not automatically push to GitHub, publish packages, or send chat messages; operators must invoke explicit actions.
- The supplied source lacks an end-to-end first-task command sequence and does not specify credentials for optional hub or cloud integrations.
How do you install or deploy this agent?
Python 3.10+ is required. Install the stable release with pipx install brigade-cli or uv tool install brigade-cli; the stated stable version is 0.27.0, so it may also be pinned with pipx install brigade-cli==0.27.0. From an installed CLI, brigade update --channel beta selects preview builds named 0.28.0.devYYYYMMDD. The supplied material does not include a complete command for initializing a repository or creating the first task, so an accurate first working invocation cannot be reproduced here. Core local operation needs no daemon. Optional fleet, cloud, and external-service features may require further configuration, but credential formats are not documented in the supplied source.
How do you use this agent?
After installation, use the brigade command against the local work ledger. The documented flow is to identify unblocked work, acquire it with an atomic claim, make the change, and run checks through Brigade so it can issue a receipt with the command, exit code, and Git state; the supplied material does not name the corresponding task and check subcommands. For MCP, tool, or skill synchronization, preview the proposed projection first and perform an explicit apply only after review. Start brigade center serve, brigade runs serve, or brigade fleet serve when their respective views or coordination service are needed; each stays in the foreground until stopped. brigade care install can register optional, target-scoped memory-care scheduling, but the scheduler remains operator-owned. Ordinary runs have no hard budget unless one is declared, and current enforcement is limited to wall-clock and worker-dispatch ceilings.
How does this agent compare with similar options?
Compared with Beads, Brigade also supplies ready work and atomic claiming but uses a local JSON ledger, whereas Beads offers a Dolt-backed distributed store. Gas Town is positioned as a multi-agent runtime, while Brigade explicitly stops short of being a full autonomous fleet runtime. Mem0, Letta, Hindsight, and agentmemory concentrate more heavily on memory; Hindsight specifically documents reflective memory learning, whereas Brigade's learning means outcome scoring, promotion, and rollback based on captured verification receipts. Rulesync, config-sync, agentsync, and chezmoi focus on configuration generation or synchronization; Brigade connects dry-run-first MCP, skill, and tool projection to task tracking, memory, and verification evidence.
FAQ
Does Brigade require a background service?
brigade center serve, brigade runs serve, and brigade fleet serve are optional foreground processes that run only until the operator stops them.