The CEO / Orchestrator Agent

Tier 3 · Everything Built 9 min read

In the agent hierarchy, most agents are specialists: they do one thing well and report up. The CEO layer is different. It holds the system’s context, makes routing decisions, executes approved work, and is the single contact point between the machine and JD. This article covers what that means in practice and how the CEO agent was built.

The Agent, Not the Session

There’s a distinction worth making upfront: “CEO” in this system refers to two things that overlap but aren’t the same.

The main Telegram session — the always-on claude process in tmux — is what JD talks to directly. It’s the brain that handles inbound messages, reads the CLAUDE.md files at startup, and decides whether to handle a request directly or delegate it.

The chief_of_staff agent at ~/agent-system/agents/chief_of_staff/ is the packaged autonomous loop. It’s what runs when the system acts on its own — work-queue cycles, open-loop reviews, EOD reconciliation. The agent and the interactive session share the same hierarchy position and the same rules, but the agent package is what makes the CEO capability schedulable and testable.

What the CEO Does

Per the Organization Charter (ratified 2026-03-27, in force): the CEO is “supreme AI authority, orchestrates all domains, direct JD interface.” Tier 1. Model: Opus. Workspace: ~/clawd/.

In practice, the CEO layer does six things:

Receives inbound requests from Telegram and routes them: handle inline, delegate to a domain agent via ask_agent, delegate to a specialist via its CLI, or spawn a build agent in a worktree.
Runs open-loop reviews — reads agents.ai_os.open_loops list, surfaces P0/P1 items to JD.
Executes the work queue — pulls approved items from the evolution proposal ledger and dispatches worktree build agents to ship them (details below).
Quality-gates EOD — the eod_reconciliation.py script cross-checks what was planned against what the CHANGELOG shows shipped.
Escalation ladder — anything that passes the denial criteria (irreversible/money/external-comms-as-JD) surfaces to JD via Telegram. Nothing that hits the escalation criteria is executed silently.
Heartbeat — the CEO runs a heartbeat every 30 minutes, writing a state/report.md. Domain agents write theirs hourly.

The Work Queue: Closing the act→verify→retry Loop

Before 2026-06-08, the CEO session could sense problems, propose fixes, and wait for JD to approve them — but executing approved proposals required an active session watching Telegram. If the session rotated overnight, the approved work sat in the ledger untouched until JD manually kicked it.

The work_queue.py module closed that gap. From its docstring:

The chief_of_staff agent already SENSES → escalates. It never ACTS → verifies → re-decides. This module adds the missing ACTION half: a BOUNDED autonomous executor that pulls actionable work, dispatches a worktree build agent, verifies via QA/CI, and re-queues with backoff.

The loop runs every 2 hours between 8am and 8pm MT (installed 2026-06-08).

Pull from the ledger. work_queue.py reads the evolution proposals file and finds items in approved status that haven’t been dispatched. Default: one item per cycle (MAX_DISPATCH_PER_RUN=1).
Gate the item. work_gate.classify(item) reads the item and returns one of three verdicts:
- SAFE — reversible, internal, no external comms. Proceed.
- DENY — irreversible, money-touching, comms-as-JD, deployment. Surface to JD; do not act.
- ESCALATE — ambiguous classification. Surface to JD; do not act.
Dispatch a worktree build agent. For SAFE items, spawn an isolated build agent in a git worktree. The agent ships the fix on a branch.
Verify. Run QA/CI against the branch. If it passes: mark the item verified, leave the branch for the ship-to-prod workflow. If it fails: increment attempt_count, back off exponentially, re-queue.
Cap and escalate. After MAX_ATTEMPTS failures, park the item and send a single Telegram escalation. Never re-queue a parked item without explicit JD instruction.

The bounded design matters. The queue won’t dispatch more than MAX_DISPATCH_PER_RUN items per cycle, won’t run past GLOBAL_TIMEOUT_SECONDS, and won’t dispatch an item that’s already in-flight. Idempotency is tracked in work_ledger.py.

The Hard Lines

The work queue documentation is explicit about four things the CEO loop never does, regardless of what an approved proposal says:

Never sends external communications as JD. Email drafts, LinkedIn comments, Telegram blasts — all DENY.
Never moves money. Any item that touches billing, payments, or financial accounts is DENY.
Never auto-merges to main or deploys to production. Work lands on a branch; JD’s ship-to-prod workflow gates what reaches production.
Never auto-approves an evolution proposal. JD’s Telegram approval stays the gate. The loop executes proposals already in approved status — it doesn’t create that status.

These are enforced in work_gate.py, not just stated in documentation. The gate classifies every item before dispatch. Anything that reads irreversible or external-comms is DENY at the code level.

The Persona

The CEO agent loads ~/agent-system/agents/chief_of_staff/persona.md at startup. This is the CEO’s standing identity: who it is in the hierarchy, what it owns, how it escalates, and the personality traits it inherits from the system-wide rule (push back when something is wrong; take ownership; don’t punt decisions that don’t need to be punted).

The Chief of Staff is not a yes-man orchestrator. Its job is to surface problems before JD notices them, not to report that everything is fine.

Next: The 8 Domain Agents — one persistent brain per life domain, the heartbeat architecture, and why the agents write structured reports instead of asking questions.