# The Systems-Architect Cheat-Sheet

*Print this. Keep it by your keyboard. It's the whole approach to designing and running a system on one
page.*

## You are the architect. Claude is the team.
You own the goal, decompose it, decide who does what, grant each specialist its access, and hold the
standards. Claude does the hands-on work of many specialists. You keep your hand on the switch —
nothing runs, and nothing acts on the world, without a checkpoint where you approve it.

## A system is several coordinated parts working toward one goal
Reach for a system — not a single tool — only when a job is too big for one tool, has natural stages,
and benefits from a specialist on each. *If one tool would do, build one tool.* The most common mistake
here is over-engineering; the skill is restraint.

## The architect's loop: decompose → delegate → coordinate → verify → observe → guard → know the limits

### 1. Decompose before you delegate
Break the goal into parts small enough to hand off cleanly. For each part, name its **job**, its
**inputs**, its **output**, and its **handoff** to the next part. Write it down as a short **system
spec**. A vague, giant delegation is the mistake underneath most system failures — *the plan is the
work.*

### 2. Delegate to specialists (subagents)
A **subagent** is a specialist that works in its own context and reports a *summary* back — keeping its
verbose work out of your main view. Built-in ones handle fast read-only exploring and planning; Claude
usually delegates automatically, or you can ask for one by name. **They run in the background** — start
a specialist, keep working, results come back. Don't picture Claude freezing while it waits.

### 3. Make custom specialists by describing them — no code
Tell Claude the specialist you want ("a summary-writer that reads this folder and drafts a one-page
summary…") and **Claude writes its definition for you.** You never hand-write it. Give it the smallest
set of tools its job needs, read-only where you can. *The exact file shape changes — the current
walkthrough is in the Companion Pack download.*

### 4. Coordinate with handoffs — sequential or parallel
Steps run **in sequence** (each feeds the next) or **in parallel** (several at once, then combined).
Parallel is faster but multiplies cost. The clean handoff between steps is what keeps a system from
jamming. Package a system you'll run again as a **Skill** (a saved, re-runnable recipe). Beyond that
sit advanced edges — an agent view for watching background work, an **experimental** agent-teams mode,
and **dynamic workflows where Claude writes code**; treat those as advanced and route specifics to the
Companion Pack.

### 5. Verify — there is no automatic check
A system that passes work between parts can pass a *mistake* down the line. There's no built-in
"make sure the output is right" step, so you build one: a **verification specialist** that cross-checks
the work against the source or the requirements before you trust it. If a specialist is cut off mid-task
it reports the partial work it managed rather than failing silently — read that, then re-run
deliberately (there's no automatic retry).

### 6. Observe — see inside every run
You can't manage what you can't see. Review what each specialist did and what it cost using the tools
that show inside a run — `/usage` (cost per session and per specialist), `/workflows` (running and
finished phases), the agent view, and saved transcripts. Read a run before you trust it, and now and
then after.

### 7. Guard at scale
- **Least privilege, per specialist.** The access you grant a specialist is the blast radius you accept
  for it. Read-only wherever it can be; never "just in case."
- **Human checkpoints at the risky joints.** Anything that sends, posts, changes a record, or moves
  money or files stops for your approval. Prepare by machine; commit by hand.
- **A cost ceiling.** Many specialists — especially in parallel or as teams — multiply token use (agent
  teams run roughly several times a single session). Set a monthly limit; prefer cheaper models where
  the strongest isn't needed. *(Prices and limits change — see claude.com/pricing.)*
- **A kill switch for the whole system.** Know how to stop every part at once, and confirm you can.
  Knowing you can stop everything is what makes it safe to run anything.

### 8. Know the limits
These are **supervised** systems: you drive, Claude delegates, you review. They are **not** autonomous
production systems; they don't come with guaranteed reliability at scale or unattended overnight runs.
Once you need an SLA, audit logs, automatic error-handling, or "it ran while I slept and fixed its own
problems," that's an **engineer** wrapping it in a real harness. **The wisest architects know what NOT
to build** — and when to bring one in.

## When a system misbehaves
Ask **"which stage?"** before "how do I fix it?" **Pause the system first.** Read each stage's output
in order until you find the first one that's off — the stages after it were only passing a mistake
along. Fix *that* stage, tighten the check after it, and re-run from there. If a change tangles things,
restore your last save point. You always have the restore.

## The Book 5 boundary
Everything here stays **supervised** — one system, specialists you scoped, a human at the risky joints,
a kill switch in reach. Running your whole practice or business on these systems is the optional
**Book 5, *The AI-Powered Practice*** — not something to bolt on here. *Buttons change; principles
don't.*