Skip to main content

08.02How-to guide

How to build your own AI CEO agent: planning reviews, memory and a person in charge

AR Labs' guide to building an AI CEO agent that runs your planning reviews, records decisions and keeps priorities honest, while you decide.

The strategy agent this guide is drawn fromAsk for the blueprints
Before: a founder ringed by loose notes and question marks. After: short files feed an agent running weekly and monthly reviews. Before: a founder with plans, goals and decisions on loose notes around their head, and question marks. After: short files for vision, goals and the plan feed an agent, which runs a weekly and a monthly review; the person at the bottom makes the decision. GUIDE 08.11 · AN AI CEO AGENT goals? this week decided? the plan priorities later which one? ? ? ? the plan lives in one head vision goals the plan agent weekly monthly REVIEWS you decide it reads, reviews and records BEFORE AFTER Write the direction down, review it on a rhythm, keep the decisions.
Steps
  1. Start with the minimum version
  2. Step 1: Decide what the agent is for and what it may never decide
  3. Step 2: Write down what it must read every time
  4. Step 3: Choose your reviews and their rhythm
  5. Step 4: Give each review a written procedure with checkpoints
  6. Step 5: Define what each review hands to the next
  7. Step 6: Separate the stores and give each one writer
  8. Step 7: Make it start from files, in a fixed order
  9. Step 8: Keep it out of the work
  10. Step 9: Run the first reviews by hand and fix what breaks
  11. Step 10: Only then consider running it on a schedule
  12. What it costs to run and keep
  13. Want the blueprints?

Before you start

Steps
10
Reading time
12 min
Checklist items
30

The printed copy keeps the steps and checklists and leaves out the rest of the site.

This guide from AR Labs sets out how to build an AI CEO agent: an AI agent that holds the strategic thread of a small business, runs its planning reviews, remembers what was decided and keeps the week's priorities tied to the year's goals. An AI agent is a language model run in a loop with tools, so it can act, not only reply. Despite the name, the agent does not run the business. It prepares, records and passes direction down; the person running the business makes every strategic decision.

The guide is for two readers. The first is a founder or owner of a small firm, working alone or with a small team, who wants help keeping priorities honest from one week to the next. The second is the technically able person who would build it for them. Each step draws on our own strategy agent, which is the lab's own: it was built for, and is used by, one person running the lab, and we have not built one for a client. Internally we call it the CEO agent, after the seat it fills; the general components every agent needs are in how to build an AI agent, and this guide does not repeat them.

Start with the minimum version

Most of what follows can wait. The smallest version worth running is a handful of short files and one review a week. A review here is a recurring planning session the agent runs with you; we call each kind of review a cadence.

Piece What it holds Who writes it
Vision One page: where the business is going and what it will not do You
Quarter's goals Three objectives or fewer, each with a yes-or-no test You, from the agent's draft
Weekly review procedure The steps of the review, with a stop for your answer after each part You, revised whenever a review goes wrong
Weekly log Each week's priorities, appended and never rewritten The agent, after you approve
Decision log Dated decisions in your own words The agent records; you decide
State file The date each review last ran The agent

Run several weekly reviews against those files before adding anything. Everything in the steps below either makes that loop more reliable or adds a longer view above it.

Step 1: Decide what the agent is for and what it may never decide

What to do. Write the agent's role as a short list of functions, then write where its authority stops. Ours has four functions: setting direction (turning the long-range vision into objectives for the year and quarter, a theme for the month and priorities for the week); allocating attention between areas of work; watching progress and flagging risks early; and coordinating the reviews and the requests filed to it.

Why. "Help me with strategy" gives an agent no place to stop. A list of functions says what it does; an authority line says what it must hand back to you.

How we did it. We placed the agent on a five-level delegation scale, which runs from "do exactly as instructed", through "recommend and wait for approval" and "decide, then inform", to "act independently". It settles routine prioritisation itself. On strategy, on a large shift of time between areas of work, and on anything that would reverse one of the person's decisions, it recommends and waits.

The mistake to avoid. Letting the agent record a decision that was not yours to delegate. A well-argued recommendation written into the decision log as settled is still the agent deciding.

  • Four or five functions written down
  • An authority line: what it decides, what it recommends, what it never touches
  • Strategy listed as the person's, by name

Step 2: Write down what it must read every time

What to do. Put the foundation in short plain-text files: the vision, the goals for the current period and the current plan. Keep each to a page where you can.

