The case for using AI’s most feared behavior as a deliberate design tool
When people talk about AI hallucination, they are almost always talking about a failure. The AI confidently states something that isn’t true. It invents a citation, misremembers a fact, describes a policy that doesn’t exist, or assures a customer that their issue has been resolved when it hasn’t. The fear is well-founded. In a production environment where the AI is interacting with real customers and making real representations, hallucination is a serious problem.
But there is a context where hallucination is not a problem. It is a method.
Understanding the difference — and knowing how to use it — is one of the more counterintuitive and genuinely useful ideas in AI workflow design.
The production problem and the discovery opportunity
In a production AI workflow, the AI’s job is to make accurate representations about real states of the world. Did the refund get issued? Was the item found? Is the appointment confirmed? These questions have correct answers, and the AI must not substitute a plausible-sounding answer for a correct one. In this context, hallucination — generating a confident but inaccurate representation — is exactly what you are trying to prevent.
But in workflow design itself, before any production system exists, there is a different question that needs answering: what should this workflow look like if everything were working correctly? What is the ideal? What would best-class handling of this situation produce, if the right systems existed, the right people were notified, and the right authority paths were in place?
This question has no factual answer to look up. There is no database of “correct” workflow designs. The designer is not trying to retrieve an accurate fact — they are trying to generate a model of the ideal. And generating a plausible, coherent, expert-level model of how something should work is precisely what AI is very good at.
This is hallucination in the service of design. The AI is not describing reality. It is generating an ideal. And in this context, that is not a failure — it is the whole point.
How it works in practice
The technique is sometimes called a blind ideal workflow simulation. The word “blind” is important. The AI must not be told about the client’s current process, current limitations, workarounds, missing systems, or the gap between official policy and actual practice. If you tell the AI what the client currently does, the AI will adapt its suggestions to that reality, and you will get a slightly improved version of the current process rather than a picture of the ideal.
The prompt looks something like this: “You are in demo mode. You are not speaking to a real customer. You are not bound by any specific organization’s current process. Simulate the best-class workflow for resolving this situation. The customer’s problem is: they left their phone at a restaurant and they are trying to get it back. The resolved outcome is: the customer has their phone. Narrate the internal steps you would take if the proper systems, staff, records, and authority paths existed. Show me what ideal looks like.”
What comes back — when the prompt is set up correctly — is a workflow model. The AI narrates: receiving the initial report and creating a structured record; notifying the relevant staff and prompting them to search; logging any found items with physical descriptions; checking found items against open reports; notifying the customer when a match is verified; coordinating the pickup; confirming resolution. It identifies the authority checkpoints — the moments where a human must act to make a state real — and it names what each step produces.
This is the to-be model. The picture of the ideal, generated without contamination from the current reality.
Why the contamination problem is real
It might seem like giving the AI more context would produce better results. More information is usually better, right? Tell the AI about the client’s current situation and let it account for those constraints in the ideal model it generates.
The problem is that AI is very good at adapting to constraints. When you describe a limitation, the AI’s default behavior is to work around it rather than to name it as a gap. Tell the AI that the restaurant doesn’t have a formal lost-and-found system, and the AI will generate a workflow that functions without one — tracking items informally, relying on staff memory, using the host stand as a de facto repository. This workflow might even be an improvement on what the client currently does. But it is not the ideal. It is the ideal given the current limitation, which is a different and lesser thing.
The whole point of the blind ideal simulation is to generate the ideal without those concessions. Because the ideal — the pure to-be model — is what the designer uses as the interview guide when they go to work with the client. Every step in the ideal that doesn’t exist in the client’s current reality is a gap to be addressed. Every authority checkpoint in the ideal that isn’t defined in the client’s current operation is a design problem to be solved.
If the designer contaminates the to-be model with as-is reality before generating it, they lose the tool that makes the gap visible.
The discipline this requires
Using hallucination as a design tool requires a designer to hold two different relationships with AI output simultaneously. In production, the designer’s job is to prevent false or unverified claims from reaching the customer. The designer builds authority checkpoints, status language, and forbidden claims into the workflow specifically to contain what the AI says.
In discovery, the designer’s job is the opposite: to let the AI generate freely, without anchoring to current constraints, and to treat the output as a design model rather than a factual claim.
This is a significant mental shift. Many designers who are rightly cautious about AI hallucination in production bring that same caution into the discovery phase, and it costs them. They correct the AI when it describes a record system that doesn’t exist. They redirect when the AI proposes a notification path the client can’t currently support. They are, in effect, doing the contamination work themselves — importing as-is reality into the ideal model before it can be generated.
The discipline is to sit with the ideal, write it down, and only then bring it into contact with reality. First the to-be. Then the as-is. Then the gap. In that order.
AI’s generative capacity — the same capacity that makes hallucination a risk in production — becomes a genuine asset when it is deliberately aimed at a design question rather than a factual question. The key is knowing which kind of question you are asking and designing the context accordingly.
Since February 5, 2026, I’ve had the opportunity to study feedback from more than 18,000 complicated AI integrations running in production across 43 projects.
That work has taught me something important: AI workflow design is not just automation. It is a new discipline.
Humans do not arrive as clean tickets, categories, forms, or process steps. They arrive unfinished. They speak, the problem emerges, and the workflow designer has to understand what solution the human is actually reaching for.
I wrote this textbook to help other workflow designers think more clearly about that process.
The framework is built around five movements:
Emergence gives you the solution. Hallucination gives you the ideal. As-is discovery gives you reality. To-be selling gives you transformation. Stewardship gives you renewal.
The textbook is free to download below.