Blueprint: AI Team on Fable + Codex

Status: living. This is how a team of one person and several dozen AI sessions a day has worked since the summer of 2026: Claude Fable 5.1 as HQ, Opus/Sonnet as the hands, Codex as a second track. Everything below comes out of practice, rakes included.

You open Claude Code, pick the strongest model, and do everything in one session: code, writing, research, correspondence. A day later the context is full, the decisions have dissolved into chat, and half your tokens went on routine a model three times cheaper would have handled. There’s a Codex subscription sitting right there, but the two tools live in different worlds and neither knows what the other did. The session dies, and everything it “remembered” dies with it.

This Blueprint describes a different shape: one long-lived HQ session on the strongest model holds context and decisions, the work is done by disposable headless workers on models priced to the task, a second vendor is wired in as a separate track with its own job, and everything that matters lives in files rather than chats. HQ is a manager, not a doer. The file is the unit of work. The human has the last word on a short list of irreversible actions.

What you get

• An HQ session that doesn’t die: it lives through resume, gets a “state of the world” block on startup, and picks up where it left off yesterday.
• A fleet of workers: every task is a separate headless run in tmux driven by a brief file, with a report file, an exit marker and a watcher; the model is chosen explicitly for the job.
• A model matrix: HQ on Fable 5.1 at max effort, substantive work on Opus 5, mechanics on Sonnet 5 at medium effort, background jobs (cross-session memory, for one) on the cheapest cloud model there is (Haiku 4.5) — or on a local one, if you have the hardware. The second track has a pair of its own: Astra for substantive work, Sol for mechanics (see “Models inside the Codex track” below).
• A second track on Codex: review, a second opinion, long generations, and processes that need an independent head; the exchange with Claude goes through files, not copy-paste.
• A decision registry: every fork that needs the human becomes a card with a default and a path to the artifact, instead of a question in a chat that sinks.
• Memory that outlives sessions: repo maps, role memory, HQ’s file memory, the team constitution.
• A sync rule: what one agent did is always visible to the other through a trace in files.

How to set it up

1. Open a coding agent (Claude Code) in your home directory or at the root of your notes — HQ lives where all the projects meet, not inside one repo.
2. Show it this Blueprint: “Build me an AI team following this Blueprint. Start with the section ‘Questions to adapt it to you’.”
3. The agent assembles the first layer: a global CLAUDE.md with the orchestration section, a map of your first repo, a brief template, a worker launcher, a decisions file. That’s day one.
4. Week one is the habit: every task longer than half an hour goes to a worker with a brief; HQ does by hand only what would cost more to brief than to do.
5. Week two is the second track and memory: you wire Codex in through files, set up role memory, and write a constitution of five to eight articles.

When to use it

• You work alone, but you have more than three projects and they run in parallel: site, content, product, operations.
• You already pay for Claude and for Codex (or another second subscription) and you want them working together rather than in turns.
• You care about decisions and history — what was decided, why, where the artifact is — not just about output.
• You’re willing to accept that the file is the unit of work, and to write briefs instead of handing out instructions in chat.

When not to use it

• One project, one repo, linear work — one session with a good CLAUDE.md is enough.
• You don’t want to keep tmux, launch scripts and state files around: this Blueprint is about operations, not about a clever prompt.
• You want a fully autonomous agent with no human in the loop: here the human is in the loop by choice, not because the setup hasn’t grown up yet.

The core idea

HQ is a manager, not a doer. The strongest model is expensive in context, not in tokens: every bit of routine done by its own hands pushes out of the window the thing you keep it for — decisions, history, judgement. So HQ does by hand only the pinpoint operations where the brief costs more than the work, and turns everything else into a brief and hands it off.

Model by task, not by habit. Substantive work — code design, product, money, research that ends in a conclusion — goes to Opus. Mechanics against an exact checklist — smoke tests, a deploy that already has a plan, moving files, regenerating from ready prompts — goes to Sonnet at medium effort. HQ runs on Fable at max effort, because its mistakes cost the most. The model is named explicitly in the launch command; a silent substitution is forbidden.

Files, not chats. The brief is a file. The report is a file. A decision is a card with a path to its artifact. The team rule: there’s an artifact, so there was work; vague means not done. Chat is noise that burns off at the next compaction; a file outlives the session, the model and the vendor.

Two vendors mean a second opinion, not a spare. Codex is not a second HQ. It has its own genres: reviewing strategic texts, independent criticism, long generations, processes. The demand on each vendor is the same — it has to see what the other one did. Which means the exchange runs through files both of them read.

