The Organization Charter

Tier 3 · Everything Built 7 min read

Note

Prereq: Orchestration: CEO → Domains → Specialists.

Most multi-agent systems are held together by convention and the author’s memory. When a new session starts, it re-derives behavior from scratch — or, worse, it invents behavior that conflicts with what came before. The Organization Charter is the solution to that problem: a written, versioned, binding document that every agent reads and every agent is held to.

---

What It Is

File: ~/clawd/ORGANIZATION-CHARTER.md. Ratified 2026-03-27. Status: IN FORCE.

The opening line: “Every agent that reads this document is bound by it. There are no exceptions, no workarounds, no edge cases. This charter is law.”

That’s a strong claim for a Markdown file. What makes it stick isn’t enforcement machinery — it’s the combination of explicit rules, an agent hierarchy that routes accountability upward, and a CLAUDE.md that makes every session load the charter before acting. An agent that hasn’t read the charter doesn’t know what it’s part of. One that has read it can locate itself in the hierarchy, understand its scope, and know what requires escalation.

---

The Mission Statement

“The mission is singular: eliminate administrative overhead so JD can focus on thinking, creating, and being present with his family. Every minute he spends on administrative work is a minute stolen from what matters.”

This isn’t motivational language — it’s a filtering criterion. Work that reduces administrative overhead for JD is in scope. Work that creates new administrative overhead is not, even if it’s technically impressive. When domain agents write reports, the test is whether the report reduces burden or adds to it. When the CEO escalates something, the test is whether JD needs to make this decision or the agent can.

---

The Hierarchy

JD  →  CEO (Opus, 30m heartbeat)
         ↓
   8 Domain Orchestrators (Sonnet, 1h heartbeat each)
         ↓
   ~31 Specialist Agent Packages (Sonnet/Haiku, on-demand or scheduled)
         ↓
   Ephemeral Workers (Haiku, spawned per task, die on completion)

Tier 0 is JD — the only human in the system, the only authority who can approve irreversible actions. Tier 1 is the CEO. Tier 2 is domain orchestrators. Tier 3 is specialists. Tier 4 is ephemeral workers. Each tier’s model tier matches its responsibility tier: Opus for the CEO, Sonnet for orchestrators and most specialists, Haiku for workers.

This is a cost routing decision as much as a quality decision. Haiku for a worker that runs clawd-log.sh costs a fraction of Opus. Opus for a CEO making an architectural routing decision is worth the premium. The charter enforces model selection by tier rather than leaving it to each agent to pick arbitrarily.

Note

A previous version of the charter described a corporate C-suite: COO/CTO/CMO/CIO. That structure was never implemented as code — the directories existed but held no orchestrator entrypoints. The current auto-synced roster (in the charter’s Article 1.5) shows the real architecture: 8 domain orchestrators, not a C-suite. A note was added explicitly: “cite the auto-synced table, not the earlier text.” The charter documented its own deviation from intention.

---

The Commandments

The charter’s Article 2 is a list of binding operating rules. Several are load-bearing enough to quote directly:

“No broken work to JD.” An agent that ships something incomplete and tells JD it’s done has violated a commandment. Incomplete work goes to a branch; JD sees it in production, not in a status report.

“Human approval for irreversible actions.” Money moves, sends-as-JD, IP/trademark decisions. These are always human-gated. The charter doesn’t say “usually” or “when in doubt” — it says always. The merch operator’s first real sale (2026-06-09) was authorized by JD. The operator designed, listed, and fulfilled; the authorization was JD’s.

“Artifacts over conversations.” The deliverable is a file, a deployed URL, a shipped function — not a chat message about a file. When an agent completes work, the artifact is the proof.

“Git discipline.” Branch-first. Commit conventions. Never touch the default branch in a non-isolated worktree. The worktree collision incidents (2026-05-22, 2026-06-08) that rewrote page.tsx edits onto the wrong branch were violations of this commandment.

“Open Source & Document Everything” (Commandment XI). After building anything useful: strip personal data, push to GitHub, document on docs.agenttree.army if it helps others. openbudget and harnessview were both shipped under this commandment.

---

Model Routing as Policy

The charter’s model selection table is explicit:

Tier	Agent Type	Default Model
1	CEO	Opus
2	Domain Orchestrators	Sonnet
3	Specialists	Sonnet or Haiku
4	Workers	Haiku

There’s no “Sonnet because it’s cheaper” rationalization for CEO decisions. There’s no “Opus because the task feels important” justification for a Haiku-tier worker. The tier determines the model; the work determines the tier. Any deviation requires a documented reason.

---

Why a Document Does Real Work

The charter works because it’s loaded. Every CEO session reads CLAUDE.md, which references the charter, which means every decision the CEO makes is implicitly checked against it. When a new build agent is spawned, its prompt includes the charter’s relevant rules (worktree isolation, no live-session writes, push-back when the design is wrong).

Without the charter, the rules live in someone’s head. When the head rotates — when the session resets — the rules disappear. A written, versioned, CLAUDE.md-referenced charter turns conventions into infrastructure.

Tip

The charter is the difference between an agent system where the rules are the author’s current intent and one where the rules are a stable artifact that survives session rotation, model changes, and new agents being added. If you’re building a multi-agent system, write the charter before you need it. The 2026-03-27 ratification date predates most of the system’s current capability.

---

Next: Inter-Agent Messaging (ask_agent) — how any agent talks to any other by name, with the specific call pattern and what happens under the hood.

Enjoyed this? Get weekly agent architecture insights.

Subscribe and get a free Agent Architecture Cheatsheet.

Subscribe