We used to design predictable user flows. Now AI can interpret, decide, and act on its own. Here’s why the hardest design decisions happen where that autonomy ends.
Showing where AI stops in the flow — by gptIn September 2025, researchers at Thinking Machines Lab ran the same prompt through a language model 1,000 times. They set the temperature to zero, a setting that should, in theory, make token selection deterministic.
They got 80 different completions from the same prompt, model, and settings.
What’s even more interesting is that all 1,000 outputs were identical for the first 102 tokens. The differences started at token 103, when the model described where Richard Feynman was born.
The researchers traced the variation to how computations were performed under different server batching conditions. With a modified implementation, they eventually got all 1,000 outputs to match.
Their research demonstrated something important. Even when you try to make a language model behave predictably, the infrastructure running it can introduce variation.
Now imagine building a product on top of that model. One that creates freight bookings, updates customer records, or moves medical documents between systems.
The problem isn’t that AI can produce different answers. That’s often exactly why we’re using it.
The problem starts when those answers turn into actions, and nobody has decided which parts of the process are allowed to be unpredictable.
For decades, we designed software around the assumption that we knew what would happen next. AI is making that assumption increasingly difficult to maintain. And I think a lot of early-stage teams are still designing as if nothing has changed.
—
We used to know what would happen next
Think about how we’ve designed digital products for the last few decades.
You open an app, select something, complete a form, click a button, and move to the next step. The interface responds according to predefined rules.
Michal’s project — TIER Energy networkA flight booking is a good example. Select your destination, choose a date, pick a flight, enter passenger details, pay, and receive confirmation.
There might be hundreds of conditions behind that experience, but the designer and engineering team can define them in advance. If the payment fails, show an error. If a seat is unavailable, offer another. If information is missing, ask the user to complete it.
This is the thinking that shaped most of our design tools and methods. User flows, wireframes, journey maps, information architecture, design systems, and interactive prototypes.
We design states and transitions between them. We decide what happens when someone clicks a button, makes a mistake, or returns to an unfinished process.
Traditional software was never perfectly deterministic. Search results changed, recommendations were personalized, and external services could fail. But the core behavior of most transactional interfaces was defined by explicit rules.
The designer didn’t need to know which flight someone would book. They needed to know how booking a flight worked.
What’s interesting is that the idea of software moving beyond explicit commands is not new. In 1993, Jakob Nielsen wrote about noncommand user interfaces. He described systems that could infer what users wanted instead of requiring them to communicate everything through specific commands. That was more than 30 years ago.
We’ve been imagining software that understands intention for decades. We just couldn’t build many of those experiences in a commercially practical way.
Now we can and that changes what it means to design a user flow.
—
The user no longer has to define every step
Imagine you’re designing a reporting tool.
Previously, a user would select data, configure filters, choose a report format, generate the report, and download it. The interface existed to collect instructions.
Classic vs AI flow — by gptToday, someone can simply write: “Tell me why our conversion dropped last month and what we should investigate.”
The product can interpret the request, retrieve information, compare periods, identify patterns, and decide how to present the findings.
We removed five steps from the interface, but we introduced a completely different kind of complexity.
What if the data is incomplete? What if two dashboards define conversion differently? What if the AI produces a convincing explanation that is actually incorrect?
A traditional user flow doesn’t fully capture these possibilities because the system can now make decisions about how to approach the task.
This is also where the difference between AI adoption and actual automation becomes interesting.
According to the 2026 Stanford AI Index, 88% of surveyed organizations reported using AI in 2025, up from 55% in 2023. Yet scaled AI agent deployment remained in the single digits across nearly all business functions.
Companies are using AI, but letting it run meaningful business processes is a very different challenge.
There’s a big difference between asking AI to draft an email and allowing it to send that email to 4,000 customers.
This is where UX becomes much more important than simply making the interface look intelligent.
—
Non-deterministic vs deterministic
I think it’s worth clarifying the terminology because we tend to mix these things together.
A deterministic system follows predefined logic. Given the same relevant input and state, the same rules produce the same output.
A non-deterministic system can produce different outcomes under apparently identical conditions. With generative AI, it’s often more useful to talk about probabilistic behavior, interpretation, and uncertainty.
Think about the difference between validating an email address and understanding what an email means.
Checking whether an email address has the correct format is a deterministic task.
Understanding whether an incoming message is a complaint, a booking request, or a pricing enquiry requires interpretation.
Now connect that interpretation to an actual workflow.
If the AI decides it’s a booking request, it might create a shipment. If it decides it’s a complaint, it might escalate the issue. If it identifies a pricing enquiry, it might prepare a quotation.
The user didn’t explicitly select a workflow. The system did.
So yes, the output might be non-deterministic UI. The wording changes, the content changes, and sometimes even the structure of what appears on the screen changes.
But the bigger problem is UX.
Users need to understand what the system is doing, predict the consequences of their actions, correct mistakes, and know when they can trust an outcome.
You can design a beautiful AI interface with great typography, smooth animations, and perfectly polished chat components. But if the underlying system makes decisions users cannot understand or correct, the experience is broken.
The difficult part is designing what the product is allowed to do with that response.
—
The biggest mistake is making everything non-deterministic
There’s an assumption that the more autonomous an AI product becomes, the better it is.
Why ask people to complete forms when AI can understand them? Why use predefined workflows when an agent can decide what to do?
Those are reasonable questions. But just because AI can interpret information doesn’t mean it should be responsible for executing every resulting action.
And just because a product uses AI doesn’t mean everything inside it has to behave probabilistically.
In fact, some of the more interesting AI products are doing the opposite. They’re deliberately combining deterministic and non-deterministic systems, deciding exactly where each one should take control.
A lot of failures come from making something non-deterministic that should have been a form.
This is especially relevant for early-stage founders. It’s tempting to turn every interaction into a prompt because it makes the product feel more advanced.
But sometimes a form, a predefined workflow, or a simple confirmation button is exactly what the experience needs.
Two products illustrate this particularly well.
—
Routine Labs: Let AI build the workflow, not improvise while running it
Routine Labs works on automating processes inside existing legacy software, particularly in healthcare. Its approach is interesting because AI is used to help build automations, while production execution follows deterministic workflows.
Imagine a medical practice dealing with documents across several applications. A blood test arrives and needs to be identified, checked against patient consent, and uploaded to Germany’s electronic patient record, known as the ePA.
Traditionally, someone has to move between systems, find the correct information, check the necessary conditions, and complete the process manually.
A fully autonomous AI agent could attempt to interpret and navigate that process every time.
Routine takes a different approach.
According to the company, its hybrid engine uses generative AI to create automations, but the workflows running in production follow repeatable, logged logic. On its healthcare website, Routine also states that it doesn’t use AI during production operations or transfer personal data to LLMs.
Routine Labs — by gptThat’s a very deliberate product decision. The uncertainty is concentrated in building the automation, where the process can be defined and checked. Production execution is designed to be predictable.
Now think about what that means for UX.
The user doesn’t necessarily need a conversation with an agent. They need to know what automation is running, which steps have been completed, whether the correct document was processed, and whether something requires their attention.
Routine’s public product examples show exactly this type of workflow: search for blood tests, check ePA consent, and upload the document.
The interface can communicate progress and exceptions through familiar patterns such as status indicators, execution histories, and review steps. No chatbot required.
And that’s what makes this approach interesting. The intelligence is used where it adds value, without making the entire experience dependent on the model interpreting the process correctly every single time.
Routine is an example of how you can build an AI-native product while keeping its actual execution deterministic.
—
Zauber: Let AI handle ambiguity, but make uncertainty visible
Zauber approaches the same problem from a different direction.
It builds AI agents for sea and air freight forwarding, working inside existing tools such as Outlook and integrating with systems like CargoWise.
Freight forwarding is an interesting environment for AI because so much operational work depends on interpreting unstructured information.
Emails, PDFs, packing lists, changing shipment details, special instructions, and incomplete documents. Information comes from different sources and doesn’t always agree.
An operator might receive an email requesting a shipment booking, with a packing list attached and a delivery date changed somewhere in the conversation.
Traditionally, someone would read everything, interpret the request, check the details, and manually enter the information into the booking system.
Zauber uses AI to handle much of that interpretation.
Its agents can read rate requests, identify relevant shipment details, retrieve rates, and prepare quotations for review. For booking creation, they can extract information from emails and documents and populate the necessary fields in CargoWise.
But the most interesting part is how the product handles information it cannot verify.
According to Zauber’s product page, if a declared value is missing or the volume doesn’t match the packing list, the system flags the discrepancy rather than guessing. The operator confirms the information before the booking is created.
Zauber visualized — by gptImagine the email says a shipment has a volume of 58.4 m³, while the packing list says 60.03 m³.
The AI has already completed most of the work, but the interface should make that disagreement visible, show where the information came from, and let the operator resolve it.
Instead of asking the user to complete every field, the product directs their attention to the two fields that matter. That’s a different way of designing workflows.
And there’s another detail I like about Zauber. Its product documentation describes monitoring agent sessions, including where the workflow hands control back to a human operator. The handover itself becomes something the company can observe, measure, and improve.
Routine and Zauber use different architectures, but they make a similar decision. They don’t treat autonomy as an all-or-nothing feature.
Creating a draft based on query: source: gozauber.comThey decide where the AI should interpret information, where deterministic rules should take over, and when the user needs to step in.
—
Why a great AI demo can become a terrible product
Here’s a simple calculation that explains why these decisions matter.
Imagine a workflow with ten steps. Each step has a 95% chance of completing correctly, and all ten steps must succeed. Assuming the outcomes are independent, the probability of the entire workflow succeeding is:
0.⁹⁵¹⁰ = 59.9% by gpt.A workflow that’s 95% reliable at each individual step could succeed end to end only about 60% of the time.
This is a simplified example, not a measured AI failure rate. Real systems have dependencies, validation, retries, and recovery mechanisms that change the result. But it illustrates why model accuracy alone isn’t a sufficient product metric.
An AI might extract information correctly most of the time. What happens when it doesn’t? What if an incorrect value gets passed to another system? What if an action succeeds but the confirmation fails? What happens if the agent repeats the action and creates a duplicate?
A lot of products look great because we’ve designed and tested the successful version.
The first time the model gets confused, the actual product experience begins. That’s where traditional design tools start showing their limitations.
A Figma prototype is excellent for representing predefined states. It’s not particularly good at representing a distribution of possible outputs, variable execution paths, or a failure that happens once in 50 runs.
This doesn’t make Figma irrelevant. It means static screens are no longer enough to validate the behavior we’re designing.
—
What happens when we ignore this?
One common failure is the illusion of completion.
An agent says it updated a record, sent an email, or created a booking. But perhaps it only prepared the action. Maybe an API failed. Maybe the system saved the wrong information.
If the interface displays the model’s response as proof that the action succeeded, the user has no reliable way to know what happened.
My own resourcesAnother is hidden uncertainty. Information extracted from a document might appear exactly like verified information retrieved from a database. The interface gives both the same visual weight, even though one is an interpretation and the other is an authoritative value.
My own resourcesThen there’s the opposite problem: excessive human supervision.
Some products solve uncertainty by asking users to approve absolutely everything. But if someone has to review 100 decisions and 98 are consistently correct, they eventually stop paying attention.
You’ve automated the original work and replaced it with a new job: supervising the automation.
My own resourcesThat’s not necessarily a better product.
There’s also the problem of incorrect decisions spreading through otherwise reliable systems. An AI might identify the wrong customer, after which every deterministic step executes perfectly while updating the wrong records.
The system worked exactly as designed, but the business outcome was wrong.
It takes us to the point when designing error states isn’t enough. We need to design the relationship between interpretation, verification, execution, and recovery.
—
How I approach designing this in an early-stage team
Working on a new AI product today, I’d start by mapping the workflow into three categories: deterministic, fuzzy, and irreversible.
It’s a simple exercise, but it forces you to make decisions that are easy to ignore when you’re focused on the demo.
Deterministic steps are operations with clear rules. Validating required fields, checking permissions, retrieving records, and preventing duplicate actions. These should generally be handled through conventional software.
Fuzzy steps require interpretation. Reading an email, understanding a document, classifying a request, or drafting a response. This is where AI becomes useful.
Irreversible or high-impact steps are actions with meaningful consequences. Sending an external email, issuing a payment, changing a sensitive record, or committing a booking. These need explicit permission boundaries, verification, and, where appropriate, human approval.
Deterministic, Fuzzy, and Irreversible steps — by chat gptOnce you’ve mapped those steps, a lot of product decisions become clearer. You can decide where the model is actually needed, what the interface needs to communicate, and which actions should never happen silently.
The next thing I’d do is stop treating the AI output as the interface itself. For many B2B products, I’d rather have the model return structured information and let deterministic components render it.
If an agent extracts booking information, the user should see a normal booking interface, not a paragraph explaining what the model found. The model fills in the card. It doesn’t need to invent the card.
Let’s take something everyone understands. Booking a flight.
You ask an AI assistant to book an early flight to Lisbon on Friday for you and Ania, returning Sunday evening.
First, the fuzzy part. The model has to interpret what “early” and “evening” mean, figure out which Ania you’re talking about, and make a few assumptions based on your previous bookings.
Instead of giving you a long chat response, the UI presents a structured draft. You can see what the model understood, where each assumption came from, and correct anything that looks wrong. Nothing has been booked yet.
My own resourcesThen comes deterministic validation. The system checks actual flight availability, passenger details, fare conditions, and prices against the airline’s data and predefined rules.
Everything checks out. Two seats are available, the refundable fare costs €398, and it’s within your budget. The interface shows a verified booking summary, without making you go through every individual check.
My own resourcesNow the interesting part.
You click Book, but the refundable fare sells out before the booking is completed. The only remaining option is €342, but it’s non-refundable.
Technically, it’s cheaper. It even