An agent does not fix a process. It inherits its exceptions.

The new screen knows your name. It summarizes your request in calm, complete sentences. It tells you what it found, what it’ll do next, why the missing approval matters.

It’s beautiful the way a reception area is beautiful.

Polished. Quiet. Nowhere near the room where your actual problem sits.

You’re not foolish for liking it. You’ve got the old checklist folded beside the legacy system. You know which field doesn’t save. Which mailbox answers after lunch. Which request needs a second subject line because the first one vanishes.

You’ve got messages to clear, people waiting, a life outside the building. When something turns that clutter into a conversation, you take the help.

That isn’t a failure of nerve. It’s what anyone does once the work has grown its own unofficial map.

No machine in this story wakes up.

The worry is duller and closer.

Put an agent at the front of a broken workflow and your breakage gets more fluent.

Not less real.

2012 — You keep a checklist beside the legacy system.

2018 — The workflow adds a form.

2024 — The AI explains the form back to you.

2026 — It still can’t tell you which inbox holds the missing approval.

The form never knew that inbox existed, because the process wouldn’t admit it existed. That’s what a good interface makes easy to forget.

Your missing approval isn’t an awkward fact outside the flow. It’s an exception. It’s got a cause, an owner, a clock, evidence, and a decision sitting behind it somewhere.

An agent can make you feel considerately delayed. It can’t find out who decides by becoming more articulate.

The map comes first

You start with a case, not a demo. “Automate invoice processing” is too broad for anyone to test.

You want a named population. An observable outcome. A first event that puts a case in scope. Terminal outcomes, systems, an accountable person, a permitted decision.

That’s a boundary.

It survives contact with your actual work.

And your question comes before your extract. Which cases predict a manual touch? Where does a complete request wait between validation and approval?

Three fields make event evidence exist at all: case ID, activity name, timestamp. The rest — time-zone meaning, source system, record owner, the joins behind each event — is what stops your map being a portrait of the data pipeline instead of the work.

Here’s where you matter and the tooling can’t help. A map isn’t discovered because a mining tool drew one.

You’re the one who reconciles the complete, cancelled, reopened and difficult cases against the people who produced them.

A case key gets reused.

A status means two things in two systems.

A timestamp records batch posting rather than work.

You knew that. The tool didn’t.

Even the tidy view has a limit. Keeping your ten most frequent activities makes a route readable. It doesn’t let anyone erase the rare high-risk event, the low-frequency exception, the case that breached a service promise.

Those get their own view. They’re where a process stops being a sequence and becomes an act of judgment.

You’re not resisting the new layer because you’re attached to your old workaround. You’re remembering where the work actually catches.

A revised form might fix it. A mandatory intake field. A clearer approval threshold. Two standardized routes instead of the eleven you improvised.

The smallest change that solves your diagnosed problem may not be an agent at all.

That isn’t anti-technology. It’s letting the problem choose the intervention.

The normal route lies

Once you can see the case, you can write the ordinary route for someone who started on Monday. Entry condition, required data, sequence, decision rule, quality check, record update, notification, terminal state.

Lean asks standardized work for three things: your demand rate, your precise sequence, and the standard inventory that keeps work moving. In a service process that inventory is mandatory fields, authoritative documents, approval authority, a complete audit record.

That’s the promise automation can actually keep.

Take an ordinary, complete case. Move it through an explicit route. Stop asking a tired person to remember the invisible parts.

But your normal route isn’t a process if it’s the only route anybody designed.

Every exception you expect needs a trigger, a reason code, required evidence, an urgency, a destination, a decision authority, and an exit.

There are three exits. Correct the case and re-enter the normal route. Take an approved alternative. Cancel it.

That’s not decoration. A queue with no exit doesn’t resolve your uncertainty. It stores it.

An unreadable attachment goes back for replacement. A supplier bank-account change needs a verified control. A contract dispute needs a commercial owner.

