Why “Workflow” Is the Wrong Primitive for AI Product Design

Workflow has become the dominant metaphor in enterprise software.

We model processes as sequences of steps.
We optimize handoffs.
We automate transitions.

For predictable, repeatable work, this approach has served us well.

The problem is not that workflows are bad.
The problem is that AI changes the nature of the work they are meant to support.

What Workflows Assume

At their core, workflows assume three things:

First, that work progresses linearly from one state to the next.
Second, that exceptions are rare and can be handled separately.
Third, that the system knows what kind of work it is dealing with early enough to choose the right path.

These assumptions hold when inputs are structured and variation is limited.

They start to break down as soon as systems are asked to interpret ambiguous, evolving, or context-dependent information.

Which is exactly what AI is introduced to handle.

What AI Actually Introduces

AI does not primarily introduce automation.

It introduces variability.

Two inputs that look similar may require different treatment.
An input that looked routine yesterday may become exceptional today.
Understanding may change as more context arrives.

This is not a bug. It is the value proposition.

But variability is precisely what workflows are least equipped to absorb. As variation increases, workflows don’t become more flexible — they become more brittle.

Teams respond by adding branches, conditions, and fallback paths. Over time, the workflow turns into a maze of special cases that no one fully understands.

The system still runs.
But governance quietly erodes.

Exception Handling Is a Symptom

Most workflow-heavy systems eventually develop a parallel universe called “exception handling.”

This is where real work happens.

Items are pulled out of the main flow, discussed, rerouted, manually corrected, and reinserted. The exception path grows until it becomes the norm.

At that point, the workflow no longer represents how work actually happens. It represents how the system wishes work would happen.

AI does not fix this. It accelerates it.

A Different Primitive: Assessment Before Action

There is another way to structure systems under uncertainty.

Instead of committing to a path early, the system first stabilizes an assessment.

What is this?
How should it be treated right now?
What is known, and what is still unclear?

This assessment is not a decision.
It is a snapshot of understanding.

Only once this understanding is explicit does action follow — which may still involve workflows, but now as a secondary mechanism.

In this model, workflows are tools, not foundations.

Why This Changes Design Decisions

When assessment comes first, several things shift.

UI design focuses less on moving items along and more on making interpretation visible.
Automation targets well-understood situations instead of pretending everything is.
Human input is used to refine meaning, not to patch broken flows.

Work becomes easier to reason about because the system’s current understanding is always available.

This does not eliminate workflows.
It puts them in their proper place.

Workflow as an Implementation Detail

In AI-driven systems, workflows should become increasingly invisible to users.

They operate behind the scenes, triggered by stabilized assessments rather than raw inputs.

From the user’s perspective, the system feels less like a conveyor belt and more like a continuously updating understanding of the situation.

This is not a radical idea.
It is how humans already work.

They assess, revise, and only then commit.

Designing for Change, Not Completion

Workflows are optimized for completion.
AI systems must be optimized for change.

As long as understanding can shift, systems must remain open to revision. Designing around assessment rather than flow makes this possible by default.

AI doesn’t make workflows obsolete.

It makes them insufficient as the primary design primitive.