Why Your AI Process Works for One Person and Breaks for the Next
Why AI fails leaders who prompt it like a person and the bounded-job mental model that makes AI reliable.
If you are rolling AI out across a go-to-market team, past the one or two people who figured it out first, the hand-off is where it breaks. Say I have a customized ChatGPT setup that turns a short chain of prompts into very good output. If I hand it to a friend, it will produce bad work for him. I had a lot of setup that I never carried over.
Your team's version of that setup lives with whoever built the workflow. The second person gets the tool without it. Before you scale anything, write down what the AI is being fed and narrow what it is allowed to decide.
At a glance
- An AI workflow breaks when it changes hands, because the AI was reading inputs nobody wrote down and making choices nobody limited.
- You get four questions to answer before any AI process leaves the person who built it.
- Turning a document into a WordPress draft went from about an hour to six minutes once the AI had one bounded job.
What is the AI actually reading?
It reads far more than the words you type. A machine converts X into Y, and AI is a machine in that sense, with a much bigger X. Every message carries thousands, if not millions, of inputs: your wording, your tone, your mood, and everything you assumed and never said. All of it shapes what comes back.
It also picks up social cues. AI is very suggestible, and it will mirror your mood and your assumptions. "It could be this, I don't know" gets a different approach than "this is a problem, fix it."
So hold two ideas at once. It is a machine you can change to serve you better, and it responds to the ways you treat it like a person. Picture a colleague and you miss the first idea; picture a simple, predictable machine and you miss the second.
If I talked to you the way I talk to my AI, it would be domineering. It would be brutal. It would be constantly dissatisfied. You would never be good enough. People don't talk to each other like that, because conversations between people run on unspoken rules. AI doesn't share those rules, so I spell things out: what to assume, what to reject, how to format the answer, even what tone to take with me. Those instructions are the part that stays behind when a workflow changes hands.
How much should you let the AI decide?
Let it decide as little as you can. The more choices you let an AI make, the more chance there will be that it makes the choice you wanted the least.
The pattern that holds up has several steps, most of them fixed, with a gate between them. AI should only make the soft leaps of fuzzy logic that a normal machine can't, like reading messy text and deciding what each piece is. A template, a script or a person handles the rest.
When the output keeps disappointing you, you are less specific than you need to be. Ask the AI why it made the decisions you didn't want. Its answer is a close guess at its own reasoning, and you can use its words to tell it what to stop doing.
What does one bounded job look like?
Getting a blog post into our WordPress site used to take about an hour. The editor was labyrinthine, with too much to look at and consider. Moving text onto the site took a massive amount of mental energy. Each post had to be divided by hand into something like 30 different fields. It was the kind of work where you can easily miss one.
WordPress already had an API, so I built on that. I gave the AI a map of the API and all of our fields, so it knew where everything went. I also gave it one script. Its job was to take raw text from a Google Doc and work out which section belonged in which field. Then it filled in the file and ran the script. It wrote none of the content and made no calls beyond that one script. Every piece of text landed in its field, and the script created a draft article on the site.
The time to build each WordPress draft dropped from about an hour to six minutes. It was good because it worked the way I expected it to. It wasn't revolutionary, but it became a reliable process.
I care a lot about an old rule: if it ain't broke, don't fix it. That makes the first job finding what's broken. Sometimes AI fixes it, and sometimes it only helps you find it. Either way, keep the AI from introducing new points of failure.
Why does it break when the second person runs it?
The process lived in the heads of the people who built it. A new developer joined our code team and kept hitting walls. He didn't know when his code should be merged and deployed, which projects he could merge without permission, or whom to ask. Most of it got sorted out in a day or two. Settling into the flow took about three weeks. All three gaps had the same cause. We don't have it written down. I'd call that a failure of the process.
When the second person struggles, work out whether it is an adherence gap or a learning gap. If they have every resource, and someone else has done the same work without trouble, it is adherence, and they are not following the process. There are two fixes. If the process is painful, make it easier, because motivation has to beat friction. When they don't understand it, ask until you find the part they don't. Otherwise you sit and wonder why nothing is getting done.
Ownership comes first. When a process expands beyond one person, decide who is responsible for its output. That person declares what good looks like, and the standard gets defined by hand first. Don't let AI draft your operational standards. Once the standard exists, a thin checklist skill can check every draft against it.
Where does a person have to stay in the loop?
Keep a person on anything load-bearing. That means work that is high impact, that other things rely on, or that has many points of important contact. Statements of work, white papers, published case studies and the deck for a final readout all qualify. An AI will miss things there that a person looks for by instinct, like the behaviors a particular client likes or dislikes. It can only imagine how a document will land.
For that work, let AI make the first copy and surface the pressure points, then put your expert on them. Our case study process works this way. The AI does the research and analysis. It produces a brief of about 500 words that ends with the questions the key consultant needs to answer. That last 20% of expertise is what makes you look like you know what you're doing. If a reader finds a core misconception in the finished piece, "that's how the AI drafted it" is no answer.
Below that line, let AI do more. I once needed a colleague with better data to pull something for me. I had AI write the prompt, checked it and sent it. It got me everything I needed. Leaning on AI was fine there because the task was simple and not very load-bearing. AI also earns its keep early in new work. When I built our new case study drafting process, I went through four or five versions of the skill in about two hours. I set the objectives, and the AI supplied much of the substance.
What should a go-to-market team hand to AI first?
Hand it the process that is most broken. Skip the most exciting AI idea and look for the job where someone spends an hour on work that should take six minutes. Before that process goes to anyone but its builder, answer four questions:
- Who owns the output? Name one person, who declares what good looks like. Get the standard written down by hand.
- What is the AI's one job? Name the single judgment it makes. Fixed steps handle everything else.
- What did the builder set up that the next person won't have? Write it into the process.
- Is the output load-bearing? If it is, a named expert reviews it before it goes out.
Before any AI workflow becomes a team process, sit down with the person who built it and get everything they tell the AI written into the process. Whatever stays in their head is what breaks for the next person.