From manual process to automated flow: an architecture playbook

Start from a process, not from a model

The question "where can we use AI?" produces demos. The question "which process costs us the most hours and why?" produces systems. We begin every engagement with one process, chosen for three properties: it is frequent, it is mostly rule-following with a few judgement calls, and its cost is visible to the business. Invoice intake, support triage, vendor onboarding, order exceptions and contract intake all qualify.

Step 1: map the process as it actually runs

Sit with the people who do the work and record the real flow, including the workarounds. For each step capture:

• Input: where it comes from (email, portal, ERP screen, spreadsheet) and in what format.
• Decision: what the person checks and what rule they apply, including the unwritten ones.
• Output: what changes in which system.
• Exceptions: what happens when something does not fit, and how often.
• Time and volume: minutes per item, items per week, and who does it.

The map usually shows that 70–90% of items follow a handful of paths and the remainder consume most of the time. That split is the design.

Step 2: draw the boundary between automation and judgement

Classify each decision in the map:

Decision type	Handled by	Example
Deterministic rule	Code, not a model	Invoice total equals PO total within tolerance
Extraction / classification	Model with structured output, verified by rules	Read vendor, total, date and PO reference from a PDF
Bounded judgement	Model with retrieval and a confidence threshold	Choose the best knowledge-base article for a ticket
Consequential judgement	Human, presented with the model's preparation	Approve a payment above a limit; reply to an angry enterprise customer

The rule is simple: models prepare, rules verify, humans decide where consequences are real. Automating the last column is where projects lose trust.

Step 3: design the target architecture before building

Write it down; a two-page document is enough. It should contain:

1. Trigger and intake: how items enter (mailbox polling, webhook, schedule) and how duplicates are handled.
2. Orchestration: the plan for a normal item and for each known exception path. We use a hub-and-spoke structure so every step is a typed tool call.
3. Tools: the systems touched and the exact operations, split into read, draft and commit (see MCP tool design).
4. Human checkpoints: which steps wait, for whom, in which tool, with what deadline and fallback.
5. Data and retrieval: what documents the system must consult, how they are indexed, how freshness is maintained.
6. Security: credentials per tool, what leaves your cloud account (ideally nothing), retention of logs and documents.
7. Cost model: model cost per item, infrastructure cost per month, human review minutes per item, compared against the current cost per item.
8. Evaluation: the test set, the accuracy bar, and who signs off.

Step 4: build the cost model honestly

An automation that costs more than the work it replaces is a science project. The numbers that matter per item:

current_cost   = minutes_per_item × loaded_hourly_rate / 60
automated_cost = model_cost_per_item
               + infra_cost_per_month / items_per_month
               + review_rate × review_minutes × loaded_hourly_rate / 60
savings        = (current_cost − automated_cost) × items_per_month

Model cost is usually the smallest term; review rate is the one to design around. A system that sends 30% of items to a human is still a large saving if those 30% took 90% of the time before.

Step 5: build spoke by spoke

Do not build the whole flow and then switch it on. Sequence it so that value lands early and risk stays contained:

1. Read-only assistant. The system extracts, matches and prepares; a person still does every commit. This alone often halves handling time and produces the evaluation data you need.
2. Auto-commit for the safe path. Items that pass every rule and fall under the risk threshold commit without review. Everything else goes to the queue as before.
3. Widen the safe path. Use the review log to find exception types worth automating; add a spoke for each.

Step 6: operate it like a system, not a script

• Dashboards for volume, straight-through rate, review queue age, cost per item and error types.
• Alerts on budget overrun, tool failures and review queue backlog.
• A weekly review of rejected items; each recurring rejection is a candidate rule or spoke.
• Re-run the evaluation set on every prompt, model or tool change.
• Documentation and training so the process owner, not the vendor, owns the system.

Worked example: supplier invoice intake

Before: two people spend most of each morning opening invoice PDFs from a shared mailbox, keying vendor, total and PO number into the ERP, checking the purchase order, and chasing mismatches by email. Roughly 12 minutes per invoice, 60 invoices a day.

After: a mailbox trigger hands each PDF to a documents spoke that extracts fields with structured output; a rules step checks the PO match and tolerance; matches under the approval limit post automatically; mismatches and high-value items land in a review queue with the extracted data and the reason attached. Human time drops to a few minutes per exception; the straight-through rate settles around 70% after the second month as recurring exceptions get their own rules.

The architecture is not exotic. The discipline is in the mapping, the boundaries and the cost model, which is why we spend the first phase there.

Frequently asked questions

Which processes are the best first candidates for AI automation?

Frequent, mostly rule-following processes with a few judgement calls and visible cost: invoice intake, support triage, vendor onboarding, order exceptions and contract intake. Avoid starting with rare or highly consequential decisions.

Do we need to replace our ERP or helpdesk?

No. The architecture wraps existing systems with typed tools; the process runs where the work already happens. Replacing systems of record is almost never a prerequisite.

How long until the first process is live?

A read-only assistant for one process is typically live within weeks of discovery; auto-commit for the safe path follows once the evaluation set confirms accuracy and the review data supports the threshold.