We already run the systems the AI has to live in

Intelligent Forge Company is the engineering team behind several core systems in the production stack of Nimbus Payments, a US-based payment processing provider specializing in NetSuite-integrated commerce and a registered MSP/ISO of Elavon, Inc., a U.S. Bancorp subsidiary. Nimbus sells, supports, and owns the customer relationship. We design, ship, and operate the technology.

That work is multi-year and ongoing, and it covers the parts of a payments business where mistakes are expensive:

• NetSuite-integrated processing flows, with NetSuite as the system of record for invoices, customers, and payment events
• Customer-facing payment portals for one-time and recurring payments
• Card-present terminal workflows, orchestrated with compensating steps so a failed flow cleans up on its own
• ACH capture and automation built to NACHA operating rules
• Level II and Level III commercial card processing
• Tokenization, PCI scope reduction, and back-office reconciliation services

We did not learn about idempotency, reversible workflows, and audit trails from an AI project. We learned them from operating a processor's book of business without disruption while replacing the platform underneath it. The rules in the previous article are the rules that stack already runs under. AI is the newest thing that has to fit inside them.

We published the case against careless AI first

Our founder has written publicly and at length about where AI fails: the gap between the hype and what ships, the fiction of the average user that models are trained on, and the way a token bill becomes a measure of how little a company understood its own process before automating it. That writing is on the record, and it predates our AI implementation practice.

We consider that a qualification. A firm that spent two years documenting how AI goes wrong is a firm that knows what to check for. Nobody whose finance operation is at stake should want an AI cheerleader. They should want an engineer who expects the model to be wrong and has built the system so that it does not matter when it is.

What "responsible" means as a commitment

Three things, concretely.

We own outcomes, not deliverables. The engagement is not finished when the model returns an answer. It is finished when the process it sits in runs clean, with a cost that is known and a person who can explain any result.

We say no. The most valuable sentence in an AI engagement is "this part does not need a model." We will say it, and we will say it about work we would otherwise be paid to do.

We measure before and after. Every AI component is evaluated on the client's own history before it ships, and reported on per task after. If it does not clear the bar, it does not go live.

How to start

The lowest-risk first step is the AI spend audit: fixed fee, one week, a written report of where the AI budget is going, what is producing results, and what to cut. It is the same discipline we apply to cloud bills and payment-integration reviews, and it usually pays for itself.

For companies with a specific process in mind, the AI implementation practice starts with the process map described in the previous article and proceeds one edge at a time.

Either way, the conversation starts with the founder and is answered the same business day. That is not a funnel. It is the first instance of the principle this series is about: a named person, responsible for the result, from the first email.

The standard fits in one sentence. The model proposes, deterministic code decides, and a named person owns the outcome. Everything below is that sentence applied.

Rule 1: No model on the money path

Authorization, capture, void, refund, ACH origination, settlement, and posting to the system of record are executed by deterministic code. Idempotency keys on every mutating call. A compensating step defined for every step that touches real money, so a workflow that fails halfway cleans up automatically. Structured logs and tracing from the first commit.

This is the same discipline we already run for a live payment processor's production stack, with Go services, Temporal orchestration, and NetSuite as the system of record. AI does not change it. A model may be consulted before a money operation. It never executes one.

Rule 2: Models work at the edges, on judgment calls that used to be manual

The places where a model earns its keep in finance are the places where a person previously read something and formed an opinion:

• Reconciliation exception triage. Classifying unmatched items by likely cause (partial payment, duplicate, fee deduction, wrong customer) and routing them, so a person clears a sorted queue instead of a raw one.
• Document extraction. Pulling invoice numbers, amounts, and references out of remittance advices, lockbox images, and emailed PDFs, then handing the structured result to code that checks it against the ledger.
• Customer and support drafting. Writing the explanation for a declined card or a returned ACH in plain language, with a person pressing send.
• Anomaly flagging. Noticing that a merchant's settlement pattern changed, or that a batch is outside its historical range, and raising it before the bank does.
• Read-only questions over reporting data. "Which customers had a failed recurring charge twice this month?" answered from the data, never by writing to it.

Each of these produces a suggestion. None of them produces a posting.

Rule 3: Every model output is a proposal with a schema

The model's answer is a typed object, not free text. Code validates it: the amount matches an open invoice, the customer exists, the classification is one of the allowed values, the confidence is above the threshold set for that task. A proposal that fails validation goes to a review queue with the reason attached. It does not go to production, and it does not get retried until it passes.

Rule 4: A person is in the loop wherever money moves, by design