None of those are variations for an agent to smooth over in defence of its completion count. They’re different kinds of work.

Your standard has to be strict enough to stop unsafe automatic completion, and narrow enough that ordinary cases don’t get dragged into ceremonial review.

Both failures are common. Only one of them gets audited.

Release is the next place a cheerful interface will lie to you.

Individual rules, end-to-end cases across systems, and operating tests with the people who receive the exceptions are three different test levels.

A rule passes in isolation. Then a retry, a duplicate message, a late update or a dead service leaves your case in the wrong state.

So you keep the release small. One channel, one geography, one value band, one queue.

The old procedure stays live. You write the switchback condition down while nobody needs it yet.

The agent moves in

An agent isn’t the exception to this sequence. It’s a more demanding tenant of it.

Take the supplier bank-detail change you’ve processed a hundred times. The run gets one immutable identifier, bound to requester, supplier record, tenant, policy version and time.

Before it plans anything, three deterministic checks. Is the case open. Is the requester assigned. Is the supplier in scope.

None of that is interpretation, and it shouldn’t be. A fixed rule belongs in a deterministic workflow.

Interpretation isn’t a permission slip for ambiguity.

The run begins in received. From there it permits six named states and nothing else: gathering, awaiting_approval, executing, completed, rejected, failed.

The runtime validates the transition. Not the model’s confidence.

It sees five named tools: get_case, get_supplier, search_contract, create_change_draft, submit_for_approval. It reads evidence and creates a reversible draft. It can’t release your payment.

The gap between a tool list and a broad instruction is the gap between a route and a wish.

Your loop needs a budget too. Two retrieval attempts for a missing contract, then escalation. That number isn’t a universal tolerance, it’s a local decision.

What it does is show you what “try again” hides. A cost. A widening search. A growing data exposure.

And the point where persistence quietly becomes a decision that belongs to somebody else.

Earning the number

Your new interface will happily count executions. So your measurement has to follow the case instead. Entry, normal route, exception queue, business outcome.

Before the pilot changes how anyone behaves, take a baseline. Case population, inclusion rules, source systems, volume, outcome, external conditions.

Then freeze it, because you won’t be able to reconstruct it afterwards.

Three time measures, because a fast step is very good at impersonating a fast process.

End-to-end elapsed time, entry to terminal outcome. Touch time, the active work. Queue time, the wait in between.

Elapsed equals touch plus queue plus defined pause.

Your median, your ninetieth percentile and your breach share will tell you what an average won’t. Which is that the strange cases are still sitting in the wrong inbox.

Route evidence isn’t a scorecard for punishing variation, and it becomes one fast.

Your variation might be permitted. It might be a documented exception, a data error, a stale procedure, a policy breach, or something nobody has classified yet.

Classify before you judge.

Exceptions want five attributes: trigger family, severity, owner, age, final disposition. Then watch what moves them.

A required-document check raises your exception rate and lowers later rework. A duplicate-payment retry lowers the visible rate and raises your risk.

So put reopened cases, reversals, complaints and control breaches back beside the outcome the exception was designed to protect.

Otherwise you’re measuring the alarm, not the fire.

And your minutes saved are capacity, not money. The real effect is eligible cases times net minutes saved, after review, exception, monitoring and maintenance time.

A benefit you can bank needs a bridge to something real. Less overtime. A temp you didn’t hire. A smaller supplier invoice. A vacancy removed. Less error loss. More work finished inside a service target.

An hour can’t honestly be both an avoided hire and extra output. Somebody has to choose.

That’s the correction. You’re not looking at an intelligent process. You’re looking at a process whose hidden decisions have acquired a narrator.

The narrator may be genuinely useful. It may free an ordinary case from the little rituals that ate your afternoon.

But it inherits every missing document, every conflicting record, every weak approval, every unclear owner and every unmeasured cost your old workflow kept out of sight.

Until the route and its exceptions are written down, the agent doesn’t fix your process.

It explains the mess back to you, beautifully.