What is a Cabinet?
Agents
Org chart & departments

Org chart & departments

A Cabinet team is a tree. Departments are folders, leads sit at the top, specialists sit underneath. Leads can dispatch work down. Specialists do focused work. Every dispatch goes through the Approval Queue before it runs.

How the tree gets built

Two things define the tree:

  1. The folder structure under .agents/ — sub-folders become departments.
  2. The type field in each persona.md — lead goes up, specialist goes underneath.
.agents/
├── marketing/
│   ├── gtm-lead/persona.md       (type: lead)
│   ├── linkedin-operator/persona.md
│   └── copywriter/persona.md
├── research/
│   ├── research-lead/persona.md  (type: lead)
│   └── citation-keeper/persona.md
└── operations/
    ├── ops-coordinator/persona.md  (type: lead)
    ├── product-auditor/persona.md
    └── revenue-analyst/persona.md

That's it. No manifest, no graph DSL. Move a folder, the org changes.

What a lead can do that a specialist can't

CapabilityLeadSpecialist
Run their own tasks✓✓
Be @-mentioned by you✓✓
Have heartbeats and routines✓✓
Propose LAUNCH_TASK to other agents✓opt-in via canDispatch
Propose SCHEDULE_JOB✓opt-in
See other agents' memoryopt-inno
Cross department boundaries when dispatchingwith policyno

A specialist stays in its lane. A lead can plan a week of work for the team in one turn.

Dispatch — the lead's main move

When a lead is reasoning through work, it can emit a structured action instead of just text:

{
  "action": "LAUNCH_TASK",
  "to": "research-lead",
  "title": "Brief 10 competitors before Friday",
  "prompt": "Fan out to /research/competitors/. One brief per company.",
  "model": "gemini-2.5-pro",
  "effort": "medium"
}

That action shows up in the Approval Queue. You see who proposed it, change settings inline, and approve or reject. Nothing runs without you.

A lead can chain dispatches in one turn:

"Plan the Q3 launch. Brief competitors via Research Lead. Schedule a weekly LinkedIn batch. Queue a Friday founder-story pass with the Editor."

The output: three queued proposals, all visible at once. You scan, approve in 30 seconds, the team executes for a week.

Department visibility

Each persona has a visibility field that controls what they can read:

ValueReads
folderOnly their .agents/<dept>/ + the cabinet-level pages they're explicitly given.
cabinetEverything in the current cabinet. (default)
allEverything in this cabinet AND its child cabinets. Use sparingly.

Tight visibility makes agents fast and predictable. Loose visibility makes them aware but expensive.

Cross-department policy

By default, a lead can only dispatch within their department. Marketing can ask Marketing. Research can ask Research. Cross-department dispatches require policy in .cabinet:

dispatch:
  allow:
    - from: marketing/gtm-lead
      to: research/*
      kinds: [LAUNCH_TASK]
    - from: operations/ops-coordinator
      to: marketing/copywriter
      kinds: [LAUNCH_TASK]

Without an entry, the dispatch is rejected at the proposal stage with a clear "policy: not allowed" message. No surprise cross-team work.

A team-of-teams: child cabinets

A child cabinet has its own .agents/ folder with its own org chart. The parent cabinet's leads can dispatch into a child cabinet only if the child explicitly opts in via its own .cabinet:

# children/clients/acme/.cabinet
dispatch:
  acceptFromParent:
    - from: ops-coordinator
      kinds: [LAUNCH_TASK]

This makes Cabinet practical for agencies, multi-tenant work, and "departments-of-departments" setups. Each child stays sovereign.

Read on