The crew

Org & Pride

A crew is more than a bag of agents — it has a shape. Define that shape as a real org chart in cfg.org: members, departments, and reporting lines. From the graph, Brigade derives an A2A (agent-to-agent) policy that governs which agents may message which.

Define an org#

Start from a template and edit. The templates cover a solo setup, a family, a company, or a blank custom chart:

$ brigade org init --template company$ brigade org init --template solo --skip-editor

The org block lists members with their reporting lines and departments. Brigade does not impose a fixed roster — instead, org init scaffolds one of four starting points you then edit: solo (a single chief-of-staff), family (a coordinator plus helpers), company (a chief of staff over an engineering lead, an engineer, and an operations lead), or custom (an empty chart). You create the actual agents with brigade agents add and place them in the chart.

The A2A policy#

The policy is derived from the graph, not configured separately. Reporting lines and departments determine who can talk to whom, with explicit overrides where you need them. This is what stops an arbitrary agent from messaging another outside the chain of command.

Inspect & explain#

You never have to guess why a message was allowed or denied:

$ brigade org show               # ASCII tree of the current org$ brigade org explain ceo backend-dev   # can ceo message backend-dev? why?$ brigade org doctor             # lints: single-member dept, dangling overrides, depth > 5…

• org show prints the tree.
• org explain <from> <to> tells you whether from can message to, and the derivation or denial reason.
• org doctor runs lints — single-member departments, dangling overrides, excessive depth, and more.

From inside a turn#

When cfg.org is set, agents get the read-shaped org tool with actions like describe, show, delegate, explain, and plan. It can render the crew as a 🦁 Pride chart — list, tree, columns, or an image.