Human review is not a fallback for when the model is uncertain. It is the designed path for any action with financial effect. The model's job is to make that review fast: sorted, pre-filled, with the evidence attached. The person's job is to decide. That division is what makes the person responsible in the real sense, because they know what they approved and why.

Rule 5: Everything is reproducible after the fact

For every model call we keep the prompt, the model and version, the input, the output, the validation result, the decision, and who approved it. When an auditor, an acquiring bank, or a customer asks how a specific item was handled, the answer is a record, not a reconstruction. This is also what makes it possible to answer the only question that matters after an error: what did the system know, and who decided.

Rule 6: Evaluation before launch, with your data

Before any AI component ships, it runs against a harness built from the client's own historical cases: last year's exceptions, last quarter's remittances, the support tickets that were actually resolved. We measure the error rate per task and set the threshold with the client. If the component does not clear the bar, it does not ship, and the honest outcome of some engagements is "this part does not need a model."

Rule 7: Cost ceilings are designed in, not discovered on the invoice

Each task gets a budget. The smallest model that clears the evaluation bar is the one that runs. Repeated inputs are cached. Batch work is batched. Spend is reported per task, so the client knows what each capability costs and can turn it off. An AI feature whose cost cannot be predicted is a feature that has not been engineered yet.

Rule 8: Failure-mode analysis comes first

Before design, we write down what happens when the model is wrong: what the wrong answer looks like, what it would touch, who notices, and how long it takes them. If the answer is "a customer is charged twice and finds out on their statement," the design is wrong and we start over. If the answer is "an item lands in the review queue with the wrong label and a person re-labels it," the design is acceptable.

What this looks like in an engagement

A typical engagement starts with the process, not the model. We map where the manual judgment actually happens, measure how much of it there is, and fix anything in the underlying process that is broken before AI touches it. Then we pick one edge, build the proposal-validate-review loop around it, evaluate it on real history, ship it with a cost ceiling and a full audit trail, and operate it. The next edge follows once the first one has run clean for a month.

That is slower than dropping an agent onto the problem. It is also the only version of AI in finance that leaves somebody responsible, which is the only version we are willing to put our name on.

Finance is the opposite discipline. An invoice is paid or it is not. A settlement file balances to the cent or the bank calls in the morning. A refund either reached the card or a customer is filing a dispute. There is no "most likely" state of a ledger. There is the correct state, and there is an error that someone has to find, explain, and fix.

That difference is the whole subject of this article. AI is not a magic wand in finance. It becomes useful in exactly one condition: when a person is responsible for the system the model lives in, understands what the model can and cannot do, and has built the surrounding machinery so that the model's mistakes are caught before they touch money.

What a language model actually gives you

Strip away the product names and a model does one thing. It maps text to a distribution over possible next tokens and samples from it. Everything else, the agents, the tools, the "reasoning," is scaffolding around that operation.

This has consequences that do not go away with a better model:

• The same input can produce different outputs. Reproducibility, the first requirement of any audited process, is not a native property. It has to be engineered around the model.
• Confidence is not accuracy. A model's tone is the same whether the answer is right or wrong. The fluency that makes it pleasant to use is precisely what makes its errors hard to spot.
• It has no concept of "balanced." A model can write the word reconciliation. It cannot know that a reconciliation is correct, because correctness is a property of the world, not of the text.
• It will do anything to complete the task. Left unsupervised, an agent whose instruction is "resolve this" will resolve it, and the cheapest resolution from the model's point of view is frequently the most expensive from yours.

None of these are defects to be fixed in the next release. They are what the technology is.

What finance actually requires

The other side of the gap is just as fixed.

Money movement in the United States runs under rules that are written down and enforced: NACHA operating rules for ACH, card network rules and PCI DSS for card data, GAAP for how the result is reported, and the plain contractual fact that a merchant's funds are a merchant's funds. Every one of those frameworks assumes that a specific, identifiable party is accountable for every transaction.

A regulator, an auditor, an acquiring bank, or a customer's lawyer does not accept "the model decided." Neither does a CFO whose month-end close does not tie out. In finance, the question after any error is never "what happened?" It is "who is responsible, and what did they know?"

That question has to have an answer before the system goes live, not after.

Responsibility does not transfer to software

Responsibility is often treated as a question of blame: who takes the fall when something breaks. That is the wrong definition, and it is the one that gets companies into trouble with AI.

