Why the design target you choose determines everything downstream
Most workflow design begins by asking: what does the current process look like, and how do we make AI follow it?
This is a reasonable question. It is also almost always the wrong place to start.
The problem is not that the current process is irrelevant. It is that when you begin with the current process, you design the AI to serve the process rather than to serve the person. The process becomes the authority. The person — with their specific situation, their specific concern, their specific definition of what a resolved outcome looks like — fits into the process as best they can, or they don’t fit, and the process fails them.
A better starting point is the solution. Not the workflow. The solution.
Two ways to design the same workflow
Here is a concrete example. A restaurant deploys an AI voice agent to handle calls about lost items. There are two ways to design this.
The first way: study the current lost-and-found process, map the steps, and build AI to execute those steps. The customer calls, the AI collects their contact information and a description of the item, logs a report, and says something like “your report has been submitted, someone will follow up within 24 hours.” The workflow mirrors the existing process. It is faster, more consistent, and available at 2 a.m. when the manager isn’t there to answer. By most definitions, this is a successful AI deployment.
The second way: start by identifying what the customer actually needs, and use that as the design target. The customer’s need is not to submit a report. The customer’s need is to get their phone back. These are different things. The design target in the first approach is a completed report. The design target in the second approach is a found phone.
Now build the workflow backwards from the design target. What would it take to reliably produce a found phone, not just a completed report? The workflow now has to ask questions the first approach never asked. Is there a physical location where found items are collected? Does anyone check that location when a report comes in? Who is allowed to verify that a found item matches a description? How does the customer get notified? What happens if the staff member who finds the phone doesn’t know a report was filed?
The report-based workflow can’t answer these questions because it never asked them. The solution-based workflow has to answer them, because a found phone requires the full chain to work — and the full chain only gets designed if someone started from the solution.
The equation
There is a simple way to think about this. Every customer contact contains two things: a problem statement and a solution statement. These are equivalent to each other, like two sides of an equation.
The problem statement is what the customer says. It is often messy — uncertain, emotional, not fully organized, containing side details and tangents and things the customer isn’t sure are relevant. This is not a defect. This is what live human speech looks like when a person is working through something they haven’t fully resolved yet.
The solution statement is what would make the problem no longer a problem. It is cleaner than the problem statement. For a customer who left their phone at a restaurant, the solution statement is: found phone. For a customer anxious about a charge they don’t recognize, the solution statement is: financial security restored. For a customer who had a bad experience and is calling to make sure someone knows, the solution statement is: experience made right.
Notice that the solution statements are conditions, not processes. “Found phone” doesn’t specify how the phone gets found. “Financial security restored” doesn’t specify whether the resolution involves a reversal, a credit, or a confirmation that the charge was legitimate. “Experience made right” doesn’t specify whether the resolution involves an apology, a refund, a free meal, or a manager conversation.
The solution statement names the end state. The workflow is the mechanism for getting there. And the mechanism — all of it, every step, every routing decision, every staff notification — is in service of the end state and only in service of the end state. Nothing in the mechanism is sacred. The end state is what matters.
Why this changes the design questions you ask
When you start with the solution, the questions you ask in the design process change fundamentally.
If you start with the process, you ask: what does the system need from the customer to proceed? What information is required at each step? What categories does this type of request fall into? These are reasonable questions for executing a process. They are not the questions that produce good outcomes for customers.
If you start with the solution, you ask: what would it actually take for this person’s situation to be resolved? What are the steps between the messy problem statement and the clean solution? Where does the system’s capability end and human authority begin? What can the AI handle entirely on its own, and what requires a real person to act?
The second set of questions tends to surface things the first set misses. It surfaces the authority gaps — the places where no one has decided who is actually responsible for taking the action that makes the resolution real. It surfaces the record gaps — the missing databases, the informal tracking systems, the staff members carrying critical information in their heads. It surfaces the status gaps — the places where the workflow is silent about what has happened and what hasn’t, which is where false completion tends to occur.
None of these gaps become visible when you start from the current process, because the current process was built around the gaps. It was built to function despite the gaps, through workarounds and informal relationships and the tacit knowledge of experienced staff. The AI that mirrors the current process inherits all of those gaps, and they become the AI’s gaps, and eventually they become the AI’s failures.
Starting from the solution forces these gaps into the open before the AI is deployed, while there is still time to do something about them.
A practical reorientation
This is not a complex theoretical framework. It is a simple reorientation of the design question.
Before designing any AI workflow — before mapping the current process, before writing a prompt, before choosing a tool — ask: what is the condition that would make this person’s problem no longer a problem? Name that condition in one sentence. Then build toward it.
That sentence — the solution statement — is the design target. Every subsequent decision can be tested against it. Does this routing path serve the solution? Does this status message honestly represent where the process stands relative to the solution? Does this authority checkpoint, this record, this notification, this escalation path — does it move the workflow toward the solution, or does it serve the process for its own sake?
When you have a clear solution statement, these questions become answerable. Without one, they are invisible. And invisible design questions produce invisible design failures — the kind that show up not as system errors but as customers whose problems were technically processed but never actually resolved.
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.