Twelve business owners sat around a table with a legal pad in front of each of them. Every legal pad had an AI question written on it. By the third question we heard out loud, I could feel the pattern. Not one of them was actually an AI question.
The customer-service one was a workflow question. “We reply to the same seven emails every day. Can AI do that?” The “which tool should we buy” one was a workflow question wearing a tool costume. The “can we use customer data in this thing” one was a policy question. The “who is going to check the output” one was an ownership question. The “what if it says something dumb to a client” one was a risk question. Twelve questions came into the room framed as AI. Zero of them were what I would call an AI question.
These are smart operators. They have read the newsletters. They have watched the demos. They have subscribed to more Substacks than they will admit to their spouses. They came into that room hoping the next explainer, the next expert, the next model release would unstick a question that has been stuck for six months. It will not.
You do not have an AI problem. You have a diagnosis problem.
The default move is to learn more
Here’s the thing. When a smart operator gets stuck, the default move is to learn more. Read another take. Watch another walkthrough. Buy another subscription. Ask another expert.
That is not laziness. It is the opposite. Learning is a discipline these owners trust because it has worked for every other problem they have solved. It got them through the last plateau. It got them through the last hire. It got them through the last time the industry changed on them. So they run the same play on AI.
And the pile of AI content in the inbox gets bigger, and the questions do not get any less stuck.
Right? More information becomes the way to avoid the harder move. The harder move is not to read another thing. The harder move is to look at the question you already have, and name what kind of problem it actually is.
That naming is a fifteen-minute job. Nobody does it. Because deciding what kind of problem you have would force a next move. Reading another explainer would not.
Yeah. There it is.
Diagnosis means locating where the work lives
Our Station Plan is the architecture of an AI-native business as a working kitchen. A Chef at the Hub for judgment and taste. A Pass in the middle for routing and ownership. Stations on the Line where the work gets done. And underneath every station, Ingredients: context, guardrails, examples, format, escalation, feedback, training.
You do not have to memorize any of that. The point of the framework is not that you learn its parts. The point is that it gives you four categories of where the stuck work actually lives. Every AI question maps to one of them.
Is this a Chef problem, meaning judgment or taste? The model can draft five versions, but only a human can decide whether this specific version ships. The stuck part is not the drafting. It is the taste at the end. That is not going to change because the model got smarter.
Is this a Pass problem, meaning routing or ownership? The AI produces output on schedule. Nobody owns the review. Nobody owns the escalation when it does something weird. The work happens, and then it sits.
Is this a station problem, meaning the work does not yet have a recipe? The team has never written down what “good” looks like for this task. There is no example. No format. No definition. The AI cannot cook a dish nobody has ever named.
Is this an ingredient problem, meaning the recipe exists but is missing a piece? The examples are from a client who left in April. The guardrail against a hallucination the current model no longer makes is still bolted on. The context describes the business as it was six months ago.
Four questions. Fifteen minutes. Most stuck AI questions resolve on the second one.
The five categories the reader will actually name
The Station Plan is the diagnostic architecture. It tells you where the problem lives structurally. The vocabulary a reader will actually use to describe the same problem is one layer more concrete. Workflow. Policy. Data. Ownership. Risk.
Every stuck AI question sorts into one of those five, and often into two at once.
“Should we use AI for customer emails?” could be a workflow question (the same replies repeat daily and we could speed them up), a policy question (are we allowed to reference the customer’s account by name in an automated draft), or a risk question (what happens the day it says something we would never say). Three different problems. Three different next moves. Same original question.
“Which tool should we buy?” is usually a workflow question wearing a tool costume. Nobody has named the work yet. Buying a tool for undefined work is how software shelves get built.
“Can we use customer data?” is policy or data. Sometimes both.
“Who checks the output?” is ownership. Always. Every time. The AI never solves ownership. Ownership is a decision the owner makes and communicates. It literally does not exist inside the tool.
“What if it gets something wrong?” is risk. What miss would actually hurt. What is the cost of the wrong output. What is the check that catches it before it goes out the door.
“Why is nobody on my team using it?” is a Pass problem in Station Plan language, or a missing output location in operator vocabulary. The tool exists. The seat license got paid. Nobody was told where its output lives. Nobody owns pushing that output into the workflow. Six months later the invoice hits, and the owner mistakes an ownership problem for a “the team is not adopting it” problem. Those are not the same thing. One is a personnel diagnosis. The other is a Pass diagnosis. The move on each is different.
Once you have the category, the Prep List tells you how to sort what moves first. But the sort does not happen until the naming happens. And the naming is not a Substack. The naming is a pen and a legal pad and twenty minutes with your own question.
Monday move
Pick one AI question that has been sitting in your business for more than sixty days. Not the whole list. One question. Probably the one that comes up in every leadership meeting and quietly gets pushed to the next one.
Do not answer it yet. Diagnose it. Name whether the real problem is workflow, policy, data, ownership, or risk. Fifteen minutes with a pen.
Then rewrite the original question as one diagnosis sentence. Not “should we use AI for customer emails.” Instead: “We have a workflow and ownership problem. Replies repeat daily, but nobody owns the approved response pattern or the review rule.”
The rewrite is the whole move. That sentence is worth more than the last four AI newsletters you read. You can act on it Monday morning. The newsletter you skimmed yesterday is still sitting in your inbox waiting to be turned into a decision that will not happen.
One guardrail. Do not shop for a tool until the diagnosis sentence is written. Every tool purchase before the diagnosis is a bet on a category you have not named yet. Some of those bets are going to be wrong. All of those wrong bets take three months to unwind and cost real money on the way out.
So.
The reason you are stuck is not that the AI space is confusing. The AI space is confusing. That is not the reason you are stuck.
The room in that peer-advisory session did not need another explainer. It had already read the explainers. What it needed was a fifteen-minute pass through its own questions, with the categories on a whiteboard, and one honest person willing to say “that is not an AI question. That is a workflow question.”
You are stuck because the question you keep asking is not the question you actually have. And every explainer you read is written to answer a category of question you have not diagnosed yourself into yet. So the answers land next to the question. Close. Never on it.
You do not have an AI problem. You have a diagnosis problem.
Does that make sense?
Original framework. Distilled from client work.
Framework spine: The Station Plan, used as diagnostic architecture, with a light callback to The Prep List for sorting the next move. Read the Station Plan.
~ source material · Original framework. Distilled from client work.
