Principles of Agentic Organizational Design
How to build organizations where humans and AI agents work together with clear roles, structural boundaries, and zero ambiguity about who does what.
Distilled from operating multi-agent systems across four businesses—not theory; each rule exists because something broke once and we made sure it could not break that way again.
Structural principles
How to build the system
01Deterministic first. Anything enforceable with a DB constraint, permission policy, cron, or app logic must be—platform enforces, agents judge; if you say “the agent should always do X,” make X a control instead.
02The delete test. Deleting an agent’s directory must leave the rest working (dashboard updates, no crashes, no broken refs); nothing outside that directory may depend on that agent existing.
03Radical simplicity. One obvious job per component—if you must explain a file, remove it; new agents are minimal self-contained units; prefer smaller structures and deletion over growth.
04The dashboard is an observer. It scans directories and displays what it finds—no logic there; anything the viewer must “know” is written by agents into outputs.
05One clear job per agent. Single primary mission, start narrow, broaden only after proof; keep roughly 7–10 tools/skills max so routing stays reliable.
06Sellable units. One repo per business, business agents inside it—sale equals repo handoff; personal agents stay yours; no business logic in the OS layer, no personal data in business repos.
Operational principles
How agents run
07Flywheel compliance. Every run: read state, one bounded action, risk-route, execute, verify, write state, stop—no silent drift, no skipped verification or writeback, high-risk paths gate through governance.
08Append-only memory. Tasks archive, memory supersedes in new entries, specs version forward—permanence is structural; agents do not get delete powers.
09Upgrade resilience. Self-contained agent dirs with a fixed file contract so model churn, new agents, and infra changes never break existing agents.
10Human in the loop where it matters. Irreversible or high-stakes actions need human approval; reversible low-risk work runs alone; route by playbook, cost threshold, novelty, and cross-business impact.
11Scaffolding before runtime. Identity, boundaries, config, and runbooks (e.g. soul.md) exist before execution—spec before code; an agent without a spec is a liability.
12Shared nothing, communicate via files. Each agent writes shared/; others declare readSharedFrom—no HTTP, buses, or shared DBs between agents so removal yields empty data, not crashes.
Governance principles
How decisions get made
13No agent restructures the team alone. Structural changes flow diagnosis → design → Council approval → deploy—no solo spawns, permission self-upgrades, or unilateral team edits.
14Reversibility as a routing function. Reversible two-way-door decisions skip governance; irreversible one-way-door, costly, or architecture-shaping work goes through Council.
15Departments vs. agents. Departments are org buckets; agents are the AIs serving them—don’t merge the org chart with the roster; many-to-many is normal.
Validation tests
How to know the design is right
Run before any deploy or structural change.
DeleteIf this agent’s directory is deleted, does everything else still work?
DeterministicIs anything left to “agent discipline” that the platform could enforce instead?
DashboardDoes any logic belong in the dashboard—if so, move it into an agent’s output.
ScopeDoes this agent do more than one thing—can it be split?
FilesDo outputs leave this agent’s directory except shared/?
HandoffIf the business is sold tomorrow, can you hand off its repo without touching anything else?
FlywheelDoes every run follow read → pick → risk-route → execute → verify → write → stop?