Run a Three-Claude Operating Model: Chat Plans, a Task Window Orchestrates, a Coding Agent Builds
- Level
- pro
- Time to complete
- 45 min
- Prerequisites
- 5
What you will buildStop being the copy-paste message bus between your AI windows. Wire three roles together with a plain-folder hand-off so you approve at gates instead of relaying every message.
What You Will Build
You will build a three-role operating model for AI development and the plain-folder hand-off that connects it. One AI is the architect: a chat window that plans, audits, and sets the quality bar, but never touches code. One AI is the orchestrator: a long-running task window with filesystem access that holds state and routes work. One AI is the executor: a coding agent that implements, runs tests, and reports back. They talk to each other through a shared folder of plain files - an inbox and an outbox - instead of through you.
The point is to get you out of the seat where you copy a plan from one window, paste it into the next, copy the result back, and relay the correction. That relay is the bottleneck. By the end of this you will have a working inbox/outbox hand-off, three written role charters, a gate policy that says exactly where you approve, and one real task that has moved from spec to report to approval without a single copy-paste between windows.
Prerequisites
- A chat AI you can use for planning (the architect) - any capable chat model.
- A task-window AI with filesystem and tool access that can run across a long session (the orchestrator).
- A coding agent that can edit files and run tests in your repo (the executor).
- One project folder on disk, under git, that all three can see or that you can shuttle files into.
- Basic comfort with a terminal, git, and reading a Markdown file.
Tip
You do not need three separate products with special integration. Three ordinary windows and one shared folder are enough. The folder is the integration.
Mental Model
When you run three AI windows by hand, you are the message bus. Every plan, every result, every correction passes through your copy buffer. Remove yourself from the bus and put a folder on disk in your place. The architect writes a spec into the inbox. The orchestrator reads the inbox, turns the spec into a task, and tracks it. The executor builds the task and writes a report into the outbox. You read the outbox and approve at the boundaries that matter. The disk holds the state; the disk is the thing grep can search and git can version; the disk is auditable whether or not anyone is watching.
The role split is the whole trick. Each window is good at a different shape of work and bad at the others, so you keep them apart on purpose. Keeping writes to the codebase flowing through the executor alone keeps the work single-threaded where it needs to be, while letting each decision happen in the context that fits it. This is the orchestrator-worker pattern that Anthropic describes in Building Effective Agents, with the human kept "at checkpoints" rather than on every message.
Steps
Each step is one action and how you know it worked. The first two set up the folder and the roles and are free; the rest wire the hand-off and unlock with Supporter.
Create the hand-off folder
Make one folder tree that is the shared state for all three roles. Everything travels as a plain file inside it.
mkdir -p ops/charters ops/inbox ops/outbox ops/state
printf "# STATE\n\nphase: idle\nactive_task: none\n" > ops/state/STATE.md
printf "# LESSONS\n\n" > ops/state/LESSONS.md
printf "# GATES\n\n" > ops/gates.md
git add ops && git commit -m "ops: hand-off skeleton" >/dev/null
You know this worked when ls ops shows charters inbox outbox state gates.md, and ops/state/STATE.md exists with a phase: line. This tree is the bus; nothing below sends a message any other way.
Write the three role charters
Give each window a written boundary so it stays in its lane. Put one short charter in ops/charters/. These are the system framing you paste into each window at the start of a session.
# architect.md
You PLAN and AUDIT. You never edit code or run commands.
Read ops/state/LESSONS.md first. Write one spec to ops/inbox/<id>-spec.md
with: goal, constraints, and a checklist of acceptance criteria that an
independent reviewer could verify. Stop after writing the spec.
# orchestrator.md
You HOLD STATE and ROUTE. You do not architect and you do not implement.
Read ops/inbox, turn each spec into ops/inbox/<id>-task.md, update
ops/state/STATE.md after every phase, and pause at any gate in ops/gates.md
until STATE.md shows the human wrote APPROVED.
# executor.md
You IMPLEMENT. You do not plan. Build exactly the task in ops/inbox/<id>-task.md,
run the tests, and write ops/outbox/<id>-report.md in Build/Break/Fix/Verify
form with a PASS or FAIL and evidence on every line. Make surgical edits only.
You know this worked when ls ops/charters lists architect.md, orchestrator.md, and executor.md, and each one names what its role must NOT do. The boundaries are the point: a role that can do everything is back to being a relay.