Where this chapter sits
The series argues that the way to adopt AI without losing control is software that can be told what to do, held to what it may do, and made to account for what it did. Chapter 1 described the gap between an AI policy and the way AI is used. Chapter 2 asked who may act. This chapter asks the question finance and technology bring to the table together: why the AI bill grows with the business, and why the same design that stops that growth is also the one that lets you prove what happened.
The problem, as you would put it
The pilot went well. Someone connected a language model to a queue of invoices, claims or intake forms, and the model read each one, pulled out the fields and passed them on. It was faster than doing it by hand, and the demonstration was convincing.
Then the invoice for the model arrived, and it had the same shape as the work. More volume meant a bigger bill, and a busy quarter meant a bigger one still. The CFO now has a cost line that grows with the business itself, priced by a vendor who can change the rate.
The CTO has a different worry, and it is the more serious one. An auditor, a customer or a regulator asks why a particular record was handled the way it was. The honest answer is that the model read it that way on that day. Run the same record again and the answer may differ. There is no version to point to, no rule to show, and no way to prove which answer was the one that went out.
So the two of you are looking at one decision from two sides. One side asks what it costs. The other asks whether it can be defended. Both questions have the same cause.
Why the usual fixes do not close the gap
The first fix most firms reach for is a cheaper model. That lowers the rate, but the cost still rises with every record, and a smaller model reads less reliably, so more records need a person to check them. The line on the budget is still a rising line; it is just a shallower one.
The second fix is to negotiate volume pricing or a fixed-fee plan. That moves the risk around without removing it. The vendor prices in your growth, and the reproducibility problem is untouched.
The third fix is to add review. A person checks a sample of what the model produced. That catches some errors, but it brings back the labor the automation was meant to remove, and a sample is not a record. When someone asks about one specific case, a sampling policy does not answer the question.
The fourth fix is to write better prompts. A prompt is still an instruction to something that interprets. It narrows the range of answers; it does not make the same input produce the same output every time.
All four accept the starting assumption that the model must run on every record, forever. That assumption is the cause of both problems.
The idea: use the model to design the work, then let the work run without it
Most of what a model does in a per-record pipeline is not judgment. It is translation. A supplier calls a field one thing, the accounting system calls it another, and the model is paid every time to notice that they mean the same thing. The meaning did not change between yesterday’s invoice and today’s. Only the data did.
Our thesis makes the point directly: “A recurring transformation should be able to run through a validated artifact.” (C2Consultants, Intelligent Software and Autonomous Organizations.) In plain terms, if the same translation happens every day, work it out once, check it, keep it as a definition people can read, and run that definition from then on.
That changes when the model is called. It is called once to draft the process. It is called once to write a script, or to map a new source’s layout onto the layout the firm already uses. It is called again only when the source changes shape, such as when a supplier redesigns its invoice or a portal adds a field. It is not called because the data changed. Everything between those moments is a deterministic step: the same input produces the same output, every run. The engineer’s version is short. The model writes the pipeline. The pipeline runs without it.
None of this means the model disappears. Some work genuinely calls for interpretation every time: reading a free-text complaint, sorting an unusual request, judging a case that fits no rule. The thesis is careful about this too: “When a case genuinely requires interpretation, a bounded model call can address that uncertainty.” (C2Consultants, Intelligent Software and Autonomous Organizations.) The point is to pay for judgment where judgment is the job, and to stop paying for translation that was already solved.
For the CFO, the result is a different cost curve. Model spend follows the number of distinct sources and the number of times they change, not the number of records. A busy quarter is a busy quarter for the deterministic steps, which cost the same per run as a quiet one.
For the CTO, the result matters more. Because the steps are deterministic, the answer to “why was this record handled this way” is no longer “the model decided”. It is this process, this published version, this run, these inputs, this output, and this named person who approved it. That is an answer an auditor can check. The cost saving is the commercial argument; the ability to prove what happened is the one that gets a reviewer to say yes.
We do not publish a ratio for the saving. It depends on how much of a process is translation and how often its sources change, and a number we have not measured for your work would be a number you could not rely on. The mechanism is what we stand behind.
What it looks like in a firm like yours
Take a mid-sized firm that receives supplier invoices in many different layouts and keys them into its accounting system. Part of the finance team spends some of every day on it.
In the per-call design, every invoice goes to a model, which reads it and returns fields. The cost rises with every invoice, and nobody can say for certain how a particular invoice was read last March.
In the designed version, the model is used up front. It reads examples from each supplier and proposes a mapping from that supplier’s layout to the firm’s own fields. A person reviews each mapping, the way they would review a new procedure, and approves it. From then on, each invoice runs through the approved mapping without a model call, and totals are calculated by exact arithmetic, not estimated.
When a supplier changes its invoice, the step that expects the old layout fails, so the run stops and reports instead of guessing. The model proposes an updated mapping, a person approves it, and it becomes the next version. The old version is kept, so last March’s invoices can still be explained by the rules in force last March. Any invoice that fits no known layout goes in front of a person, and anything consequential, such as releasing a payment, waits at an approval step with the named approver recorded.
The same pattern applies to filing work. In one case we measured, a government portal filing took 112 seconds automated (Measured: the median of the last 18 runs), against 10 to 20 minutes by hand (the customer’s estimate), at about 100 filings a week. The filing runs as a published workflow whose steps are the same every time; the time saved comes from the work being designed, not from a model reading every form.
What to do first, before you buy anything
1. Find where the model is called. For each process that uses a language model today, write down whether the model runs once per record or once per design. Most firms find the answer is once per record, everywhere.
2. Separate judgment from translation. For each of those processes, ask whether the model is deciding something that genuinely varies case by case, or recognizing the same fields in the same layouts again. Mark each step one or the other. The translation steps are the ones that can stop costing money on every run.
3. Run the reproducibility test. Pick one record handled last quarter and ask the owner of the process to show exactly why it was handled that way, and to produce the same result again today. If they cannot, that is the risk your auditors will find, and it is worth knowing before they do.
How C2Consultants does this
C2Empowered, the operations platform we build, applies this approach. In Workflow Studio the co-author uses a model to draft a workflow from a plain description and to map a new source onto the layout you already use; once a person approves and publishes it, Fleet Agents run that published version step by step without calling a model for the translation, and the model is called again when a source changes shape. Administrators choose local or hosted models for every use. Each run keeps a trace tied to the version that governed it, and each consequential step waits at an approval gate set by risk level for a named approver, so the record of what happened is produced by doing the work. One honest limit: this pays off where the work repeats; a step that genuinely needs judgment on every item still calls a model every time, and its cost still rises with volume. The way to find out how much of your work is translation is a pilot on one of your own processes: discovery ($2,000), installation ($1,750), and building and testing your first workflows ($175 per hour), run side by side with how you work today before you decide anything more.
Next chapter: The cost of repeated translation. Where the time in a process actually goes.