How AI Workflow Automation Actually Works

Descriptions of AI automation tend to stay at the level of capability - it can read documents, it can answer questions, it can route requests. That is true and it does not tell you how one is actually built.

Here is the structure of a real automation, stage by stage, using invoice processing as the example because it is common, boring and genuinely useful.

The five stages

Every automation we build follows the same shape:

Trigger → Process → Decide → Act → Log

The AI part, when there is one, lives in Process. Everything else is deterministic, and that is deliberate.

Stage 1: Trigger

Something happens that starts the run.

Common triggers: an email arrives at a monitored address, a file lands in a folder, a form is submitted, a record changes in a database, a webhook fires, or a schedule comes round.

In our invoice example: an email arrives at invoices@ with a PDF attached.

Design decisions that matter here:

• Scope it tightly. Monitor a dedicated address, not a general inbox. Ambiguity at the trigger produces noise through the entire pipeline.
• Handle duplicates. The same email can be delivered twice. Keep a record of what has been processed so you do not create the same invoice twice.
• Decide what happens to non-matching input. Someone will eventually email that address asking a question. The automation should route it to a human, not attempt to process it as an invoice.

Stage 2: Process

Take the raw input and turn it into structured data. This is where a model earns its place, because invoices from different suppliers look completely different and rules cannot keep up.

The model is given the document and asked to return a defined structure: supplier name, invoice number, date, due date, currency, line items, subtotal, tax, total.

Two things make this reliable:

Constrain the output format. Ask for a specific schema rather than free text. If the response does not parse, that is a failure you can detect immediately rather than a mess downstream.

Ask for confidence or absence explicitly. A model told to return a value will return one, even when the field is not present. Instructing it to return null when a field is genuinely missing is far more useful than receiving a plausible invented number.

The output at this stage is structured data of unknown correctness. Which is what the next stage is for.

Stage 3: Decide

Validate what came back, then decide what happens to it. This stage is entirely rules, and it is the reason the automation is trustworthy.

For our invoice:

• Do the line items sum to the subtotal?
• Does subtotal plus tax equal the total?
• Is the supplier one we recognise?
• Is the invoice number one we have already processed?
• Is the date within a plausible range?
• Is the total within the normal range for this supplier?

Then the routing decision:

• All checks pass, total under the auto-approval threshold → proceed automatically.
• All checks pass, total above threshold → queue for human approval.
• Any check fails → route to a person with the specific failure flagged.
• Unrecognised supplier → route to a person to set up.

This stage is where most of the value lives. It is also the part that gets skipped when people build automations quickly, and skipping it is why those automations quietly produce wrong data.

Stage 4: Act

Do the thing. Create the record in the accounting system, file the PDF, notify the approver, update the ledger.

Practical requirements:

Handle failure properly. The accounting API will be unavailable sometimes. Retry with a sensible backoff, and if it still fails, stop and alert rather than dropping the item.

Make actions idempotent where possible. If a retry runs the same action twice, it should not create two records.

Order matters. If creating the record succeeds but filing the document fails, decide in advance whether that is acceptable or whether the whole run should be rolled back.

Stage 5: Log

Record what happened: the input, what the model returned, which checks passed and failed, what action was taken, how long it took and what it cost.

This is not optional overhead. It is what makes the automation maintainable.

When someone asks why a particular invoice was miscategorised three weeks ago, the log is the difference between a five-minute answer and a shrug. It is also how you measure whether the automation is actually saving what it was supposed to save, and how you spot accuracy drifting before it becomes a problem.

Where the human sits

In this example, a person approves anything above the threshold and handles anything that failed validation. They do not review every invoice - that would defeat the purpose - but nothing hard to reverse happens without them.

The general rule: a human approves anything customer-facing, financially significant, or difficult to undo. The automation removes the mechanical work; the person keeps the judgement.

Over time, as you accumulate evidence about accuracy from the logs, thresholds can move. That decision should be based on measured performance, not optimism.

What this looks like in effort

The extraction step - the AI part everyone focuses on - is usually the quickest to build. Modern models handle it well.

The work is in everything else: connecting to the email system, handling the varied ways attachments arrive, writing meaningful validation, integrating with the accounting system’s API and its quirks, building the review interface for the human step, and handling the edge cases that surface once real documents start flowing.

That ratio holds across most automation projects. The model is a component; the automation is the system around it.

The same shape, different jobs

Swap the specifics and the structure is unchanged:

• Support triage: email arrives → classify and summarise → route by type and urgency → assign and draft a reply → log
• Lead qualification: form submitted → extract and enrich → score against criteria → route to the right salesperson → log
• Reporting: schedule fires → pull and summarise data → check for anomalies → send report → log

Once you recognise the pattern, most automation requirements become a matter of filling in the five stages.

---

We build automations this way - narrow, validated, logged, with a human where it matters. Describe a process you would like to stop doing manually, or read more about AI automation.