AI workflow automation

Context

A recurring operational workflow: requests and documents arriving continuously, each needing to be read, checked against reference material, have information extracted, be drafted into a standard output, formatted, and routed. Around a hundred of them a day, handled by a team of skilled people who were spending most of their week on handling rather than on judgement.

The business problem

Ten distinct manual steps, roughly four hours end to end per item, and the volume was not going down. The work was not difficult; it was repetitive, interruptible and easy to do slightly inconsistently. Every attempt to solve it with templates and checklists helped a little and then plateaued.

The obvious answer was AI, and the obvious objection was equally reasonable: nobody wanted an opaque system producing outputs the organisation would have to defend.

Constraints

• The output is something the organisation stands behind, so a fully autonomous pipeline was never acceptable.
• Running cost had to be predictable before commitment — token spend and API rate limits stated up front, not discovered in month two.
• The team doing the work had to be able to review outputs faster than producing them by hand, or the automation would simply move the bottleneck.
• Reference material was scattered and had to be curated before retrieval could be grounded in it.

Approach

The first step was measurement, before any building: the manual process was instrumented so the four-hour baseline and the ten steps were a recorded number rather than an estimate. Without that baseline, any later claim of improvement would have been a story.

The automation was then built around an explicit human gate. Retrieval, extraction, drafting and formatting run automatically; the person submits a structured request at the front and reviews a completed draft at the back. Those two remaining steps are guided — the reviewer sees the draft alongside the retrieved source material it was built from, which is what makes reviewing faster than re-doing.

Every decision at the gate is logged as accepted, edited or rejected. That log is the honest measure of how well the system works, and it is also the feedback signal: rejected outputs point at gaps in the curated material rather than at a need for a bigger model.

What I did

• Instrumented and measured the manual baseline before designing anything.
• Curated the reference material into a retrievable knowledge base.
• Built the automation — retrieval, extraction, drafting and formatting — with APIs, Python and orchestration.
• Designed the review interface so the draft and its supporting sources are visible together.
• Built the accept/edit/reject logging, and the usage and cost visibility on top of it.

Systems and technologies

Python for orchestration and extraction, commercial LLM APIs for drafting, a retrieval layer over the curated material, and the client's existing document and routing systems on either end.