Most “AI Chief of Staff” writeups jump straight to a system prompt. That’s the wrong place to start. A prompt describes behavior; it doesn’t describe the structure that makes the behavior reliable across hundreds of sessions, months apart, without you re-explaining the rules every time.

This is the map I wish existed before I built one: 17 entities, grouped into five categories, each solving one specific failure mode of a naive single-agent setup. None of it is invented from scratch: most individual pieces have real precedent (domain subagents and a memory context, for instance, are already in Anthropic’s own Claude Cookbook example; the write-back memory idea overlaps with MemGPT; Reflexion (entity 14) is a named academic pattern). What I haven’t found published anywhere is this specific combination, assembled as one system. It’s the companion piece to Building an AI Chief of Staff: Agents, RAG, and a Routing Graph, which goes deep on entities 2 and 9. Think of this post as the table of contents; that one (and future posts) are the chapters.

None of this requires a specific vendor or framework. It’s implementable on top of any agent runtime that can call tools and read/write files.

I. Structure — how work gets divided

1. Entry orchestrator. A single point that receives every request and decides who should handle it. It never answers domain questions itself. Its only job is triage.

2. Domain agents. Specialists with their own judgment per area, instead of one generalist averaging instincts that should stay distinct (a cautious finance read and an upside-seeking career read are both correct in their lane — blending them produces neither).

3. An explicit escape valve. Clear rules for when a human can skip the entire apparatus on purpose: a pure technical question, a direct system command, an explicit “just answer me directly.” Without this, heavy governance becomes friction, and people route around the system instead of using it.

II. Memory — what persists and how it’s found

4. Structured memory, write-back. Facts and decisions that persist across sessions. Every agent is expected to write to it, not just read from it. A memory store you only query is a search engine, not a system that accumulates judgment.

5. Semantic RAG over unstructured knowledge. Long-form notes and research, searched by similarity rather than exact match: useful when you’re looking for “what have I already thought about that’s similar to this,” not a specific fact.

6. A trigger-indexed skill registry. RAG applied to procedures instead of facts: each reusable playbook declares what it’s for, and the system loads only the relevant ones instead of stuffing fifty into one prompt.

7. Multi-session goal persistence. Distinct from fact memory: this tracks objectives that span many sessions (status, progress, next step) and surfaces them unprompted, so you never open a session and have to ask “where were we.”

8. A universal inbox with typed triage. Fast capture with zero decision required at capture time; processing happens later, with different rules per type (an idea gets evaluated, a task gets scheduled, a reference gets archived).

III. Governance — who’s allowed to act alone

9. A workflow graph with gates. Every transition between steps is an edge; every edge that involves a real-world consequence defaults to requiring human confirmation (deny-by-default), and a small validator checks that no future edit can quietly loosen that.

10. A blind reviewer. An agent that validates a result against a stated success criterion without seeing the process that produced it, so it can’t inherit the builder’s confirmation bias.

11. Adversarial synthesis (optional, for decision support). Two opposing readings of the same situation, produced independently. The value isn’t which one “wins,” it’s where they diverge. The divergence is usually the actual decision.

12. An escalation ladder. Self-correction first, then a specialist, then a human, in that order. This isn’t about avoiding the human; it’s about not treating every uncertainty as equally worth interrupting them for.

IV. Learning — getting better over time

13. Skill crystallization. A repeated task (multiple steps, multiple agents involved, or explicitly flagged as “I’ll need this again”) graduates into a named, reusable capability instead of getting solved from scratch every time.

14. Continuous self-evaluation. A pre-run / post-run reflection loop (what worked, what failed, what to do differently) so the same mistake doesn’t need correcting twice by a human. It’s in the spirit of the academic Reflexion pattern (verbal self-reflection instead of a weight update), though looser: Reflexion re-attempts the same task with a reward signal, while this is closer to a written lessons-learned log carried across different sessions and tasks.

15. Periodic audit and pruning. A recurring pass that categorizes every agent and skill as active, lukewarm, stale, or unused, and only proposes removal, never deletes without confirmation. Agent sprawl is a real, underdiscussed maintenance problem once a system passes a few dozen components.

V. Efficiency — cost and session discipline

16. Cost-aware delegation. The orchestrator decides, case by case, whether a subtask goes to an expensive model or a free/local one, with explicit criteria, never “always cheap” or “always expensive.” This is the practical shape of multi-LLM routing, which is having a moment right now for good reason: most subtasks don’t need frontier-model reasoning, and pretending otherwise is pure waste.

17. A deterministic session-boundary protocol. A fixed checklist at open (read context, surface active goals, flag anything pending) and at close (save a summary, update goal state, log what happened) so continuity doesn’t depend on the model “remembering” to do it. It’s a procedure, not a hope.

Why the count matters less than the categories

Seventeen is not a magic number. It’s what this particular system needed once it outgrew a single prompt. What matters is the five categories, because each one answers a question a naive setup never asks explicitly:

  • Structure — who handles what, and how do you opt out?
  • Memory — what persists, and does the system ever write, or only read?
  • Governance — what can happen without asking, and how is that enforced, not just stated?
  • Learning — does the system get better, or does every session start from zero?
  • Efficiency — does every subtask cost the same, or does the system know when it doesn’t need to?

A system missing an entire category isn’t necessarily broken. A lot of useful agents never need adversarial synthesis, for instance. But a system that’s never asked the question in a category tends to fail in that category’s specific way, silently, until it doesn’t.

This is a reference map, not a specific implementation. Deep-dive posts on the remaining governance entities (blind reviewer, adversarial synthesis, escalation) and the learning category are next.