The human has the last word, but the list is short. Not “ask about everything” — one explicit list: sending messages to people, publishing, payments, deploying new systems, migrations on the production database, production configuration, deleting data. Everything else: do it and report. One named exception to “sending messages to people”: scheduled recurring columns (in our case a weekly column in two Team2Team spaces, fired by launchd) go out with no human at the moment of posting, but under a previously recorded human decision covering that column, that space and that cadence, and their text is deterministic — no free generation at send time. The exception lives in a document, not in a head: unrecorded, it is a violation.

Architecture

Human
  │  chat + decision cards (dashboard) + mobile bridge
  ▼
HQ — Claude Code, Fable 5.1, effort max, endless session through resume
  │  writes briefs, reads reports, keeps the decision registry, memory, handoff
  ├──► Claude workers — headless `claude -p` in tmux, Opus 5 / Sonnet 5
  │      role + role memory + repo map → brief → report → SendMessage to HQ
  ├──► Codex track — `codex exec -m astra|sol` in tmux (workers) + Codex-Main (second opinion)
  │      brief file → report file → a line in HQ's inbox
  └──► Watchers — a Monitor on the inbox file, job watchers, launchd jobs
Common ground (everyone reads it): notes · repos with a CLAUDE.md map ·
inbox file · decision registry · team journal · constitution

HQ. One interactive Claude Code session on Fable. To restart it you use a wrapper command that resumes the live id from a state file. On every start a hook drops a “state of the world” block into context: the last handoff, decisions that are due, unread inbox sections, the state of the roles, orphaned processes. Once a day or two HQ writes a handoff note: what’s hot, what’s waiting on the human, what to do first.

Workers. Every task is a tmux session job-<slug> running headless from a brief file. The log goes to a file through tee, and the last line is an EXIT=<code> marker in that same file — the watcher reads the file, not the screen. The report is a file in the repo’s scratchpad/, not in a temp folder. The last line of the brief says “send the report to the session named X”, with the real name of the HQ session.

Roles. Each role has a folder with MEMORY.md (rakes, facts, the human’s decisions) and state.json (the id of the last session, the repo). Resume-first only when the role’s context is genuinely needed — a multi-step task, knowledge of the codebase; a short self-contained task gets a fresh session, because dragging a fat history around costs. What separates a role from a disposable worker, and when to create one, is in “Named teammates and plain workers” below.

The Codex track. A Codex worker is codex exec in tmux under the same protocol: brief file, report file, exit marker. Its push to HQ is a small script that appends a section to the inbox file, and HQ’s Monitor on that file wakes it up. The other direction is a script that drops a task into Codex-Main’s inbox and nudges its queue. Accepted is not the same as done: done means the cursor moved and there’s a report artifact.

The decision registry. A JSON file of cards with mandatory fields: type (decide / approve / think / do), the question, the default, the cost, the path to the artifact. A dashboard shows them, the human answers with a button or a line, the answer is written back into the same file and into the inbox — HQ wakes up and acts. A card without a default is work handed back to the human; an “approve” card without a cost is an automatic yes.

Memory. Three layers: repo maps (CLAUDE.md at the root — stack, structure, entry points, how to restart and how to check), role memory, and HQ’s file memory (one fact per file, index loaded at startup). Plus cross-session memory from a plugin: its background watcher makes thousands of calls a day, so it lives on the cheapest model going — something in the Haiku class. We tried a local one and rolled it back: a 27B model held 30 GB of memory and spent its life loading and unloading under eight sessions; we’ll come back to it with something smaller.

Named teammates and plain workers

A worker is a process. A named teammate is a role with a name, memory and a thread. The difference comes down to three things: what survives the task, who owns the project thread, and how HQ addresses the executor.

A plain worker is a one-off headless run driven by a brief. Fresh session, the whole context fits in the brief, and once the report is in, the process dies leaving nothing behind but artifacts — a report, a commit — and a line in the team journal. That’s the right tool for a self-contained task under half an hour: regenerate images from ready prompts, run a smoke test against a checklist, move files, gather data from known paths, apply an edit that’s described exactly. The model follows the genre of the task: Sonnet for mechanics, Opus for a substantive one-off.

A named teammate is a role like producer, ops, web, designer, toolsmith, analyst, envoy, or a product role on the “one product, one engineer” principle. A role has five things a worker doesn’t:

