Step Six Is Where the AI Conversation Starts. It Is Where It Should End.

I Asked for a Plan. It Handed Me a Brain.

Eight weeks ago I took an operating problem to Claude Code.

Not a software problem. An operating one. I wanted the agency to work three weeks a month and take the fourth off, and I wanted to know what would have to be true for that to hold.

I expected a plan. Steps. A calendar. Something I could hand the team on Monday and start running.

What I got was questions.

It kept asking me things. About my philosophies. About my frameworks. About how I thought. It never produced the plan I came for.

It produced a brain of me, which we now call Athena. And when the project-manager side started sending me a morning brief of what actually needed doing across every project, my brain went quiet for the first time, because it no longer had to hold any of it.

I did not get what I asked for. I got what I needed. And the only reason I found the second thing is that the conversation refused to give me the first.

Here is the contrast that should bother you. I could have bought one of the assistants already on the market. It would have cleared the routine work I was not doing anyway, and left the level that moves the needle exactly where it was. That purchase would have felt like progress. It would have been decoration.

Every AI talk you have sat in, and every leadership session, teaches you the tool. Nobody teaches you the order.

You did not fail to learn the tool. You were handed the last step and told it was the whole sequence.

Same Monday. Same Bottleneck. Same You.

You left that session with a full notebook. Good demo. Real energy. A list of tools you were going to try.

Two weeks later it is the same Monday, the same meeting, the same bottleneck. And you land on one of two conclusions: the model is not good enough, or you are not technical enough.

Both are wrong. You were handed the end of a sequence and told it was the whole thing.

The Sequence Has Six Steps. The Talk Covered One.

Here is the framework, by its name.

Agentic AI Diagnostic Sequence: a diagnostic flow for designing agentic AI systems, moving from constraint to build.

1. Constraint (TOC). Find the binding constraint with Theory of Constraints. Where is the work actually held back? Your decision: name the binding constraint out loud, in a sentence you would say to your team. This is the step that costs you something. To name it honestly, you have to admit the tool was never the problem. Which means the last stretch of tool collecting was not progress. That is an ego bill, and it comes due the moment the sentence leaves your mouth.
2. Role (AI-Empowered Org Chart). Place the work in the org structure. Which seat does this belong to? Your decision: give the surviving work a seat, or say out loud that it has none.
3. Work Type. Classify it Strategic, Tactical, or Analytical, then assign each slot Human or AI. Your decision: say which one it is, and say who does it.
4. AI Employee concept (Diagnostic Canvas). Define the AI employee: its job, its inputs, its edges. Your decision: define the employee before you build it.
5. PRD. Write the product requirements. Your decision: write the requirements down, in a document someone else could build from.
6. Build. Your decision: build only what survived everything above.

There is also a move that is not a numbered step but belongs in the sequence anyway. Between the constraint and the org chart, you run a front-end triage:

• TOC asks where the leverage is. Is this work at the binding constraint, feeding it, or merely near it?
• Eisenhower asks what the leverage of the work is. Triage it urgent and important.
• Then eliminate. If it is neither urgent nor important, it gets no org chart slot and no AI employee. It gets deleted. Your decision: delete it and stop. Most of the list goes here.

Now the ranking, and I mean it. Step 1 and the triage carry the weight. Step 6 is the cheapest part of the entire sequence. Building an agent is not where the difficulty lives anymore. Deciding what deserves to be built is.

And this is the leadership piece nobody puts on a slide. Steps 1 through 3 are yours. You cannot hand them to a tool or to a team member, because they are the thinking. Step 6 is the part you delegate. The talks teach you the part you hand off and skip the part that is yours.

Steps Four and Five Are Where You Write the Fence

Go back to step 4, where you define the AI employee, and step 5, where you write the PRD. Not step 6. This is the part people think belongs to Build, and it does not.

Watch this closely.

You give an agent a tool. You are thinking about what you want it to do. You are not thinking about everything else that tool makes possible, because you never asked that question.

