Most "AI workflows" are one phase: type a prompt, hope.
Mine has four.
The build doesn't start until phase four.
By then the AI is barely making decisions.
It's executing a contract.
Phase one: Brainstorm
Open conversation. No structure, no acceptance criteria yet, no scope. I yap. Claude compresses what I yap into a `.md` file in real time. We argue. We rule things out. We name the actual outcome I'm chasing, not the thing I thought I wanted when I started talking.
The output of phase one is one sentence: **what done looks like.**
CRUSH started as "I want a video plugin that feels analogue." Two hours of brainstorm later the doc said: "14 Metal fragment shaders, a 6-slot effect chain, three global controls (DECIMATE, SPAZ, CHILL), real-time on Apple Silicon, drag-and-drop in DaVinci Resolve." That's the outcome that got dispatched.
Phase two: Implementation plan
Now I take the outcome and ask Claude to architect it.
Files, dependencies, the order things get built in, the places it's likely to fall over.
This is still in the main session. Still advisor seat. Zero code written.
The plan for CRUSH was a 6-stage build pipeline. Format design, build-time generator, plugin core, 2D shaders, splat engine, AE port. Fourteen Metal fragment shaders authored as `.crush` JSON files. A Python codegen that writes the entire C++ OFX boilerplate at compile time so adding a new effect later is JSON plus a shader function and nothing else. Every stage had acceptance criteria, file scope, and risks named upfront. By the time it was done, the plan was a single markdown artefact a fresh worker could execute against without ever talking to me. That's the goal. The plan is the spec. The spec is the thing.
The plan also names risks before any worker meets them.
It says: "Metal kernel buffer names must match this exact contract or DaVinci silently rejects the bundle."
It says: "Real-time on Apple Silicon at 4K is the gate.
If a shader drops frames during scrub, it doesn't ship."
Risks named upfront are risks that don't ambush a worker at 3am.
## Phase three: Handoff doc
This is the artifact.
The brief.
A file a fresh worker can open cold, with no memory of phases one and two, and execute against.
A handoff doc has: scope, files in play, acceptance criteria, the one condition that makes the worker stop and surface to me, and the thing I want to be sitting on top of when it returns. It's tight on purpose. A worker reading it shouldn't need to ask me a single question.
If I can't compress the brainstorm into a brief, I don't understand the outcome yet. Phase three is where bad ideas die.
Phase four: Dispatch
Now and only now does code get written.
The brief goes to a background worker on its own branch, with its own clean context, its own budget line.
Main session stays in the advisor seat. I review the diff when it lands.
This is the advisor-driven development pattern Anthropic publicly described as the advisor tool: a senior model holds judgment, cheaper executor models burn through the mechanical turns, and complexity escalates back up the stack.
I run it as the spine of every build. Opus advises. Sonnet executes.
The advisor only spends tokens on judgment, not keystrokes.
The same four phases produced CRUSH (14 effects, shipped April 7) and every other plugin in the suite. None of them started with a prompt.
Why this maps to ICM
The brief itself is an Intent Context Model. Three layers, encoded in one file:
- Intent: what done looks like (the output of phase one)
- Context: files, constraints, risks (the output of phase two)
- Model: which executor gets the work (selected at dispatch)
People skip straight to Intent and wonder why their AI is hallucinating.
They handed it a wish, not a contract.
ICM says all three layers ship together or the worker is guessing.
The principle
The build is the easy part.
The thinking that produces the brief is the work.
Most people spend 10% of their time defining outcomes and 90% babysitting prompts.
Flip it.
Spend 90% on phases one through three. Phase four runs without you.
Stop prompting. Start defining outcomes.
Below are two examples of implementation plans, one for Crush and one for how I built my advisor-driven development.
// A<3