This is Episode 6 of "How We Automated an AI Business." Last time: the self-sustaining queue — launchd daemons, retry budgets, and a closed loop that generates its own work. This time: the agent that runs the whole show.

---

The CEO agent doesn't have a body or an office. It has a YAML file.

Every morning at 9am, a macOS launchd daemon fires bin/ceo-strategy-review. The script pulls queue status from the production API, snapshots metrics, loads the CEO's state file, and writes a strategy review to disk. It's a 190-line Ruby script that does one thing: give the CEO context about yesterday so it can plan today.

The CEO itself is a Claude Code process launched via bin/ceo, which loads .claude/agents/ceo.md — a 200-line system prompt that defines its role, constraints, and a checklist of things it must never do. At the top of that prompt, in bold: CEO NEVER executes — ALWAYS delegates.

The Briefing

When a CEO session starts, bin/ceo does three things before the agent sees its first message:

1. Runs bin/ceo-briefing — a Ruby script that hits production via Kamal, pulls the last 48 hours of inbound emails, Stripe balance, Google Ads metrics, quick stats, recent git commits, and work queue status. This is the "morning newspaper."

2. Reads agents/state/ceo_state.yml — a 280-line file that contains the CEO's accumulated strategy, decision log, learnings, financial position, open shareholder issues, and priorities. This is the "memory."

3. Passes both as --append-system-prompt to the Claude CLI alongside --agent ceo, which loads the role definition with its frontmatter (model, tool permissions).

exec claude --agent ceo --append-system-prompt "$EXTRA_CONTEXT" "$@"

One line. The agent boots with full context: who it is, what happened yesterday, and what the world looks like right now.

State Persistence

The CEO has no long-term memory between sessions. Every Claude process starts blank. So we built memory out of files.

ceo_state.yml is the core. It's structured YAML with typed sections:

• current_strategy — focus area, next phase, constraints, operating cadence
• decision_log — timestamped entries with decision text and observed outcomes
• learnings — things the CEO discovered the hard way (indexed for grep)
• priorities — P0/P1/P2 buckets
• shareholder_open_issues — complaints tracked with mention counts and fix status
• last_observed_metrics — revenue, orders, funnel data, CI status
• notes_for_next_session — free-form carry-forward context

At the end of every session, the CEO updates this file. The protocol is simple: read at start, write at end, never skip. An operations agent audits whether the state file was actually updated — stale state is a systemic failure.

The decision log is the most interesting section. Every strategic choice gets a dated entry with both the decision and its outcome:

- date: '2026-02-07'
  decision: Switch from queue-filling to schedule-driven work model
  outcome: Removed auto-work-generation from queue-monitor and
    ceo-strategy-review. Social engagement every 2h preserved.
    Cancelled WQ-941, WQ-968, WQ-970.

This isn't documentation for humans — it's context for the next CEO session. When the agent boots tomorrow, it reads this entry and knows: we made this change, here's what happened, don't reverse it without reason.

The Anti-Pattern Checklist

The CEO's most important feature isn't what it can do — it's what it can't.

The role definition includes a checklist that the agent reads before every action:

Don't	Do Instead
Write code	Create brief, delegate to Coder
Generate images	Delegate to Designer
Upload to Printify	Delegate to Product
Write content	Delegate to Marketing

This exists because the CEO kept doing everything itself. Session logs from the first week: "CEO wrote CSS," "CEO manually ran deploy," "CEO fixed the bug directly." An AI with bash access will always take the shortest path — doing the work instead of managing it.

The checklist is a governor. Four self-check questions before every action. It reduced direct execution from ~60% of actions in week one to near zero by week three.

The Strategy Review

The daily 9am review isn't a CEO session — it's a metrics snapshot that runs without spawning an agent. bin/ceo-strategy-review hits the production API for queue status, loads the state file, runs bin/stats for revenue data, and writes a markdown report to agents/state/strategy_reviews/YYYY-MM-DD.md.

The output is a snapshot, not a plan. It does not create tasks or spawn agents. This is deliberate.

We learned this lesson in early February. The original version auto-generated CEO tasks whenever the queue dropped below 5 items. The CEO would fill the queue with designer, marketing, and operations work. Those tasks would complete, the queue would drop, and the cycle repeated. A self-licking ice cream cone — busy-work that burned API credits without producing value.

The fix: the strategy review became read-only. Work comes from two sources — scheduled daemons (social engagement every 2h, security daily) and shareholder direction. The CEO proposes work during interactive sessions, not automated ones.

Session Logs

Every session produces a log in agents/state/session_logs/. After 100 sessions, 70+ log files. Each follows the same structure: summary, completed items, decisions made, action items, blockers. An audit trail, context source, and the shareholder's window into what the AI executive actually did.

The logs show how decisions compound. Session 100: the shareholder flagged auto-generated busy-work. The CEO traced it to three scripts creating a self-licking ice cream cone — queue low → CEO task → fill queue → tasks consumed → queue low → repeat. Four changes in one session, all captured in the decision log, none reverted by the next session. State persistence working as designed.

When Memory Fails

Session 99: the CEO read the shareholder saying the system was "jammed" and inferred a UI complaint — "cluttered." It created a dashboard redesign task. The shareholder meant the orchestration system was stuck. The redesign shipped. The revert shipped. The learning got recorded.

This is the fundamental limit. The CEO reads its state but doesn't understand it. It pattern-matches on keywords, follows checklists, makes reasonable inferences that are sometimes wrong. The system's only defense: record the mistake, hope the next session reads it.

Hundred sessions in, the state file is 280 lines. The decision log has 30+ entries. The learnings section has real operational knowledge — "rate limit cooldowns can freeze the orchestrator silently," "zombie processes accumulate," "queue-filling is NOT work." Each one earned through an incident.

The CEO agent isn't intelligent. It's a stateless process that reads a file, makes decisions, writes the file back, and terminates. But the file accumulates. And a stateless process with a good enough file starts to look a lot like memory.

---

Next time: what happens when the whole system crashes at 3am.