• A role definition. A file describing who this is, what it owns, which tools it has, which canons it reads first. For web that’s the deploy canon and the OG gate; for ops, “back up before any surgery on data”; for envoy, “draft, never send”.
• Role memory. MEMORY.md: rakes, facts, the human’s decisions in that genre. The role updates its own memory at the end of every task, and HQ adds to it from the reports. It isn’t a diary — it’s a list of “what I know that is neither in the code nor in the brief”: where the production backups live, which cloud project is the right one, what the human has forbidden for good.
• State. state.json: the id of the last session, the repo, the date, the last task. That’s what makes resume possible: the next task on the same thread continues a session that already carries the codebase and the previous moves, instead of getting introduced from scratch.
• Ownership of the thread. Executor continuity: whoever started work on a project gets the next task on it, even when the genre would suggest a different role. Handing it over takes a written reason and a handoff: status, artifacts, open risks, next move. That’s how a product ends up with “its own engineer” who remembers why it was built this way.
• An address. HQ addresses the role by name through the launcher (--role web --brief …), and the brief opens with “you are this role, read your memory”. People on the team know the address too: “that’s one for ops”.

	Worker	Named teammate
Lives for	one task	a thread of many tasks
Context	all of it in the brief	brief + role memory + session
Memory	none: journal and artifacts	MEMORY.md + state.json
Launch	always a fresh session	resume-first, fresh when the context isn’t needed
Model	by the genre of the task	by the role, the brief can override
Answers for	the result of the task	the project thread, the repo map, the canons
When	under half an hour, self-contained	a recurring genre, a codebase, long threads

When to create a role. The rule of three: the genre has come up three times, it has a repo or a canon of its own, and the same mistakes keep repeating because nobody is there to remember them. A role without recurrence is one more thing to feed. A memoryless worker in a recurring genre is the same rake every week.

What a role does better than a worker. It remembers production: where the backups are, how to restart, which smoke tests are mandatory. It reads the repo map like someone coming back, not like a newcomer. It catches what changed since its last visit with a git log at the start of the task. It knows the human’s decisions in its genre: what’s forbidden, what’s approved standing. It carries on a multi-step task without a retelling of the history in the brief.

What it costs you. Resume drags the session history along — slower and more expensive — so a short self-contained task goes to the role as a fresh session rather than a continuation. Memory rots if nobody reviews it. Two instances of one role at the same time corrupt its state: the session id gets overwritten, so parallel tasks for one role either queue up or the second one goes to an anonymous worker. And a role without a human owner turns into a dumping ground for notes.

Life cycle. Birth: a role definition, empty memory, and a first task that writes the repo map. Working life: resume-first when context is needed; at the end of every task — memory, report, message to HQ. A weekly review: HQ reads the role’s memory and decides what’s stale, what’s ready to be codified into a hook or a repo map, and what to delete. Retirement: the genre is gone, the role is archived, the memory stays as a reference.

Roles and vendors. A role is tied to a genre, not to an engine. It can live on Claude or on Codex — ours does: curator, who owns the encyclopedias and decks, runs on Codex. Same principle, same memory and state; different launch, different report channel. The launcher reads the provider out of the role definition, and HQ never notices the difference.

Models inside the Codex track: Astra and Sol

The same “model priced to the task” principle applies at the second vendor too, and there it gives you two layers that don’t rule each other out.

Layer 1 — HQ picks the model at launch. A Codex worker starts as codex exec -m <model> -c model_reasoning_effort=<level> driven by a brief file. Model aliases live in one registry shared by both vendors (ours is models.json: opus, sonnet, fable, astra, sol), and both the launcher and the executor selector in the dashboard read it; an alias belonging to the second vendor switches the engine by itself. HQ doesn’t remember model ids and doesn’t type them into briefs by hand — it says “mechanics” or “substantive”, and the registry turns that into a model.

Layer 2 — subagents inside one Codex session, each on its own model. Codex ships a multi_agent flag and custom agents: one TOML file per agent in ~/.codex/agents/ (personal) or in .codex/agents/ in the project (shared with the team, loaded only in a trusted project). The file holds name, description, developer_instructions, plus the ordinary config keys: model, model_reasoning_effort, sandbox_mode, mcp_servers. A key you leave out is inherited from the parent. The limits are [agents] max_threads (6 by default) and max_depth (1 by default: a child doesn’t spawn grandchildren). The built-in roles are default, worker, explorer; your own role with the same name overrides the built-in one.