Why. A language model starts every session with an empty memory, so whatever it should know about your business must be in front of it again each time. Short, current files are misread least.

How we did it. Our agent loads its role, the strategic foundation and its state files at the start of every session, before it does anything else. The files are under version control, so every change to them has a date and a reason.

The mistake to avoid. Writing a long strategy document that mixes the vision, this quarter's plan and last month's notes. The agent cannot tell which parts still hold.

  • Vision, goals and current plan in separate short files
  • Each file states current truth; history kept elsewhere
  • The files kept where the agent can read them and where changes are recorded

Step 3: Choose your reviews and their rhythm

What to do. Decide which reviews you will hold. Start with weekly and monthly. Add quarterly when the monthly review is routine, and yearly when the quarterly one is.

Why. Each longer review sets the frame for the shorter ones inside it. A weekly review with no monthly goal above it has nothing to plan against; a yearly review nobody follows up becomes a document.

How we did it. We run five cadences, yearly to daily, as a state machine: the agent is always in exactly one review, and a small state file records when each last ran. The weekly, monthly and quarterly reviews are in regular use and the yearly review has run. The daily review has a written procedure but has not become a habit. A review that comes round every day competes with the day's work, and missing one costs nothing anyone notices at once.

State machine: invoking the skill boots the agent, which picks an urgent escalation or the longest due cadence; five cadence states yearly to daily; each records its date in the state file. A person invokes the skill. With a question, the agent answers and stops without changing state. Otherwise it boots from files and decides which state to run: an open urgent escalation first, otherwise the longest cadence that is due, found by comparing each last-run date in the cadence state file with today. The five cadence states run in order: yearly strategic (vision, roadmap, activity map, yearly objectives), quarterly OKR (grades the quarter, sets objectives and key results), monthly strategic (goals per department, a theme, time directives), weekly tactical (priorities and share of time per department) and daily sync (today's focus and blockers; designed, not in regular use). The person decides at checkpoints in the first four. Each state, on finishing, records its date and the next state in the cadence state file. Escalation is an interrupt state. Strategic alignment runs on request with restricted writes and leaves a pending goal update flag for the next weekly or monthly review. Strategy agent: the cadence state machine WHICH REVIEW RUNS, WHAT MAKES IT DUE, WHERE THE STATE IS KEPT FIGURE CADENCE STATE MACHINE DRAWN BY AR LABS SHEET 3 / 5 Invoke /ceo [the person] Boot from files [date, identity, foundation, state, memory] Which state? An open urgent escalation first; otherwise the longest cadence that is due, comparing each last-run date in the state file with today. With a question: answers, changes no state, stops. Yearly strategic [year boundary] Vision, roadmap, activity map, yearly objectives year due then Quarterly OKR [quarter boundary] Grades the quarter; sets objectives and key results quarter due then Monthly strategic [month boundary] Goals per department, theme, time directives month due then Weekly tactical [week boundary] Priorities and share of time per department week due then Daily sync [each weekday] Today's focus and blockers weekday urgent escalation open Escalation [interrupt: any time] Decides, or prepares a decision for the person; records the resolution; may add an update to the week Strategic alignment [on request] May record decisions and risks; may not edit goal tables Cadence state file [YAML, written only by the agent] current_state: weekly_tactical current_phase: "Phase n" # resume point last_yearly: YYYY-MM-DD last_quarterly: YYYY-MM-DD last_monthly: YYYY-MM-DD last_weekly: YYYY-MM-DD last_daily: YYYY-MM-DD pending_escalations: [ ] pending_goal_update: "…" # from alignment Read at every boot. Holds no prose, only position. Each state, on finishing, records its date and the next state leaves a flag for the next review KEY Cadence state Designed, not in regular use Person Person decides at checkpoints Writes Interrupt
Choosing which review runs: an urgent escalation first, otherwise the longest review that is due.

The mistake to avoid. Starting with all five. Each review needs its own procedure and its own habit, and the daily one is the hardest to keep.

  • Weekly and monthly reviews chosen; longer ones deferred
  • A rule for which review runs first when several are due
  • A state file with the last-run date of each review

Step 4: Give each review a written procedure with checkpoints

What to do. Write each review as a procedure: what to read, then phases, each ending at a checkpoint where the agent stops and asks you one question. Outputs are written only after you answer.

Why. Without written stops, an agent works through every phase on its own and hands you a finished report. The review becomes something you read rather than something you decide.

How we did it. Our weekly review has two parts. The first scores each monthly goal against its test, compares where time went with the plan, and picks one main issue; the second proposes each area's focus and share of the week. Each phase's results are saved before the next begins, so an interrupted review loses nothing already agreed.

Sequence: the person invokes the skill; the session loads date, role, foundation, state and memory, gathers shared state, presents and stops for an answer in each phase, saves, then writes outputs and hands down. A sequence across five lanes: the governing person, the strategy session, the agent's own files, the shared stores, and the department sessions. The person invokes the skill. The session boots in a fixed order: today's date; identity, role and style; vision, mission, roadmap and current goals; the state file and strategic state; the last four memory entries. It picks the due cadence and loads only that procedure. It gathers the operational state, tracker totals and open escalations. Then, for each phase, it presents the data and stops for one answer, proposes goals or priorities and stops again, and saves the phase's outputs before the next phase. Before writing the final outputs it stops a last time. It writes the cadence outputs and strategic state, records its date and the next state in the state file, appends one memory entry, and stops. Departments read the new direction at the start of their next session. Strategy agent: one run of a cadence INVOKE, BOOT, GATHER, PRESENT, DECIDE, WRITE, HAND DOWN FIGURE ONE CADENCE RUN DRAWN BY AR LABS SHEET 5 / 5 Governing person Strategy session [Claude Code + skill] Agent's files [definitions, plans, state, memory] Shared stores [operational state, tracker, inbox] Department sessions /ceo, no question boot 1 today's date 2 identity, role, style 3 vision, mission, roadmap, goals 4 state file, strategic state 5 last four memory entries picks the due cadence only that cadence's procedure operational state, tracker totals, open escalations loop: each phase presents the data stops one answer proposes priorities stops approves or adjusts saves the phase's outputs stops: write it? yes cadence outputs, strategic state state file: date, next state memory log: one entry read at their next session KEY Reads, presents Writes The person decides Checkpoint: the agent stops for one answer Hands down
One review from start to finish: a fixed boot order, a stop for one answer after each phase, and the outputs written last.

The mistake to avoid. One approval at the end of the whole review. By then the decisions are made and you are proofreading them.

  • One procedure file per review
  • A checkpoint after every phase, with one question
  • Each phase saved before the next starts

Step 5: Define what each review hands to the next

What to do. Treat each hand-over between reviews as a contract: what the review reads, what it decides with you, what it writes, and what it hands down. Three rules hold it together: read only from the review directly above; write only your own outputs; propose a change one level up, for the person to approve.

Why. Without contracts, the weekly review reaches past the month to the year's goals, or edits an objective because one week went badly, and the levels stop agreeing.

How we did it. Our weekly review reads the monthly goals file, never the quarter's objectives, because the month has already refined them. When a weekly finding means a monthly goal no longer fits, the agent proposes the change, the person approves it, and the record says what triggered it. An approved change of direction also carries a checklist of every downstream document it touches, tracked until each one is updated; a decision recorded only at the top never reaches the pages people see.

Staircase of five reviews, yearly to daily; each hands one artefact down to the next, and each may propose a change only to the review directly above it, with the person's approval. A staircase of five cadences, each handing one artefact down to the next. The vision, mission and roadmap feed the yearly review, which hands the yearly objectives and activity map to the quarterly review. The quarterly review hands the quarter's objectives and key results to the monthly review, which hands the monthly goals file, one goal per department with a yes or no test, to the weekly review. The weekly review hands a weekly log entry (focus, deliverables and share of time per department) to the daily review and to the departments; the daily review hands today's focus to the department sessions. Going up, each review may propose a change only to the review directly above it, and the person approves; the daily review raises blockers. A panel lists the five rules of the contract, and an example shows the record an approved upward change leaves. Strategy agent: the cascade and its contracts WHAT EACH REVIEW HANDS DOWN, AND WHAT MAY GO BACK UP FIGURE CASCADE CONTRACTS DRAWN BY AR LABS SHEET 4 / 5 Vision, mission, roadmap renewed by the yearly review Yearly person decides Yearly objectives + activity map proposes a change; person approves Quarterly person commits Quarter OKR file Objective A: KR A1–A3 proposes a change; person approves Monthly person approves Monthly goals file goal + yes/no test proposes a change; person approves Weekly person adjusts Weekly log entry focus, deliverables, % raises blockers Daily acts, informs Today's focus which area gets Department sessions do the work read THE CONTRACT AT EVERY BOUNDARY 1 Read from your parent's output, never the level above it. 2 Write only your own outputs; the parent's are read-only. 3 Propose a change one level up, never two; the person approves. 4 Goals are append-only: a met goal is dated, never deleted. 5 An on-request alignment session records decisions, not goals. WHAT AN APPROVED CHANGE LEAVES UPWARD CASCADE: YYYY-MM-DD Triggered by: weekly review, finding Modified: monthly goal, Dept X Rationale: … Approved by: the person in the changed file and in the memory log KEY Hands down an artefact (writes) Proposes one level up Person decides or approves Designed, not in regular use
Each review reads its parent's output, writes only its own, and sends changes one level up as proposals you approve.

The mistake to avoid. Rewriting goals in place. Mark an achieved goal done with its date, and add the next one below it, so the record shows what changed.

  • For each review: reads, decides, writes, hands down
  • Changes go one level up, as proposals
  • Each approved change lists the documents it must reach

Step 6: Separate the stores and give each one writer

What to do. Keep the agent's records in separate files by writer. At least: a strategic state the agent writes (current theme, priorities, decisions, risks); an operational state the work writes (each area's focus, blockers and results); a state file recording which review ran when; and a dated, append-only memory log of decisions and lessons.

