The parts of an AI workflow I deliberately keep boring

The part of an AI workflow I care most about is often the least impressive part to watch.

It is a total that reconciles. A missing field that stays empty. A document that stops at a review step because two values disagree.

Those moments do not make a particularly exciting demo. But when the output is something another person has to use, send, or approve, they matter more to me than a fluent explanation of what the system thinks it did.

In my independent payment requisition build for a national construction company, the division is explicit: AI reads the incoming material, Python handles the calculations, and the operator reviews the assembled package. That project sits outside my employment at Terakeet, as do the other independent projects in the Work section. The approach here reflects that independent building work and my own views.

The interesting design question is where each responsibility starts and ends.

Start with the output someone has to trust

A payment package has to agree with its source records. An estimating import has to put the right value in the right field. A delivery board has to preserve the columns the dispatcher maintains by hand.

Those requirements help me divide a workflow before I decide which model to use.

I ask what the operator will need to check at the end. Then I work backward: which source supplies each value, which rules transform it, and what should happen if something is missing?

My estimating automation case study is another example. Reading the specification is only part of the job. The output also has to fit the receiving system's file format. A plausible-looking file is not enough; the receiving system has to interpret it correctly.

Let AI interpret, then check what it found

Documents rarely arrive in a uniform shape. A label changes. A table spans two pages. A note explains an exception that a simple field lookup would miss. That is where I find AI useful: making sense of the material and proposing a structured reading of it.

I want that reading to include its evidence. For an extracted amount, that might mean the original text, the file name, and the page where it appeared. If the value cannot be found, the result should say so.

There is a subtle trap here: a tidy output can look more trustworthy than the messy document it came from. But putting information into neat fields does not establish that the information is correct. OpenAI makes this distinction in its Structured Outputs explanation: a response can follow the required structure and still contain mistakes in its values.

This is also why I treat context engineering as part of the build. Field definitions, approved rules, and examples give the model something specific to work against. They still need to be followed by checks.

A mismatch should survive the workflow

Consider a fictional invoice with two line items: $1,200 for materials and $800 for labor. The document prints a total of $2,100. Assume there is no tax, discount, or additional charge in this example.

The sum is $2,000. The difference is $100.

The workflow should retain the printed total and the calculated total, flag the difference, and stop that item for review. It should not rewrite the invoice to make it balance. It should not invent a miscellaneous charge to explain the gap.

The calculation is simple. The policy around the disagreement is the design decision.

If the actual document has an unclear tax line or a missing second page, the system needs to surface that uncertainty. It cannot assume the simplified conditions of this example apply to every invoice.

A check can prove that two values disagree. It cannot, by itself, prove which value is right.

Ordinary code makes the rules inspectable

For repeated operations with agreed rules, I want a calculation I can inspect and rerun. Totals, required fields, duplicate identifiers, and output formatting are good candidates.

This does not make code automatically correct. A perfectly repeatable formula can use the wrong input or encode the wrong business rule. The work includes checking the formula, testing its boundaries, and confirming the rule with the person who owns the process.

My preference is to keep the rule visible. If two document identifiers match, show the match. If a required value is absent, name the missing field. If an amount changes during a transformation, preserve enough detail to explain how.

Anthropic's Building Effective Agents distinguishes workflows with predefined paths from agents that choose their own steps. For this kind of repeatable document process, a defined path gives me a useful starting point: I can specify what must happen before an output moves forward.

Make human review a useful step

A button that says “Approve” is not much help if the person clicking it has to repeat the entire task to understand the result.

For the fictional invoice, a useful review item would say:

The printed total is $2,100. The line items sum to $2,000. Please confirm whether a charge is missing or the source total needs correction. Both values have been retained. This item is on hold.

That gives the reviewer a specific question. It also makes clear that the system has not resolved it.

The same principle appears in my Business Central delivery-board build: the workflow prepares information for the operator while preserving the fields that need human judgment. Defining what automation leaves alone is part of defining what it does.

Test the awkward inputs first

A clean example tells you whether the happy path works. I also want examples that force a decision: a missing amount, a conflicting total, or the same document arriving twice.

I made a small fictional input pack you can open in Excel, with an expected-results guide. It contains four scenarios:

• Matching total: preserve the source values and pass the arithmetic check. Passing this check does not authorize payment.
• Conflicting total: preserve both values and hold the item for review.
• Missing amount: leave it missing. Do not substitute zero or backfill it from the total.
• Repeated document: flag the matching identifier and avoid adding it to the batch twice until reviewed.

These are illustrative fixtures, not a full validation set or a record of client results. Their purpose is to make the expected behavior explicit before you try a workflow on varied real documents.

If you are outlining your own process, this is a useful starting brief:

The brief helps expose gaps. It does not replace implementing and testing the checks. The scoping brief resource is a place to document the larger process around them.

Decide what failure should look like

Before calling a workflow finished, I want answers to a few ordinary questions. Can the operator trace an output back to its source? Will a missing value remain visible? Can someone rerun the task without creating duplicate work? Does a failed check actually prevent the next step?

That last question is easy to overlook. A warning in a log is different from a workflow that holds the output until someone resolves the problem.

The payoff I am aiming for is a finished package with clear exceptions, a repeatable path through the routine work, and a person who can understand the result. The boring parts are what make that possible.

For the full project behind this approach, read Payment requisition automation for a national construction company.