# .codex/agents/scout.toml — cheap scouting, read-only
name = "scout"
description = "Read-only scout across the codebase, on a cheap model."
model = "gpt-5.6-sol"
model_reasoning_effort = "low"
sandbox_mode = "read-only"
developer_instructions = """
Search precisely, don't scan whole directories. Hand back facts and paths; the parent does the synthesis.
"""

# .codex/config.toml — the registry and the limits
[features]
multi_agent = true

[agents]
max_threads = 4
max_depth = 1

[agents.scout]
description = "Read-only scout on a cheap model."
config_file = "agents/scout.toml"

Verified live on September 9, 2026 on Codex v0.153.3: a parent on gpt-6-astra (effort high) brought up two subagents from files like these, and in the session logs each of them had its own model and its own effort — scout on gpt-5.6-sol / low, builder on gpt-6-astra / medium. The forum complaint from July 2026, that subagents have inherited the parent’s model since 5.6, doesn’t reproduce on this build. And you check that in the logs (~/.codex/sessions/…/rollout-*.jsonl, the model field in turn_context), not by asking the subagent about itself.

What we know about price and quality. An overnight benchmark on our own tasks, September 6, 2026: where the source sits right in front of the model (checking facts, counting over data), Opus, Astra and Sol all hit the same ceiling in every repeat, while a substantive task that calls for judgement (a month of transcripts: promises, the threads running through them, a decision) pulled them apart — Opus 0.865, Astra 0.761, Sol 0.698, at $0.77 / $1.01 / $0.39 per run. The conclusion is the same as for the Opus/Sonnet pair: hand mechanics to the cheap model and lose nothing, keep judgement on the strong one.

Where the saving is and where it isn’t. Subagents burn more tokens between them than a single session does: each has its own context and makes its own tool calls. The win doesn’t come from running things in parallel, it comes from a cheap model on a cheap role: an explorer on Sol read-only, a worker on a middling model, the judge or the parent on a strong one. The classic mistake is to put a strong model on the parent and say nothing about the children: they silently inherit it, and the “economical” setup ends up costing more than one session would have.

How to choose a layer. Layer 1 is for a task that stands on its own and can be written down as a brief: HQ sees the model in the launch command, in the team journal and on the card; that’s our default. Layer 2 is for when a single Codex session breaks the work into scouting and building by itself and needs the parallelism inside the task; then the children’s models are pinned in the project’s TOML files and travel into the repo along with the code.

Key principles

1. A brief has four mandatory lines. First: the role, and “read your memory”. Third: “read the constitution and work by it”. At the start of the work: git log / status — what changed since your last visit. Last: “update your role memory, write the report, send it to session ”. A placeholder name for HQ means the report goes nowhere.
2. Model explicit, effort explicit. HQ at maximum. Sonnet mechanics at medium effort, through an environment variable in the launch command. A silent fallback to another model is forbidden: if it wouldn’t launch, say so.
3. Anything over thirty seconds goes into tmux. Not foreground (it blocks your turn), not a background shell (it dies with the session). The watcher is an until loop with a timeout on the log file, one per job; a single watcher covering many jobs goes blind.
4. Artifacts live in permanent places. Reports go into the repo’s scratchpad/, not /tmp: a reboot wipes temp folders along with the history of the work.
5. One shared repo means no parallel workers. Before a build or a deploy: the inbox and git status — somebody else’s uncommitted files ride along. And if the human is sitting in that repo in an interactive session, don’t start a worker there; give the task to that session.
6. Secrets live in the keychain and the environment, nowhere else. No .env in the code, no keys in reports, logs or commits. Scripts pull keys through a helper, and briefs carry the reminder “don’t print it to the log”.
7. Codify, don’t memorise. A rule that has fired twice goes into a hook, a gate, a script or a process manifest. Anything volatile — model, price, path, limit — goes into config, not into the body of the code or the prompt.
8. Reversible by default. Back up before changing, roll back in one move. Irreversible things happen only through the human’s list.
9. A broken assumption is not a reason to go quiet. The approved approach hit a new fact: if the replacement is reversible and the goal is the same, do it and report; if the goal, the money, the people or the publicity shift, stop and ask.
10. Vendor sync. Every piece of substantive work leaves a trace the other side reads: a report or a commit from Codex, a journal and a daily note from HQ. Every Codex brief carries a line about that trace.

Workflow

Morning. Restart HQ: the hook shows the handoff, cards that are due, the inbox, roles older than a week, orphans in tmux. One or two clean-up moves, then the actual work.

