Automating the documented process is how these fail quietly.
Discovery, build and deployment for one workflow that already works — just slowly, or expensively, or only when one particular person is at their desk.
We start by watching the work happen.
There is the process on the wallchart, and there is the process people run. They are rarely the same one. The differences are not sloppiness — they are the accumulated handling of everything the documented version does not cover, and they are usually the reason the work comes out correct.
Automate the documented version and you get a system that is right most of the time and wrong in exactly the cases someone was quietly catching. Nobody notices for a quarter, because the failure looks like normal output.
So discovery is sitting with the people doing it, not reading the procedure. It is the part clients most often want to skip and the part that most reliably decides whether this works.
How we scope it.
One workflow, named up front
Not a function, not a department. One sequence with a beginning, an end, and someone who can say whether the output was right. If that person cannot be named, there is nothing to check the system against, and we would be building on an opinion.
The judgement calls, written down
Every workflow has decision points where an experienced person chooses. We write those down explicitly, with the edge cases, before anything is built — partly because a model needs them, and partly because the exercise regularly reveals that two people have been deciding the same thing differently for years.
What happens when it is unsure
Decided during scoping, not after launch. Which cases route to a human, what the reviewer sees, and how a correction gets back into the system. A workflow automation with no defined escalation path does not degrade gracefully — it just produces confident output nobody checks.
Deployed where the work already is
Into the tools the team already opens. A system that requires people to remember a new tab is one that gets used for three weeks. Where that means working inside something we do not control, we say so during discovery rather than discovering it during the build.
Measured against how it ran before
We take a baseline during discovery — how long the workflow takes, how often it needs rework — because without one, the question of whether this was worth doing has no answer, and the conversation at renewal becomes a matter of impressions.
When to do something else.
If the process is genuinely broken rather than slow, automating it makes it produce wrong answers faster. That is a process problem and it should be fixed by the people who own it first.
If you want this capability in-house across many workflows rather than one system delivered, Infrastructure is the program that does that.
And if what the workflow needs is a rules engine, we will tell you. Deterministic problems have deterministic solutions that are cheaper to run and easier to audit, and a language model is a poor way to apply a lookup table.
Bring us the workflow.
Describe what it does, who runs it, and where it slows down. That is enough for us to say whether it is a fit, and roughly what discovery would need to look at.