Brigade: Sync tools and memory across harnesses, with one local-file record of your coding agents' work

Who it is for

• For developers who use several coding agents at once: when switching between harnesses (for example, using a different coding agent at different times), you want tools and memory to stay in sync and all work to share a single record, instead of each tool keeping its own with states that never line up. The official description is that it runs coding agents anywhere and keeps one record of the work.
• It ships as a CLI: agents claim ready work from a shared record, and memory and skills are served to harnesses over MCP. It suits users who are comfortable managing agent work state on the command line and wiring capabilities into an existing agent toolchain through MCP.
• The work record is kept as local files and no daemon is needed, which suits users who want their work data to stay on their own machine and prefer not to run extra background services. Whether multi-user collaboration or remote deployment is supported is not stated officially.
• Prerequisite: the npm install route requires Node.js 22 or newer plus npm. If your environment does not meet that, the official documentation offers no alternative install method and does not say whether behavior differs between operating systems.
• The official documentation does not name situations where it fits poorly and gives no list of supported harnesses. Before wiring it in, confirm that your agent client can add an MCP server over stdio — the official documentation does not check this for you. If your toolchain can neither run a CLI nor connect to MCP, there is currently no confirmable integration path.

First attempt in 3 minutes

• Prerequisites: have Node.js 22 or newer and npm ready. The official documentation states that usage may send one passive version request as a telemetry side effect; this is the network side effect the vendor explicitly discloses, it is a condition you accept before use, and you should be aware of it when installing. Beyond this, whether any other network access occurs is not covered by the available information.
• There is exactly one recommended main path: install the pinned version globally with npm, then initialize following the official steps:

npm install --global @escoffier-labs/[email protected]
brigade setup

• Trigger the first attempt: have the agent run brigade work claim --next --actor codex to claim a piece of ready work from the shared record — this is the core workflow shown officially. Note that claiming is a “take the ready work away” action; how the entry's state changes in the record afterwards and whether it can be undone are not stated, so treat it as an operation that affects the record.
• If you would rather not have the agent claim work yet, start brigade memory serve-mcp --stdio locally in stdio mode, connect it to your harness as an MCP server, and see whether you can read Brigade's memory and skills over MCP — this step involves no claiming.
• Success signal: the agent picks up a piece of ready work via the claim command, or the harness reads Brigade's memory and skills over MCP. What brigade setup actually does and what its success output looks like are not described officially; if the command does not behave as expected, first confirm your Node.js version meets the requirement, then check the steps against the official repository.

Use cases

• Case 1: let several agents share one work record. Scenario: you use more than one coding agent and want a single place that shows who is doing what and how far along, instead of having it scattered across separate sessions and losing context every time you switch tools. Start: after installation and brigade setup, have the agent run brigade work claim --next --actor codex when a task begins. Workflow: work claim — the agent claims a piece of ready work from the shared record. What to expect: the entry is claimed, and the record lives in local files with no daemon. How the record is updated after claiming and how to view all work are not stated officially; what can be confirmed today goes up to the claim step.
• Case 2: serve memory and skills to a harness. Scenario: you want the harness to use the memory and skills Brigade maintains while handling tasks, instead of every tool keeping its own with nothing shared between them. Start: launch brigade memory serve-mcp --stdio in stdio mode and connect it to your harness as an MCP server. Workflow: memory serve-mcp — Brigade exposes memory and skills to the harness through this server. What to expect: the harness can read memory and skills over MCP. How your client registers a stdio MCP server and which callable interfaces exist afterwards are not stated officially; connect the way your harness normally does, then verify.

Boundaries

• Network access: the official documentation says a passive version request may be sent once as telemetry, and this is disclosed proactively by the vendor; beyond that, whether any other network access occurs is unstated, so do not treat it as a fully offline local tool.
• Files and side effects: the work record is kept in local files with no daemon; claiming takes ready work out of the shared record, and whether it can be undone is unstated. What changes installation and brigade setup make to your system is not itemized officially.
• Runtime and client: the npm route requires Node.js 22 or newer and npm; the set of supported harnesses is unconfirmed, and whether yours works has to be verified by you.
• Version and other: the install command is pinned to 0.30.0; other versions and upgrade paths are unconfirmed. Beyond claiming, how to add work, view all work, or write memory and skills is not covered by the available official information. Before folding it into your daily workflow, trial it on a small scale, confirm the behavior matches expectations, and only then expand your usage.