A task arrives. HQ works out whose thread it is: whoever touched the project last — reports, commits, role memory, the Codex context — gets the next task, unless the human said otherwise. It writes a brief with context, boundaries and acceptance criteria. It starts a worker and sets a watcher. If there’s a fork, a card goes into the registry with a default, right then.

A report arrives. HQ checks the facts that clash with its own context (the date in a filename is not the date of the event; “done” without a path is not done). It closes a card only against an artifact. It writes up the daily note and the context for the second track. It kills the tmux job once the result is collected.

The human answered some cards. Answer → action (close it into the log, or launch a worker), a reply in the card’s thread, and the inbox section marked as handled. An answer doesn’t close a card — HQ closes it, with an artifact.

Evening. A handoff note: what’s hot, what’s waiting on the human, what to do first tomorrow. Compaction by feel — the drift starts well before the ceiling.

Weekly. A review of role memory and the registry: cards that have gone stale, cards closed without an artifact, rules that are ready to be codified.

What the system is made of

• A global CLAUDE.md — who you are, where things live, conventions (tmux, secrets, commits), and an “Orchestration” section with the model matrix, the brief protocol and the human’s rule. This is the only place for orchestration mechanics; duplicating it elsewhere is how drift gets in.
• Repo maps — a CLAUDE.md at the root of every active repo. A worker starts with its cwd in the repo and picks the map up by itself; no map means the first worker writes one before doing the task; change the topology and you update the map with it.
• Roles — ~/.claude/teammates/<role>/MEMORY.md plus state.json, and a role definition (who it is, what it can do, which tools) for the agent type.
• A launcher — one script: --role, --brief, --model, --effort, --cwd, --session; it picks the provider (Claude or Codex), decides resume or fresh, writes the log with the exit marker, and retries on overload. You assemble a command by hand only for the cases it doesn’t cover.
• Briefs and reports — scratchpad/brief-<slug>.md and scratchpad/report-<slug>.md in the repo the task belongs to; scratchpad/ sits in .gitignore and in the deploy exclusions.
• A decision registry — pending-decisions.json plus decision-add / decision-close scripts with gates (unique id, a default, a cost on “approve” cards, an artifact on close), and a dashboard with buttons.
• An inbox file — markdown with sections ## <source> <date time> — <subject>; the writers are the messenger bridge, production bot alerts, Codex, and answers on cards; HQ keeps one Monitor on it and marks the sections it has handled.
• A team journal — a hook writes “started / done / stopped” events with the agent, the model and the task into jsonl; Codex is journalled by a wrapper; there’s a viewer in the dashboard.
• A constitution — eight short articles, each with its own “evidence”: the human has the last word (and one list of human-only actions); a claim rests on a source; reversible by default; a broken assumption is not a reason to go quiet; there’s an artifact, so there was work; codify rather than memorise; contours stay isolated (closed audiences don’t get mixed); executor continuity (a thread stays with whoever is running it). It changes only on the human’s word, with a version and a history.
• Bridges — messenger → inbox (for things that arrive on your phone), and “send this as me” only through a confirmation card with a one-time token.
• The memory watcher on Haiku 4.5 (the default) or on a local model: an OpenAI-compatible endpoint on a local server, with thinking switched off at the proxy, because background summarising doesn’t need it and it cuts the time by a factor of six. The local route only pays off with a model that fits in memory alongside everything else you are running.

Starter kit

A brief, at minimum:

# Brief: <what to do> (<who asked>, <date>)
Role: **<role>**. First thing: read your memory at `~/.claude/teammates/<role>/MEMORY.md`.
Task: <one paragraph, quoting the human's own words>.
Read the constitution at `<path>` and work by it; the repo map is `<path>/CLAUDE.md`.
You're inside tmux `job-<slug>-worker` — leave it alone, don't delete its log. Sub-jobs are `job-<slug>-<step>-sub`, yours only.
Before you start: `git log --oneline -8 && git status --short`.
## What to do
1. … (boundaries, what NOT to touch, how it will be checked, how to roll back)
## Report
`<repo>/scratchpad/report-<slug>.md`: … Update your role memory. Last step — SendMessage to session **<HQ name>**.

Launching a worker by hand (fish inside tmux; Sonnet mechanics get an effort prefix):

tmux new-session -d -s job-x 'claude -p --dangerously-skip-permissions --model claude-opus-5 \
  --settings \'{"crossSessionInbound":"accept"}\' "Read the brief at <path> and carry it out in full." \
  2>&1 | tee /tmp/tmux-job-x.log; echo "EXIT=$pipestatus[1]" | tee -a /tmp/tmux-job-x.log; exec fish'

