Design time is AI. Runtime is not.

Every document automation product now says it uses AI. That tells you very little. The useful question is not whether AI is involved, but where it sits in the life of a workflow, and what it is allowed to decide. We draw one clear line: AI helps you build the workflow and understand what it did. Rules you approved run it.

Two moments, two sets of requirements

A workflow has two very different moments. The first is design: someone works out how a process should be handled. Which documents belong together, which fields matter, which rules apply, what goes to the ERP and what goes to a person. The second is runtime: the thousandth order on a Tuesday morning, processed while nobody is watching.

Design rewards speed, imagination and a tolerance for drafts. Runtime rewards the opposite: the same input gives the same output, every outcome can be explained, and nothing changes unless someone decided it should. Trying to serve both with one free-running model is where most of the trouble starts.

What AI is good at while you design

Building a document workflow used to mean a specification, a developer and weeks of back and forth. Most of that work is translation: turning what a process expert knows into steps, mappings and rules. That is exactly what a language model does well. In StencilFlow, you give the StencilFlow agent what you would give a new colleague:

• A description of the process in plain language.
• The Excel sheet with today's rules and reference data.
• A handful of real emails and documents, with the outcome you expect for each.

From that, the agent drafts the workflow as a graph, proposes the mappings, runs the draft against your examples, shows where the result differs from what you expected and fixes it with you. Later it helps with changes in the same way.

Mistakes at this stage are cheap. A wrong mapping in a draft shows up as a difference in a test, not as a wrong booking in your ERP. A person looks at every draft before it goes anywhere.

And when a case goes wrong: investigation

The second place AI earns its keep is after the fact. When a case ends in an error or lands in review, someone has to work out why. Traditionally that means digging through logs, or a ticket to whoever built the workflow. The StencilFlow agent reads the run history of the case instead: which documents came in, what was read from them, which rule failed and on which value.

• Explain behaviour: ask why a case went to review, and get the answer in plain language, traced to the step and the rule.
• Find the cause: a changed supplier layout, a missing code in a reference table, a rule that is too strict.
• Propose a fix: as a new draft version, tested against earlier cases, for a person to approve.
• Onboard new team members: someone new can ask what a workflow does, why it is built that way and why a given case ended the way it did, without waiting for the colleague who built it.

Investigation reads and explains. It does not change outcomes or reprocess cases on its own.

Why it should not decide at runtime

Now imagine the same model deciding, case by case, whether an invoice is approved or a shipment is released. A few things go wrong at once.

• The policy becomes invisible. A prompt that decides is a rule nobody can read, test line by line or sign off.
• Behaviour drifts. When the model or its provider changes, outcomes can change without anyone changing the process.
• Explanations get thin. "The model thought so" is not an answer an auditor, a customs officer or a supplier accepts.
• Mostly right is wrong. In finance, customs and order entry, a decision that is correct nine times out of ten still needs a person on every case.
• Every case pays the cost and the wait of a model call, even the thousands that are completely routine.

The one place AI does run: reading

There is one runtime task where AI earns its place: reading. Scanned documents, unfamiliar layouts and messy emails are hard to handle with templates alone. So StencilFlow uses AI reading where templates do not fit, but inside firm boundaries.

• It is directed by a schema: it fills in the fields and line items the workflow asks for, nothing else.
• Its output is data, not a decision. The same rules check it as any other value.
• Anything that fails a check goes to a person, with the source page beside the extracted value.
• Its quality is measured against answers your team verified, not assumed.

Known layouts still use deterministic templates that give the same answer every time. AI reading is the tool for the documents that do not fit them.

What this looks like in practice

What runs in production is a fixed graph of named steps, readable rules and tables your team maintains. Every outcome records the rule that produced it: straight through, review or exception, never a grey area. Every change is a new version that is tested, replayed against earlier emails and compared before it goes live. And only a signed-in person can activate a workflow. The agent can draft and test; it cannot put anything live.

AI makes building fast. Rules make running boring. For a process that writes into your ERP, boring is the goal.