Responsibility, properly understood, is the state of knowing what is running, having control over it, and being answerable for the result. A responsible engineer knows what the five servers do, how the cache behaves under load, and why the payment workflow retried three times at 2 a.m. That knowledge is what makes the system reliable, and it is what makes the person valuable.

Automation does not dilute that responsibility. It concentrates it. When a model is placed in a process, the person who put it there is now responsible for the model's output as well as everything they were responsible for before. There is no arrangement in which "the AI handles it" and nobody is on the hook. There is only the arrangement in which someone is on the hook and has not noticed yet.

This is why dropping an AI agent onto a process that is already broken makes it worse. If the reconciliation process is a mess and nobody can explain why the exceptions queue grows every week, the correct first move is to stop, study the process, and fix it. A model layered on top of a broken process automates the brokenness and adds a token bill. A model layered on top of a working process, by someone who understands both, can make it materially better.

When AI is a magic wand

There is a version of the "magic wand" that is true. In the hands of someone who owns the outcome, who has decided exactly which decisions the model is allowed to influence, who validates every output with deterministic code before it takes effect, and who can reproduce and explain any result after the fact, a model does things that were previously not economical: reading thousands of remittance advices, triaging exceptions by likely cause, drafting the customer explanation for a failed payment, finding the anomaly in a settlement report before the bank does.

That is not the model being magic. That is a responsible engineer using a probabilistic tool inside a deterministic system, with the boundary between the two drawn deliberately.

The rest of this series is about where that boundary goes and how we draw it: the implementation standard we apply when AI goes into payment and finance systems, and the record that makes us confident applying it.

Responsibility, defined

The dictionary definition is useful here. Responsibility is the state of having a duty to deal with something, or having control over it. A duty is a moral or legal obligation.

So to be responsible for something is to consider that you have an obligation toward it and that you have control over it. That is not a burden. It is the condition under which a thing can be kept in working order. A person responsible for a vehicle keeps it maintained. A person responsible for equipment keeps it operational. An accountant responsible for the books keeps them reconciled.

Responsibility is often confused with blame, which is the state of being held accountable for something that has already gone wrong. That confusion is itself a symptom. Either the area is in order and someone is responsible for it, or it is not, and the search for a scapegoat has begun.

How to recognize an irresponsible area

A person who is not responsible for an area avoids it. An experienced manager knows the signs: the meetings that are missed, the reports that arrive late, the tasks performed mechanically because they are required rather than owned. Any organization has such areas, and there is a reliable way to locate them. Where there is a great deal of activity and very little output, there is a concentration of irresponsibility.

Hiring is the clearest contemporary example. On one side, employers deploy automated screening because nobody wants to read the applications. On the other, candidates use automated tools to produce applications that pass the screening. The result is machines on both sides generating enormous activity while very few people are hired. Nobody in the chain is responsible for the outcome, and the outcome shows it.

The token bill

Now apply this to AI agents: systems that are given a goal, tools, and a budget, and set loose on a task. Where the task is well understood, this is useful. Where it is not, the pattern is predictable.

A process is not working. Nobody examines why. An agent is placed on top of it with instructions to handle it. The process continues not to work, exactly as before, and a new cost is added, because the agent is diligent. It will do anything to complete the task it was given, and the cheapest way for an agent to complete an ill-defined task is to keep trying. The bill for that is measured in tokens.

The rule is simple. A field of irresponsibility cannot be repaired by adding more irresponsibility to it. If a hiring process costs far more per hire than it should and nobody can explain why, an agent will not reduce the cost. It will add its own cost on top.

The characteristic outcome is a manager who is pleased with an automation that sends a polite acknowledgment to every incoming application at a substantial monthly cost, while the recruiting the company actually asked for has still not happened. The automation is a response to the wrong problem, produced by someone who was avoiding the right one.

The order of operations

There is a sequence that works, and it does not start with the model.

Stop the process. When the warning light comes on, pull over. A process that produces no output should not continue running, and certainly should not be accelerated.

Study it. If you are responsible for the area, go in and find out what is wrong. Engineers absorbed in side projects. A finance team that replaced software that worked for a decade and now cannot take a payment. An invoicing department replaced by a single agent that has no idea how to accept one. All of these are real, and all of them are visible to anyone who looks.

Correct it, and record what happened. Find the specific failure, have the responsible person fix it, and write down what went wrong and how the organization will avoid it. If the responsible person was you, that applies equally.

Then automate. Once the process produces its output reliably, a model layered on top of it can make it faster and cheaper. Automation multiplies whatever is already there. On a working process it multiplies output. On a broken one it multiplies cost.