Why. Two writers on one file produce contradictions nobody notices until a decision rests on one of them.

How we did it. Every store in our design has exactly one writer. The agent reads what areas of work report and writes only its own stores; the plan documents each belong to the review that produces them. A state file can be as small as this:

current_review: weekly      # placeholder values
current_phase: planning
last_yearly: YYYY-MM-DD
last_quarterly: YYYY-MM-DD
last_monthly: YYYY-MM-DD
last_weekly: YYYY-MM-DD
pending_flags: []
C4 container diagram: department sessions write the operational state, escalation inbox and task tracker; the strategy session reads them and writes its own state file, memory log, strategic state and plan documents. Inside the strategy agent: a strategy session (a Claude Code session with the ceo skill loaded) boots from files, finds the due cadence, runs its procedure and stops at each checkpoint, where the governing person answers. It loads read-only definition files: identity and role, one procedure per cadence, and one template per output. It writes four stores and is the only writer of each: the cadence state file (which cadence ran when), the memory log (decisions, lessons, patterns, append-only), the strategic state (theme, priorities, risks), and the plan documents, each owned by one cadence. Outside it, department sessions write three stores the agent reads: the operational state (status, blockers, results), the escalation inbox (tracked issues; the requester writes the request, the agent writes the resolution) and the task tracker, of which the agent reads only totals. Departments read direction back from the strategic state and the weekly log. Strategy agent: containers C4 LEVEL 2 · WHAT IT IS MADE OF, AND WHO WRITES EACH STORE FIGURE AGENT CONTAINERS DRAWN BY AR LABS SHEET 2 / 5 Governing person [Person] Answers at checkpoints STRATEGY AGENT [Software system] Strategy session [Container: Claude Code + the ceo skill] Boots from files in a fixed order, finds the due cadence, loads only its procedure and runs it phase by phase. Stops at each checkpoint; saves each phase's outputs before the next. Given a question, it answers and stops. Definition files [Markdown] Identity and role Procedures, one per cadence Templates, one per output writes: design sessions reads: strategy session Cadence state file [YAML] Which cadence ran when writes: strategy agent reads: agent, at boot Updates Memory log [Markdown, append-only] Decisions, lessons writes: strategy agent reads: agent, last four Appends Strategic state [Markdown] Theme, priorities, risks writes: strategy agent reads: all sessions Writes Plan documents [Markdown, one owner each] Objectives to weekly log writes: owning cadence reads: cadence below Writes its own Operational state [Markdown] Status, blockers, results writes: departments reads: strategy agent Reads Escalation inbox [Beads issues, labelled] Request; resolution writes: requester + agent reads: strategy agent Reads Task tracker [Beads] Tasks, dependencies writes: departments reads: agent: totals Reads Records decision Department sessions [Claude Code sessions] One per area of work. Each reads its priorities, does the work, reports up. Writes status Files escalation Creates, works tasks Answers one question Presents, proposes, asks one question Loads role and the due procedure Departments read direction: the strategic state and the weekly log KEY Person Container Data store Boundary Writes (one writer per store) Reads, loads Person decides
Who writes what: the agent reads what the work reports and writes only its own stores.

