The model proposes, the code decides

Take an ordinary accounts-payable process. An invoice arrives as a PDF in a shared mailbox. Somebody reads it, finds the purchase order, checks the quantities against the goods receipt, codes it, checks who may approve that amount, posts it and schedules the payment.

There are two familiar ways to automate this badly. The first writes rules for everything, including the reading, and spends the following year maintaining templates for every supplier’s layout. The second hands the whole thing to a model — read the invoice and book it — which works in the demonstration and fails the first audit, because nobody can say why a particular invoice was posted the way it was.

The version that works splits the process by the kind of work in each step, not by the system the step happens to touch.

Split by the kind of work

Reading. Turning something written for people into fields: an invoice, an email, a delivery note, a claim form. This is what models are good at, and where rules are most brittle.

Classifying and drafting. Which kind of request this is, which team it belongs to, what the reply or the coding suggestion should be. Also model work, as long as nothing leaves the building on the model’s word alone.

Deciding under ambiguity. Whether a complaint is really a cancellation, whether an invoice line described one way matches a purchase-order line described another. The model proposes an answer and shows what it is based on.

Checking against facts. Does the supplier exist, do the lines add up to the total, is the quantity within tolerance of what was received, has this invoice number been booked before. This is code, always. A model can be asked whether the sum is right; a function knows.

Changing state and applying policy. Posting, paying, updating a master record, enforcing an approval limit or segregation of duties. Code and configuration, inside a transaction, readable by the people responsible for compliance.

Infographic

Who does which step

Costly mistakeCheap mistake

Code and rulesCheckable facts, money and state. Nothing to interpret.

Model proposesCode verifies the proposal; doubtful cases go to a person.

Plain automationAn integration and a rule. A model adds nothing here.

Model acts aloneReversible and cheap to correct, such as first-pass routing.

Fields and recordsText and documents

The seam is a proposal, not an action

The pattern that holds this together is easy to state: the model never performs the state change itself. Its output is a proposal — a structured object with the extracted fields, the chosen purchase-order line, the suggested account, and a pointer to the part of the document each value came from.

That proposal goes to a verification layer written in ordinary code, which checks it against the systems of record: required fields present, every identifier resolving to a real record, totals and tax consistent, tolerances respected, nothing booked twice, the purchase order still open. Only a proposal that passes is committed, and it is committed by code.

Code cannot tell whether the model read the document correctly. It can tell whether the reading is consistent with everything else the company already knows, and many wrong readings fail exactly there. The ones that pass every check and are still wrong are the residual risk, which you measure by sampling rather than by hope.

What must not live in the prompt

An approval limit written into a prompt is a request. It holds for as long as the model reads it as intended. The same limit in code simply holds, and it can be reviewed, versioned and changed under the same control as any other financial setting.

The same applies to anything an auditor or a regulator will ask about. A compliance team can review a rule table. It cannot review the behaviour of a model across inputs nobody has seen yet, and it should not be asked to.

There is a plainer version of this rule as well: do not ask the model to do anything you can compute or look up. Arithmetic, date logic, master-data lookups and duplicate detection are cheaper, faster and exactly right in code.

Where people come in

Proposals that fail verification, and those the model itself marked as uncertain, go to a person — together with the proposal, the check that failed and the evidence, so that the person makes one decision instead of redoing the case.

Which checks fail, and how often, then becomes the most useful map of the process you will ever have. A check that fails constantly points at weak reading, a missing reference record or a rule that is simply wrong, and each of those has a different owner.

Start by labelling the steps

Draw one process as steps and label each one: reading, classifying, deciding, checking, changing state. The labels do most of the design on their own, and they make it obvious where the model earns its place and where it would only add risk.

That boundary — what the model may propose, what code enforces and what always goes to a person — is the first thing we define in an AI agents engineering engagement, and it ends up written in code rather than in a prompt.