AI inside the workflow, not beside it.

Vague terms produce vague projects. These are the five building blocks we design with, and what each one actually does.

Document intelligence

Three distinct operations that are often bundled under one name. OCR turns an image of a page into text. Extraction maps that text to named fields: supplier, date, amount, clause. Consistency checking compares the fields with each other and with reference data: the lines add up to the total, the supplier exists, the date falls in the open period. The model does the second; ordinary code should do the third.

Knowledge retrieval

Retrieval-augmented generation (RAG) searches a curated, access-controlled set of documents and gives the model only the passages it found, so the answer can cite them. Its quality depends on the corpus before the model: duplicates, outdated versions and documents without an owner produce confident wrong answers.

Case triage

Classifying incoming requests by type, urgency and required skill, then routing them. Usually rules plus a classifier; a language model helps when requests arrive as free text in several languages.

Workflow orchestration

The layer that sequences steps, calls systems, retries safely and records state. It should be ordinary, deterministic software. An agent, in the precise sense, is a model allowed to choose which tool to call next. We grant that freedom sparingly, inside bounded permissions, and only where the path genuinely cannot be specified in advance.

Assisted review

The screen where a person sees what the system proposes, the evidence behind it and how uncertain it is, then approves, corrects or rejects. Corrections are stored and become test cases. This is where most of the design effort should go, because it is where trust is built or lost.

Invoice intake is a good reference because almost every organization has it. The same structure applies to contracts, claims or onboarding files. This is an illustrative design; we do not claim it is deployed for a client.

Workflows · Reference process

Invoice intake, fully specified.

Scroll the diagram sideways to see all of it.

System of record Processing step or service Channel, provider or external party Grouped layer Instruction or data out Result or decision back Records to the log

Read the diagram as text

1. Intake: each document arriving by email, upload or portal receives an ID, a content hash and a timestamp.
2. Validation rules: file type and readability, duplicate detection by hash and by key fields, mandatory attachments present. Failures go to the exception queue.
3. Known layouts are read by template rules with no model involved. Unknown layouts go to AI extraction, which must return a fixed schema.
4. Consistency checks: totals reconcile, dates are plausible, the supplier exists in master data, field confidence is above threshold. Any failure becomes a flag with a reason.
5. Human approval: the reviewer sees the document beside the extracted fields, with doubts highlighted, and approves, corrects or rejects. Thresholds by amount decide what must be reviewed.
6. Export to the accounting or ERP system through its API or a validated import file, with an idempotency key so a retry never books twice.
7. The evidence log records the input hash, model and prompt versions, extracted values, checks run, reviewer decision and export ID.

Notice where the model is not. It does not decide whether a document is a duplicate, whether totals add up or whether an invoice can be paid. It reads layouts that rules cannot read, and its output is checked before anyone relies on it.

A pilot is judged on its happy path. Operations are judged on everything else. Each failure below has a defined detection and a defined response before the system goes live.

Saying where not to use a model is part of the job. In these cases ordinary software is cheaper, more reliable, or both.

• Arithmetic and totals. A model can read the numbers. Code should add them.
• Stable rules with legal or financial weight. VAT rates, approval limits, eligibility thresholds. Encode them; do not ask a model to remember them.
• Exact lookups. "What is the balance of this account" is a database query, not a retrieval problem.
• Low-volume tasks. If it happens twelve times a year, a checklist beats a pipeline.
• Outputs nobody can check. With no ground truth and no reviewer, there is no way to know the system works.
• Decisions with significant effects on a person, taken without meaningful human review. These need a different design and a legal assessment first.