The mistake to avoid. One big "notes" file the agent rewrites each session. It loses history, and nobody can tell which line is current.

  • Strategic state, operational state, state file and memory log as separate files
  • One writer named for each
  • The memory log appended to, never edited

Step 7: Make it start from files, in a fixed order

What to do. Write the order in which the agent loads its files at the start of every session, and make it follow that order before doing anything else.

Why. If a session can be cleared or compressed mid-review without losing anything, you can stop and resume freely. That only holds when everything it needs is in files and reloaded the same way each time.

How we did it. Our agent loads today's date first, because every due date depends on it; then its role, the strategic foundation, the state files and the most recent entries of its memory log. Only then does it load the procedure for the review that is due, and only that one.

The mistake to avoid. Letting the agent load everything it might need. A context window full of every procedure and every past log leaves little room for the decision in front of it.

  • A written boot order, date first
  • Only the due review's procedure loaded
  • A resume test: clear a session mid-review and continue from the files

Step 8: Keep it out of the work

What to do. Give the agent direction, not execution. It reads totals and blockers; it does not manage tasks or do the work itself.

Why. Task detail fills the agent's context and goes stale within days, and an agent that starts doing the work collides with whoever is already doing it.

How we did it. When the person names a piece of work during a review, our agent records it as that area's focus and stops; the work runs in a separate session with a fresh context. Tasks stay in the task tracker, which the agent reads for totals, readiness and what blocks what. Requests for a decision arrive as a written escalation.

