Workflow Automation That Survives Contact With Reality

Most automation projects fail in the same way. Someone maps an ideal process, builds it, and discovers that the real process has exceptions the map omitted. The automation handles the happy path, the team keeps handling everything else manually, and within a few months the tool is overhead rather than leverage.

Automate the path you measured, not the one you drew

Before building anything, watch the work. Count how often each branch actually occurs. Teams consistently describe their process as more uniform than it is — and the exceptions are not noise, they are usually where the time goes.

If 30% of cases are "special", automating the other 70% saves less than it appears, because someone still has to triage which bucket each case falls into.

Design for the exception from the start

The question is not whether exceptions occur but what happens when they do. Three options, in increasing order of usefulness:

1. Fail and alert. Acceptable only if someone is reliably watching.
2. Route to a human queue. The item waits somewhere visible with its context attached.
3. Partially complete and hand over. The automation does what it can, then presents a human with a mostly-finished item to approve or correct.

The third is almost always the best. It captures value on hard cases rather than abandoning them.

Where language models help, and where they do not

They are good at the parts that previously resisted automation because they needed judgement about unstructured input: classifying a request, extracting fields from a document, summarising a thread, drafting a reply.

They are not a substitute for the deterministic parts. Moving data between systems, applying business rules, enforcing permissions — these should remain ordinary code. Putting a model in that path adds latency, cost and non-determinism in exchange for nothing.

The pattern that works: deterministic pipeline, model calls at the specific points that need interpretation, validation after each one.

Confidence scores and when to trust them

If a step can report how sure it is, route by that. High confidence proceeds automatically; low confidence goes to a human. This converts an accuracy problem into a throughput problem, which is far easier to manage — and the review queue becomes your training data for improving the model.

Be careful: a model's stated confidence is not calibrated by default. Validate it against outcomes before routing on it.

Measure the right thing

Not "cases automated". That number rewards automating easy cases and ignoring hard ones. Measure total human time spent on the process, end to end, including triage, correction and the time spent dealing with automation failures.

Automation that halves the easy cases and doubles the hard ones is a loss, and only the end-to-end number shows it.

Keep the manual path working

Every automated process needs a route for a human to do it by hand. Systems break, providers have outages, and some case will eventually fall outside everything you anticipated. An automation that leaves no manual path turns a degraded day into a stopped one.