A watcher (in HQ’s background, a window of ten minutes or less, then re-hang it):

until grep -q '^EXIT=' /tmp/tmux-job-x.log || [ $t -ge 560 ]; do sleep 20; t=$((t+20)); done

A decision card:

{"id":"site-og-v2","type":"approve","question":"yes → I ship the v2 OG cards to the site; no → v1 stays",
 "default":"yes","cost":"30 min of the web worker, reversible","artifact":"~/Vibe/site/scratchpad/report-og-v2.md","owner":"max"}

Questions to adapt it to you

1. How many projects do you run in parallel, and where do their files meet — home folder, notes, a monorepo? That’s where HQ lives.
2. Which subscriptions do you have: Claude (Max/Pro), Codex, API keys? That decides the model matrix and where the second track sits.
3. What is human-only for you? Write down five to seven actions you only ever do yourself. Agents do everything else by default.
4. Are you alone or working with people? With people, the decision registry and the inbox become shared, and roles get owners.
5. Do you have local hardware for local models? Then some of the background work drops to zero — but do the arithmetic honestly: a 27B model with a long context takes 30 GB, and on 64 GB it gets in the way of everything else. Without the hardware, the background runs on Haiku for pennies.
6. Where do your notes and decisions live now? HQ needs a base that both the human and the agents read — an Obsidian vault fits perfectly.
7. What’s your rhythm — you work during the day and want things to happen overnight? Then launchd/cron jobs, with the same briefs and the same reports.

Gotchas

• A headless session ends the moment it stops calling tools. A worker that finished its turn with “waiting for the render to complete” has simply exited. Waiting can only be done with a shell loop and a timeout — that rule goes into every brief.
• A headless worker’s log is empty until the very end. Zero bytes after two minutes isn’t death; death is the absence of a process. The watcher looks at the log and at tmux.
• A report sent to a placeholder session name is a report sent nowhere. You take HQ’s name from the session list while writing the brief and type it in literally.
• pkill -f <script> kills the tmux server if the string matches its arguments. Before any pkill, look at pgrep with your own eyes.
• A shared repo and parallel workers — somebody else’s files end up in your commit and in your deploy. Inbox and git status first, build second; one writer per tree.
• --fresh overwrites the role’s state. For two instances of one role, start the second one without a role or restore the id by hand.
• Plugin auto-updates wipe local patches. Anything you patched inside a plugin’s cache goes into memory with a path to the original and a check to run after every update.
• Vendor pricing differs on context. With OpenAI, requests over 272K of input are billed at double for input and one and a half times for output, across the whole request; with Anthropic it’s a flat rate up to 1M. The conclusion: keep briefs short, resume only when you actually need it, don’t drag a fat history around.
• A second agent agreeing with the first one is not yet a fact. Agreement is a claim too: you accept it after the same check — what it rests on, and what would make it false.
• A card with no default, or an “approve” card with no cost — that’s work pushed back onto the human, and cards like that stop getting read fast.
• Yours and theirs. What’s inside closed spaces, chats and client folders doesn’t travel into other contours — not as a retelling, not as a hint; only your own goes out. One worker serving every project is the most common way to break this.

Scaling up

• One worker → a fleet. As soon as you’re past two jobs a day: a launcher, one watcher per job, job-* killed once the result is collected, dev-* left alone.
• Roles. When the same genre keeps coming back — the site, a product, content, production incidents — create a role with memory, and the rakes stop repeating.
• A dashboard. Decision registry, inbox, journal, service health — one local page; your phone talks to it through the messenger bridge.
• The second track. Codex workers driven by briefs first, then Codex-Main as a long-lived session for review and processes, with an inbox cursor and the rule “accepted is not done”.
• Local models. Background calls — memory, classification, summarising — can move to a local server once the model fits in memory next to your actual work; until then the cheapest cloud model carries them, and the bigger cloud is left for judgement.
• The night shift. Launchd/cron jobs with the same briefs: digests, watchers, backups, note syncs; their results get linked into the daily note by the same job.

What you end up with

What the coding agent builds with you from this Blueprint:

• A global CLAUDE.md with an “Orchestration” section and the human-only list.
• A map of your first repo.
• A roles folder with two or three roles and empty memory.
• A worker launcher and a brief template.
• pending-decisions.json and the scripts to add and close cards.
• An inbox file and one HQ Monitor on it.
• A constitution v0.1 of five articles — changed only on your word.
• A first handoff note, so tomorrow’s HQ doesn’t start from nothing.