The agent stays. The rules decide.

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. The agent stays with a workflow for its whole life: it builds it, helps your team while it runs and helps improve it. The cases themselves are decided by rules you approved.

Build, run, improve

A workflow has three phases. First it is built: 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. Then it runs: the thousandth order on a Tuesday morning, processed while nobody is watching. And then it is improved, because suppliers change layouts, rules change and some cases keep landing in review.

Building and improving reward speed, imagination and a tolerance for drafts. Deciding a case 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. So the agent works around the run, and rules work inside it.

Build: what the agent is good at

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.

StencilFlow comes with ready-made, tested components for every part of a document workflow: intake from mailboxes, document reading, combining documents into cases, rules and lookup tables, the review workspace and actions into your systems. The agent chooses those components, connects them and configures them. The result is a workflow your team can read and check, not one large program only a developer can follow.

Mistakes at this stage are cheap. And because the building blocks themselves are already tested, a mistake in a draft sits in one step's settings or expression, where you can see it. 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.

Run: troubleshooting and questions

Once a workflow is live, the agent stays with your team. 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.

Your team can also ask about operations: which supplier causes the most reviews, how many orders came in this week, which rule fails most often. The agent answers from your own cases and run history.

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

Improve: learning from what actually happened

A workflow that is live for a few months has a lot to teach. Ask the agent to review recent runs and it looks for patterns: cases that keep landing in review for the same reason, values reviewers correct again and again, a supplier whose layout changed, a rule that is stricter than it needs to be.

• Every suggestion comes with the evidence: which cases, how often, and what would change.
• Every change is a new draft version, replayed against earlier cases and compared before anyone looks at it.
• Your process experts decide. Nothing changes until a person activates the new version.

That is how the workflow and the team get better over time, without anyone handing control to a model.

Why the agent should not decide the cases

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 task inside the run 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, test and propose; it cannot put anything live.

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