A payment decision has to be exact and repeatable. So in the product I built, the money logic is deterministic code, and the agent only touches the parts where judgement is genuinely open-ended.
Every AI demo right now is an agent doing everything. Point it at the problem, let it reason end to end, marvel at the trace. It demos beautifully. Then you try to put it in front of a real workflow with real money and it falls apart, because the thing that makes a demo impressive, the model deciding freely, is exactly the thing you cannot allow when the output is a payment.
I spent a while building a procure-to-pay product: a vendor invoice comes in, gets extracted, matched against a purchase order, routed through an approval workflow, and reconciled. It is the kind of thing everyone now wants to put an agent on. So I did, sort of. But the interesting decision, the one that took the longest to get right, was not where to add the agent. It was where to refuse to.
The rule: a payment decision must be exact and repeatable
A model is a probability distribution. Ask it the same question twice and you can get two answers. That is a feature when the task is fuzzy and a liability when the task is "does this $48,200 invoice match this purchase order". Matching, the approval engine, reconciliation: these have to be exact, auditable, and identical every run. So they are plain deterministic code. No model in the path. If a controller asks why this got approved, the answer is a code path they can read, not "the model felt it was fine".
That sounds obvious written down. It is not how most people are building AI features right now. The default has become: agent first, and carve out the deterministic parts only when something breaks. I did the opposite. Deterministic by default, agent only where the trajectory is genuinely open-ended.
The three places the agent actually earns its keep
Once you hold that line, the places where AI belongs get very clear, because they are exactly the places a deterministic rule would be brittle or impossible.
Reading the messy vendor PDF. Invoices are a thousand different layouts. A parser built on regex and rules is a losing game. This is real fuzziness: vision model in, structured data out, validated against a schema. The model does the perception; code does everything downstream once the data is structured.
Deriving the approval workflow from the org chart. Onboarding a client used to be a forward-deployed engineer reading their HR system and hand-building the approval rules. The genuinely hard part is mapping titles to signing authority: which role approves what, resolved to a real person, with the data-quality problems (a terminated manager, two people who both look like the CEO) flagged for a human. That judgement is fuzzy, so the agent makes it. But it produces a proposal, not a decision: a human reviews and edits it in plain language before anything goes live.
Investigating a flagged exception. When a bill trips a rule, someone has to judge it against unstructured context, notes, prior invoices, vendor history, and recommend. That is reading and reasoning over messy evidence, which is what models are good at. So the agent investigates and recommends. It does not act. A human sees the recommendation and decides.
Notice the pattern in all three: the model does perception or judgement over unstructured input, and hands a proposal to either deterministic code or a human. It never holds the pen on the outcome.
Human in the loop is a design principle, not a disclaimer
"Human in the loop" usually shows up as a safety label bolted onto an otherwise autonomous system. Here it is structural. Nothing posts until a person approves. The agent derives, reads, investigates, recommends, and then stops. The interesting engineering is in making that handoff good: showing the human exactly what the agent concluded and why, right where they decide, so the review is fast instead of a rubber stamp or a bottleneck.
That is also the honest answer to "will AI replace this job". In a system that touches money, the agent removes the tedium (reading the PDF, drafting the workflow, triaging the exception) and leaves the decision with the person accountable for it. That is not a limitation I worked around. It is the product.
Why this is the actual skill
The prompt was never the hard part. Wiring a model to a task is a weekend. The hard part is the judgement about the system: which parts must be exact, which parts are genuinely open-ended, and how the two halves hand off without the fuzzy half ever making a decision the exact half should own. Get that wrong and you have an impressive demo that no finance team will ever trust. Get it right and the AI disappears into the places it belongs, and the rest is boring, auditable, correct code, which is exactly what you want when the output is someone's money.
If you want to see the whole loop, an agent deriving an approval workflow from an HR system, then a real invoice routed through it with a live trace, paused for a human at the gate: the ledgerloop case study has it, the demo is live, and the source is on GitHub. Built with Mastra.
Originally published at dylan.merigaud.com.
