AI Process Automation
Automating a process is mostly an authority question. Which steps can a system take by itself, and who is accountable when it takes one badly?
- Typical duration
- Four to ten months
- Team shape
- Two to five senior engineers
- Starts with
- Mapping the real process
Map the process before deciding what a model should do in it
Most processes described as candidates for automation turn out to be several processes: a documented one, the one people actually follow, and the exceptions that consume most of the effort. Automating the documented version produces a system that handles the easy cases and hands everything else to a person with no context.
So we map what actually happens first, including the exceptions and the informal steps, and only then decide where a model belongs. Some steps it can take alone. Some it should draft and a person approves. Some should stay entirely human, and saying so is part of the job. That boundary is written down per step, and it is the thing an auditor will ask about.
What usually goes wrong, and what we do instead
Automation projects fail on exceptions and on authority, rarely on the automation itself.
Where process automation fails
- The documented process automated, rather than the one people follow
- Exceptions handed to a person with none of the context that produced them
- A model given authority to act where it should only have drafted
- No record of why the system did what it did, discovered at audit
- A brittle chain where one step failing strands work in an unknown state
How we build it instead
- The real process mapped by observation, exceptions included
- Exceptions routed with the full context of what led to them
- An authority boundary written down per step, and agreed with you
- Every decision recorded with its inputs and its reasoning
- Durable workflows, so a failed step is resumable rather than lost
What that involves
The work that decides whether automation removes effort or relocates it.
The authority boundary
Written down per step, before anything is automated.
Which steps the system may take alone, which it drafts for approval, and which stay entirely human. This is the document an auditor asks for, and deciding it is most of the engagement.
Process mapping
What actually happens, observed rather than described, including the exceptions that consume the effort.
Model-driven steps
Classification, extraction and drafting where a model genuinely outperforms a rule.
Durable orchestration
Workflows that survive a failure mid-process and resume rather than stranding work.
Exception routing
Handed to a person with the full context, not as a rejection with a reference number.
System integration
Reading and writing the systems the process already uses, on agreed record ownership.
Decision records
Every automated action logged with its inputs and its reasoning, queryable afterwards.
What you end up with
Stated from your side rather than ours.
A boundary you can defend
What the system decides and what a person signs is written down per step, which is what a regulator or an auditor will ask about.
Exceptions that are workable
A person picking up an exception gets the whole context, so handling one takes minutes rather than an investigation.
Work that does not get stranded
Durable workflows mean a failure mid-process resumes rather than leaving an item in a state nobody can find.
An answer to 'why did it do that?'
Every automated action is recorded with its inputs and reasoning, so the question is a query rather than an investigation.
How the pieces fit together
The model is one step among several, and the orchestration around it is what makes the process reliable.
What each part does
- Trigger: what starts a case — a document, an event, a schedule — recorded with everything known at that moment.
- Durable workflow: the process as code, checkpointed at each step, so a failure resumes instead of stranding the case.
- Model steps: classification, extraction or drafting, each producing a confidence score alongside its output.
- The authority gate: the written boundary, deciding per step whether the system acts, drafts for approval, or defers.
- Approval and exception queues: work handed to a person with the full case context, not as a bare rejection.
- Decision record: inputs, outputs and reasoning for every automated action, queryable long after the case closes.
How the work runs
The same five stages as every engagement, applied to a process people already run.
Diagnose
The process as it actually happens, the exception rate, and where the effort genuinely goes.
Decide
The authority boundary per step, agreed in writing with the people accountable for the process.
Prove
One step automated in production, running beside the current process before it replaces anything.
Deliver
Steps automated in slices, each measured against the manual process before the next is scoped.
Hand over
Your team adjusts the boundary and the workflows with us watching, then without us.
What we build it with
Chosen for what has to be explained afterwards, and for who has to run it once we have gone.
Models
- Anthropic
- OpenAI
- Gemini
- LangChain
Orchestration
- Temporal
- Kafka
- Python
- TypeScript
Data
- PostgreSQL
- pgvector
- Redis
- Elasticsearch
Platform
- AWS
- Azure
- Kubernetes
- Datadog
What you get, and when
Handed over as it is produced, not assembled at the end.
- The process as it actually runs, exceptions included
- Where the effort genuinely goes, measured rather than assumed
- The authority boundary per step, agreed in writing
- Source in repositories you own
- Durable workflows that resume rather than strand work
- Approval and exception queues designed as workflows
- Decision records for every automated action
- Throughput and exception-rate dashboards per step
- A record of every boundary change and who approved it
The rest of our AI work
Most AI engagements need one of these underneath them, and some need two.
Related work
Engagements where deciding who was accountable came before deciding what to automate.
Questions about process automation
The ones we are asked most often before a first conversation.
How much of the process can be automated?
Is this about reducing headcount?
How is this different from RPA?
Should the system be able to act on its own?
Can we explain what the system did to an auditor?
Do we have to replace the systems we run today?
Process that eats more time than it should?
Tell us what the process is and where the effort goes. We will tell you which steps a model can honestly take.