A budget is a statement of understanding

My own AI spend is a fixed monthly amount, and it is enough to run a great deal of work. That is possible because I know what I ran and why, I can estimate each task in advance, and when something goes wrong I do not retry until the bill grows. I stop, find the cause, and correct it before the model touches the task again.

That is the whole principle of AI cost engineering as we practice it. A cost ceiling is not a constraint imposed on a working system. It is evidence that the system is understood. When a company cannot say what its AI spend will be next month, the problem is rarely the price of tokens. It is that nobody is responsible for the process the tokens are being spent on.

What the word means

Support is help provided to someone. Help is making it easier for someone to do something by offering one's own services or resources.

The possessive matters. The party providing help is expected to contribute something of its own. When a customer contacts a company for support, that is what they are owed, and it is as central to the business as sales or collections. A model deployed to deflect inconvenient requests does not reduce the number of inconvenient requests. It produces more of them, from angrier customers, with a support ticket now attached to a churn risk.

The competitive consequence

Consider the position from the other side. A company that has replaced its first line of support with a model has handed every competitor a script:

You are currently a customer of a firm that answers support with an automated agent. We offer the same service with two differences. We are somewhat more expensive, and when you call, a person in this country answers.

That pitch closes. Customers will pay a premium for a competent human on the line, and the premium is large relative to the cost of providing it. Any company that answers the phone can take customers from a company that does not.

Scale is not the argument

The models that make automated support rational for the largest platforms do not apply to a company receiving ten calls a day. Those companies do not need an electronic holding pen. They need someone to pick up, resolve the issue, and, while the customer is satisfied and on the line, offer them the next thing they need. That is not a cost center. It is one of the most reliable sales channels a small or mid-sized company has.

Where a model does belong in support

None of this means AI has no role in a support operation. It has a useful one, behind the person rather than in front of the customer:

• Drafting the reply to a routine question, for a person to review and send.
• Retrieving the relevant order, invoice or account history so the person answering does not have to search for it.
• Classifying and routing incoming requests so the right person sees them first.
• Summarizing a long thread for whoever picks it up next.

In each case the model makes the human faster. The human still provides the help. That is the same division of labor we apply when we put AI into finance systems: the model proposes, the person is responsible, and the customer never has to find out which is which.

How the artefact was priced

In the 1980s a copy of a program was a product in the ordinary sense. A programmer could write a game, place an advertisement, and sell the cassette for a fair price. The buyer received something, the author was paid, and the transaction made sense to everyone involved.

The 1990s strained that model but did not break it. Piracy was already widespread, and yet substantial companies, from compiler vendors to operating-system publishers, were built on the premise that code in itself was worth paying for.

The 2000s introduced software as a service, and the floor began to give. By the end of the 2010s the price of code as an artefact had fallen close to zero. A few independent developers still sold packaged software successfully, but they were survivors of a category that had largely disappeared.

What SaaS actually did was relocate the price. It moved from the code to the service around the code: uptime, patches, backups, the database recovery at three in the morning. For a business customer this was a better arrangement. Nobody wanted to own the floppies. They wanted the outcome.

What AI did to the price

As of 2025, the price of code as an artefact is not zero. It is negative.

That is a precise claim. It is now more expensive, in token cost, maintenance burden and the effort of keeping a model on task, to maintain a large, carefully documented codebase than not to have one. Models still struggle with very large legacy systems; nobody is regenerating a million lines of enterprise Java in an afternoon. But for small and mid-sized systems, a competent engineer with a modern model can reproduce almost any product you could name in a working day. An open-source project can be cloned in hours, sometimes with better organization than the original.

The usual objections are correct and do not change the conclusion. Tests, observability, migrations that do not fail at nine in the morning, all of it is still required. It is also now largely generated. Hand the existing test suite to a model, ask for the rewrite, and it works.

The consequence is that there is no meaningful intellectual property in ordinary application code anymore. There has not been for some time. What has changed is that it is no longer possible to pretend otherwise.

What this means for the "10x engineer"

For a brief period the industry believed in the ten-times programmer, a person worth a finder's fee and a war room. That role has not been eliminated. It has been made ordinary. Any well-trained engineer who understands the fundamentals, can lay out a system, and is willing to work with a model can now ship in an hour what the celebrated engineer of 2010 produced in a week. Not because they are exceptional, but because the floor moved.

Where the value went

It went where it has always been. The question every business has faced for the whole history of commerce is the same: what can you do, who needs it, and how does that need become revenue. The industry spent two decades treating the artefact as the product because the artefact was hard enough to make that it could be charged for. It is not hard anymore, so we are back to the fundamentals.

