The Amplifier Framework: the eight steps

Why eight, and why in this order

The framework was built backwards. It starts from the two failure modes and asks: what is the smallest sequence of decisions that prevents both?

Steps 1 through 3 protect against dependency. They force you to do your own thinking before you ever touch a tool. Define your end state alone. Map the flow yourself first. Decide deliberately what the tool is for. By the time AI enters the project you already own it; you cannot be hollowed out by something you have already structured for yourself.

Steps 4 through 8 protect against avoidance. They require you to actually use the tool — select one, set it up, direct it, evaluate its output, integrate it. By the time the work ships you have been hands-on with AI in specific, deliberate ways. You cannot fall behind by refusing to engage, because the framework requires engagement.

The iteration logic protects against sloppiness. Nobody's first pass is their final pass. Building the expectation of iteration into the structure means iteration stops being failure and starts being normal.

Skip a step and you slide toward the trap that step was protecting you from. Run them in order and you stay in the middle path. That is why eight — not because eight is magical, but because nothing smaller covers the ground.

The eight steps

1. Define the End State

   Alone. No AI. Write what success looks like — in paragraphs, not bullets, because bullets are sorting and paragraphs are thinking. Name the audiences specifically: not "the team" but "Sneha at her desk on Tuesday morning". Describe the texture of the outcome, not just the deliverables. Include the constraints. Keep it to a page.

   Why this step exists: what you want is a human question. If you ask AI to help you decide what you want, it gives you a competent generic version of what most people in your situation want, and you adopt it because it sounds reasonable. Now you have someone else's end state dressed up as yours. That is the first place the Dependent goes wrong.

   Most common failure: a deliverable list disguised as an end state. "Complete the migration with all tests passing" is a list. "A migration Karan can defend in his quarterly without hedging, whose documentation Sneha can use on Tuesday morning, and whose test reports let the client feel the team was awake" is an end state. The first produces generic work; the second produces work that fits.

   Chapter 7 (introduced); Chapter 8 (its failure drives the whole chapter); Chapter 9 (done well in fourteen minutes).

2. Map the Flow

   Three phases, and the trap opens if you skip any of them.

   Phase A — map it yourself first. From your own knowledge, even if incomplete, list every task from here to the end state. Sequence them. Mark what cannot start until something else finishes. Do not look at references. Do not ask AI. The act of making the list is the act of taking ownership of the project.

   Phase B — AI reviews your flow. Now bring AI in, not to build the plan but to review it. Share the brief and your list and ask one specific question: what is missing, what dependencies have I not seen, what sequencing errors are there, what would someone with deep experience of this kind of project have included that I haven't? You are using AI's breadth to complement your depth.

   Phase C — brainstorm each gap. For every gap AI names, neither accept nor reject. Ask why it is needed. Push back where you disagree. Reach consensus or a clear reason for declining. Then decide what to add and in what form. In the book, Vivek's fintech project gains a legal review and a competitor benchmark this way and declines a focus-group phase; Arjun's migration gains three tasks, one of them in a smaller form than the tool suggested.

   Principle: you cannot delegate what you have not structured. Human leads, AI validates, human decides.

3. Assign Tasks — Human or AI

   For each task in the flow, decide whether it belongs to a human, to AI, or to a hybrid with named human and AI parts. Use the Decision Filter below. If a task lands cleanly, assign it. If the answers are mixed, the task is too coarse — decompose it and run the pieces again. Ambiguity in assignment always means the task needs further breakdown.

   Most tasks split. Resist the temptation to assign whole chunks to AI or to yourself. In the book, "migrate the legacy integration module" becomes four sub-tasks before any of them lands cleanly; three separate documentation tasks turn out to be one.

4. Select the Right AI Tool

   For every AI-assigned task, which AI? Use the Tool Selection Logic. Using one tool for everything is a screwdriver for every repair: it works for some things, badly for others, and you never find out which because you never tried anything else. The book teaches selection thinking, not tools; brand names change every six months and categories do not. The tool directory carries current names.

5. Prepare and Direct

   The step most people skip. Before engaging any tool on any task, prepare three things: the full context (what this is for, who it is for, the situation, the constraints, what to avoid); the expected output (format, length, depth); and the success criteria — written down before you see anything, because once you see polished output your standards drop. The criteria are your protection against being seduced by polish.

   Then use two-step prompting: brief in plain language, let the tool write the optimised prompt. "Stop speaking the machine's language. Speak yours. Then let it translate."

6. Execute

   Do your human tasks. Direct AI on its tasks with what you prepared. Nothing fancy; the fancy thinking happened earlier. If the earlier steps were done well, this phase is faster than it used to be. Arjun spends two and a half days in setup and finds sixty percent of the work executed by Wednesday night — the proportion of thinking to doing has inverted.

7. Evaluate Against Your Criteria

   For every AI output, compare it to the criteria from Step 5. Not to how it sounds. If it fails, iterate: refine the input, add context, try a different tool. Do not accept polished output that does not meet what you specified. The Dependent ships polish; the Amplifier ships work that meets criteria. The Dependent cannot evaluate, because they never built the judgement muscle.

8. Integrate and Stress-Test the Whole

   Each task can be perfect and the assembled whole can still fail: the script and the storyboard each work and together they don't; every piece passes its test and the integrated thing feels generic. Put it all together, look at it as one piece, and check it against the Step 1 end state. Integration is a human skill. If it does not hold, decide which kind of problem you have — see iteration.

The Decision Filter — human or AI?

Four questions for every task in Step 3. In the book Vivek sketches them on a napkin.

The decomposition rule: if a task still cannot be assigned cleanly, it is not broken down enough. Decompose and ask again until every piece lands on one side. Try it on your own task list in the workbench.

The Tool Selection Logic — which AI?

Five characteristics for every AI task in Step 4. The categories are what matter; the names under them are what is around this year.

Two-step prompting

Step A — communicate like a human. Give context (why, background, who it is for), specifics (exactly what you want, what good looks like, what to avoid), and examples if you have them. Brief the AI the way you would brief a smart colleague who is new to your project. The quality of what comes back is directly proportional to how clearly you communicated what you needed.

Step B — let the AI optimise its own instructions. Once you have explained in plain language, ask: "given what I just told you, write me an optimised prompt that captures all of this, in the format you'd respond to best." Read it. Edit a line if needed. Use it.

The AI understands its own input format better than any human prompt engineer. You bring clarity of thought; it brings technical optimisation. That is amplification, not prompt engineering. The Dependent copies a template without understanding it; the Avoider refuses to learn prompting at all; the Amplifier speaks naturally and lets the tool refine the technical layer.

Iteration — small fixes and structural problems

When Step 7 or Step 8 reveals a problem, there are only two kinds, and telling them apart is the skill.

The test: can you fix this without affecting anything else in the plan? If yes, it is a small fix. If fixing it means changing other tasks, reallocating resources, or questioning what you originally wanted, it is structural. Iteration is not failure; it is the framework working as designed. The Dependent does not iterate because they accept whatever the tool gives them. The Avoider does not iterate because they never used the framework at all.

How the three types map to the framework