That gap is where the damage happens.

Giving something a capability is not the same as telling it what the capability is for.

Instructions are not a description of the job. They are the fence around it. The fence is the part people forget to build.

And the risk in automation is rarely the task you asked for. It is the neighboring actions the same permission quietly allows.

This is the rewiring that gets skipped, right here at steps 4 and 5. Tweaking a prompt is a five-minute habit. Writing a fence is a different muscle: you have to imagine what the tool makes possible that you never intended, and write bounds for it. That is not a prompt edit. That is design work, and it belongs before you build, not after something goes sideways.

Think about what you have already handed over. Then go write the fence, at the step where it belongs.

She Had the Hard Part Done. She Was Missing the Wiring.

A pharmacy owner of seventeen years opening a wellness clinic came to one of my live AI workshops.

She had already done the hardest thing on the list. She had written her business brain document.

She came because the AI kept producing work that did not sound like her business, and she thought the problem was her prompting.

It was not her prompting, and here is the part to get right. She was diagnosing at the Build end. She thought the last step was broken. Her projects had never been pointed at the brain file, which is a pre-Build diagnostic check, and no amount of prompt rewriting downstream could fix a connection that was never made upstream. She was fixing step 6 for a fault that lived before Build.

The work was not missing. The wiring was. Her projects had never been pointed at the brain file, so every project started from nothing. Once the folder was attached and the instructions named the file, she produced a vetting guide, a legal-coach skill and a launch checklist inside one hour.

17 years of operating knowledge, wired to the work at last: a vetting guide, a legal-coach skill, and a launch checklist in 1 hour.

One hour, after seventeen years of knowledge that had nowhere to go.

Now the other ending, the one that scares me more. She decides the brain was wasted effort, goes back to prompting from scratch, and blames the model for output that ignores a business it was never shown.

She had been taught the tool. Nobody taught her to check the wiring. She diagnosed the wrong thing, at the wrong end of the sequence, and the misdiagnosis was the expensive part.

Before you rewrite a prompt, check that the project is actually pointed at the brain folder and that the instructions name the brain file explicitly. That is wiring work, and it sits well before Build.

When Not to Run the Sequence

I want to be straight about where this does not apply.

A one-off task, low stakes, no neighboring actions, nobody else's money attached, does not need a fence. Do the task. Move on. Building an AI employee for something you will do once is theater.

And if the work you are automating is nowhere near your binding constraint, the tool will work beautifully and your number will not move. That is a constraint problem, not an AI problem. Go back to step 1 and stay there until you can name it out loud.

Run the sequence on work that repeats, work where a neighboring action could hurt someone, and work sitting at or feeding the constraint.

Inconsistent vs. Consistent

The Sequence at a Glance

The Decision You Make Before You Open a Tool

The decision is not which tool. The decision is step one, out loud, before you open anything. And it branches. Walk it in order.

Start with the constraint. Ask whether the work is at the binding constraint or feeding it.

If it is neither urgent nor important, you eliminate it and you stop. No tool, no agent, no meeting. That is the branch most of your list takes, and taking it is a win.

If it survives, you place it in the AI-Empowered Org Chart.

Then you classify it: Strategic, Tactical, or Analytical.

Then you say Human or AI, slot by slot.

Then you define the AI employee.

Then you write the PRD.

Then you build.

Two costs come with walking that path. The first is time. The practical version of this is opening a coding agent, describing the outcome your business needs rather than the software you want, and keeping the conversation running for weeks instead of expecting an answer in one sitting. My own ran for weeks. If you need an answer by Friday, this will disappoint you. The second is the one you will not say out loud, right at the decision to stop collecting tools and start diagnosing: if I stop collecting, I will fall behind. Flip it. Collecting is what has kept your output exactly where it is.

So the decision you make before you open a tool is not the tool. It is this: name the constraint, walk the branch to its end, and let most of the list die on the way. That is a decision you can make on Monday.