There are a great many businesses with real customers and real cash flow running their operations on a forty-tab spreadsheet that one employee maintains by hand every Monday morning. That spreadsheet is a problem someone could solve. Not by writing software, because software is now the cheap part, but by understanding the business well enough to put the right system in front of it, and by taking responsibility for that system once it is running.

That is where the engineer of 2026 is useful, and it is how this firm positions itself. The code is the easy part. It always was. It was simply hard enough, for long enough, that it obscured the work that actually mattered.

Two definitions

Two ideas underpin everything that follows.

Feeling foolish is the result of a hidden assumption. You reach for a hook that someone has moved, and your keys land on the floor. You fill a diesel engine with gasoline because nobody told you it was diesel. In both cases the cost is caused by something you did not know was there. In software, the expensive version of this is deploying a system whose behavior you have not actually understood.

A system works only if it runs without supervision. Every machine needs maintenance, but maintenance is a known, scheduled action: change the oil, rotate the keys, patch the server. If an application needs to be nudged, restarted, corrected or babysat to do its ordinary job, it is not a working application. It is a broken one with an operator attached.

These two definitions are the standard against which I judge any tool, including this one.

What a computer is

A computer is a device that gathers, stores, processes and transmits information. Processing means executing a precise sequence of instructions. That precision is the entire value of the machine.

Programming, properly done, is an exact discipline. I can predict what a given instruction will do. I can state the reliability of a system within defined bounds. There are established methods for fault tolerance, for real-time guarantees in aircraft and telecom equipment, and for the arithmetic in banking systems that computes balances and fees so precisely that nobody notices it. A computer can repeat a task indefinitely without deviation, and that is why we built it. The word "computer" once described the people who did arithmetic by hand for aerospace and military programs. We replaced them because the machine does not drift.

What a language model adds

Under the product names, a large language model is matrix arithmetic with controlled randomness introduced into the output. That randomness is what lets it recombine language in useful ways. It is also a deliberate departure from the definition above. A computer is supposed to return an exact answer. A model returns a probable one.

This is not a criticism of the technology. It is a description of it, and it has consequences that no amount of investment removes:

• No model can guarantee a correct answer. That limits its use wherever correctness is the requirement rather than a preference.
• A model-driven system needs care. It must be checked, corrected and constrained, which means that by the second definition above it is not, on its own, a working system.
• The output is fluent whether it is right or wrong, so the errors are harder to see than the errors of a conventional program.

The practical risk follows directly. A single misread command in a generated script can delete a working directory or an entire filesystem. Generated code reaches production unreviewed because it looked plausible and the deadline was real. In banking and payments, where I do most of my work, the people responsible for the ledger understand this instinctively. When someone suggests putting a model on the money path, they do not need the argument explained to them.

Where the technology is genuinely useful

Skepticism about the pitch is not dismissal of the tool. There are tasks where a probabilistic answer is exactly what is wanted.

• Large-scale pattern work. Predictive models over big datasets, weather being the obvious example, produce more nuanced probabilities than we had before. They are still probabilities.
• Text transformation. Rewriting for tone, changing register, producing a first-pass translation that a person then corrects. These tasks were never exact, and the model does them far better than a global find-and-replace.
• Reading at volume. Summarizing, classifying and extracting from documents that a person previously had to read one by one.

What these have in common is that a nearly right answer is valuable and a person checks the result. Where a nearly right answer is worthless, such as a settlement file, a balance, or a command executed with elevated privileges, the model does not belong in the loop without deterministic code and a person around it.

The human cost

The area where over-reliance does the most damage is anything involving people. Screening candidates is the clearest case. With thousands of applications per opening, some automation is unavoidable. But every rejection a model issues has a reason that nobody examined. The system will admit a candidate who interviews well on paper and reject an excellent engineer who does not happen to match a pattern. The only remedy is the one that has always worked: a person talks to the candidate.

The balance

The claim in the market is that AI is a gold mine with no downside. The reality is that it is another technology that must be studied, understood and applied with judgment. Ignore it and you will be slow. Apply it everywhere and you will spend your time debugging plausible nonsense. The balance is specific to each task, and finding it is engineering work, not a purchasing decision.

That is the position this firm implements from. We expect the model to be wrong, we design so that it does not matter when it is, and we say plainly when a task does not need a model at all. Before accepting any vendor's claim that AI must be everywhere, ask to see the sales figures and the earnings of the companies making it.