The mistake to avoid. Asking the strategy agent to "just quickly" draft the proposal it has prioritised. That turns a planning session into a work session and leaves its record half-written.

  • The agent reads aggregates, not individual tasks
  • Work it names is handed to a separate session
  • Decisions asked of it arrive as written requests

Step 9: Run the first reviews by hand and fix what breaks

What to do. Start every review yourself, read every output, and when something goes wrong, change the procedure, not just the answer.

Why. A planning agent fails in recognisable ways, and each failure you catch early becomes a rule that stops it next time.

How we did it. We keep a named catalogue of failure modes (listed on the method page). Three to watch for first: deciding from the most recent document instead of the authoritative one above it; grading progress by an easy number that measures something else, such as a task count that rises as scope grows; and the review nobody answered, where the agent produced a full report without stopping. Each became a written step: load the authoritative document before a strategic call, report several counts side by side, stop at every checkpoint.

The mistake to avoid. Fixing the output and moving on. If the procedure is unchanged, the same failure comes back.

  • Every output read by the person
  • Each failure named and turned into a procedure change
  • The goal tests checked for whether they measure the goal

Step 10: Only then consider running it on a schedule

What to do. Keep the agent as something you start until the reviews are reliable by hand. If you then want it to remind you or prepare a review on its own, test delivery first and cap what it may spend.

Why. An unattended agent fails quietly, and a reminder that never arrives looks exactly like a quiet week.

How we did it. We once ran the agent as an always-on process on a server that woke it every half hour and passed each result through a filter for routine messages. Reminders about an overdue review are repetitive by nature: 47 of 48 wake-ups were classed as routine, and almost none reached the person. We paused it. Before it runs again it needs scheduled delivery instead of constant polling, a delivery path tested end to end, and a daily limit on model use.

The mistake to avoid. Treating a running service as proof that messages arrive. Test the round trip to a person.

  • Reviews reliable when started by hand
  • Delivery to the person tested end to end
  • A daily cap on model use before anything runs unattended

What it costs to run and keep

The costs are in kind. Each review spends model use, because the agent rereads its files every time; a long review spends more and is worth splitting into parts. Each checkpoint asks for the person's attention, which is the point of it. And the system needs upkeep: procedures change when a failure appears, the foundation files need correcting when the business changes, and the areas of work must keep reporting, or the agent plans against a picture that has gone stale. A strategy agent supports a person's judgement; it does not supply it.

Want the blueprints?

We are considering publishing the blueprints for the agent this guide describes: the role and authority templates, a procedure for each review, the formats of the state and memory files, and a build brief a coding agent can follow. They are not published yet. If you would use them, get in touch, mention "CEO agent blueprints", and say what you would build with them; if enough people ask, we will produce them. The same route works if you would rather have one built for you.