Deterministic Controls for Finance AI Agents: The Hybrid Architecture for 2026

By Infonaligy · Updated August 10, 2026 · 7 min read

Finance teams spent 2025 asking whether an AI agent could close the books. The better question is which part of the work a probabilistic model should touch at all. The answer settling into practice is a split architecture: the model reads and proposes, while a separate deterministic layer, built from human-approved rules, performs the posting, approval, and payment.

This is a control design, not a preference. An agent that is 97 percent accurate at coding invoices is impressive as research and unacceptable as a subledger: the 3 percent lands in a ledger auditors will test and a bank account that moves real money. The market converged fast. On August 4, 2026, Kognitos announced Context Graph for Finance, pairing finance-specific context and human-approved rules with deterministic execution, starting with accounts payable. Fiserv's agentOS, launched in May 2026 and slated for broad availability by August 2026, embeds policy controls, auditability, and human oversight by design. Gartner has predicted that 40 percent of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5 percent in 2025. Agents are arriving whether or not you designed controls around them.

Why are probabilistic AI agents unsafe for high-stakes accounting?

Because a large language model produces the most plausible response, not the same approved rule applied identically every run. That is a feature for drafting and a defect for execution. Finance controls depend on three properties a raw model cannot offer:

• Repeatability. Re-running the same invoice can yield a different GL account. Auditors test controls by re-performance, and a control that cannot be re-performed is not a control.
• Explainability. A chain-of-thought narrative is a generated artifact, not evidence. A rule identifier plus the inputs it evaluated is evidence.
• Bounded failure. Deterministic code fails loudly on inputs it does not recognize. A model fills the gap with something confident and wrong.

Accuracy is not the control. What happens between the suggestion and the ledger entry is.

Where is non-determinism acceptable in finance workflows?

Draw the line at state change and money movement. Non-determinism is fine wherever the output is a proposal a rule or person will validate, and unacceptable wherever it is the final act.

Acceptable (perception and reasoning): extracting fields from an unstructured invoice, reading a contract for payment terms, normalizing vendor names, summarizing a variance, drafting an accrual memo, proposing a bank-line match, triaging exceptions.

Unacceptable (execution): posting a journal entry, releasing a payment file, changing vendor banking details, approving against a delegation of authority, adjusting a reserve, closing a period, writing off a balance. These belong to code with a version number and a test suite.

How do you split the agent from the executor?

Build two components with a contract between them, not one agent holding write credentials.

The agent (perception and reasoning)

It turns messy reality into a structured proposal: entity, vendor, amounts, dates, proposed coding, matched purchase order and receipt, evidence, and a confidence signal. It has read access and zero write credentials. This is where purpose-built AI agents earn their keep, since the hard part is comprehension, not clicking.

The executor (deterministic and auditable)

It accepts or rejects that proposal, validating against a schema, evaluating approved rules in fixed order, checking the three-way match and delegation of authority, then either posting through the ERP's supported API or routing to a human queue with a named reason code. No model call lives inside it. It is ordinary software, versioned in Git, tested in CI, shipped through the same AI DevOps pipeline as production. Never let it interpret a partial proposal.

What approval thresholds and human-in-the-loop rules work?

Thresholds belong in policy, not discovered in code. A starting pattern for accounts payable, tuned to your materiality:

• Straight-through: perfect three-way match, known vendor with banking details unchanged for 90 days, amount within tolerance of the purchase order (for example, 2 percent or a fixed dollar cap, whichever is lower).
• Single approver: non-PO invoices under the department's delegated limit, or matched invoices with variance inside tolerance. The approver sees the proposal, the evidence, and the rule that fired.
• Dual approval: anything above the delegated limit, any new vendor, any bank detail change, any manual journal entry above materiality.
• Never automated: vendor banking changes initiated from an inbound document, duplicate-suspect payments, payments to vendors inside a cooling-off window, anything flagged by sanctions or fraud screening.

Two rules keep human-in-the-loop honest. Approval must be an affirmative act on a specific proposal, not a bulk acknowledgment of a queue. And measure your override rate: if approvers accept more than roughly 98 percent of proposals without edits, review has become a rubber stamp. Segregation of duties applies to the agent too: whoever can change a rule must not be able to approve a payment it releases, an extension of your identity and access controls.

What does an immutable audit trail need to contain?

Assume an auditor asks you to re-perform a year-old transaction. Capture, in append-only storage matching your retention policy:

• The source document, hashed, with the hash stored alongside the entry.
• The structured proposal, plus model version, prompt version, and retrieval sources.
• The rule set version and rule identifiers that evaluated, including those that did not fire.
• The decision outcome, reason code, and resulting ERP document numbers.
• The human actor, timestamp, and what they saw at approval.
• Every rule change, with author, approver, effective date, and ticket reference.

Two details matter more than teams expect. Log the rules that evaluated false, because negative evidence is how you demonstrate a control operated. And version rules with effective dating, so a March transaction is explained by March's rules, not today's. Pair this with agent observability so extraction drift surfaces as an alert, not an audit finding.

How do idempotency and replay safety prevent duplicate payments?

Give every proposal a deterministic idempotency key: a hash of vendor identifier, invoice number, invoice date, currency, and amount. The executor checks that key before writing and returns the prior result rather than creating a second document. Where the ERP or banking API lacks native idempotency, keep your own ledger of attempted operations, and treat a timed-out response as requiring reconciliation before retry, never as license to resend.

Duplicate payment turns an automation win into a restatement conversation. Retries, queue redelivery, and partial outages create the conditions, and an agent that decides to try again makes it worse.

Replay safety is the same discipline pointed backward: replay a day of proposals against a new rule version in a sandbox and diff the outcomes. If replaying yesterday produces different postings today, either your rules changed (fine, if documented) or your executor has hidden state.

Why is reconciliation still the control that catches everything else?

Preventive controls stop what you anticipated. Reconciliation catches what you did not, and it is the best early warning that an agent has started behaving differently. Reconcile daily rather than monthly: subledger to general ledger, bank to cash, and the agent's proposal log to the postings that actually exist in the ERP. The third comparison is the important one: it catches postings with no proposal, proposals that posted without passing the executor, and count mismatches signaling a retry problem. Set a variance threshold, alert on breach, and name an owner for every aging item. Most automated reconciliation programs cover the first two and skip the third.

How should you test finance agents before go-live?

Do not pilot on live payments. Run the agent against real historical volume with writes disabled, comparing proposals to what your team did.

• Backtest 6 to 12 months across the full seasonal range, including your worst month.
• Build an adversarial set: near-duplicate invoices, credit memos, partial receipts, FX rounding, retroactive price changes, similar vendor names, and documents whose header and line totals disagree.
• Test the executor separately with unit tests per rule, including boundaries. Threshold bugs live at exactly the threshold value.
• Define exit criteria first: zero unauthorized writes in shadow mode, exception rate stable across four consecutive weeks, near-zero proposals that would have posted incorrectly.

Then run in parallel, with the agent proposing and humans deciding, and measure agreement. Our approach to simulation testing for AI agents goes deeper. This is the phase teams most regret shortening.

What is a realistic rollout sequence?

Sequence by reversibility. Start where a mistake is cheap to unwind.

• Weeks 1 to 3. Pick one process, almost always accounts payable, and one entity. Write down the rules that already exist informally. This is where surprises surface.
• Weeks 4 to 8. Build the agent read-only, the executor rules-only. Run shadow mode against history. When outcomes disagree, fix the rules, not the model.
• Weeks 9 to 12. Parallel run with human approval on every item. Stand up daily reconciliation and the audit log. Brief internal audit and your external auditor now, not after go-live.
• Weeks 13 to 16. Enable straight-through processing for the narrowest tier only: matched PO invoices under a low dollar cap from long-standing vendors. Hold for a full close cycle.
• Quarter 2 onward. Widen thresholds one variable at a time, then add a second entity and process. Never widen two dimensions at once, or you will not know which caused the drift.

Expect this to be slower and duller than the demos, and expect that to be the point. The organizations getting durable results are not those with the most autonomous finance agents, but those who decided early which decisions a model may make, and wrote the rest as code.

Infonaligy is an AI consulting and IT services firm based in Dallas-Fort Worth, delivering remotely nationwide. We help finance and IT leaders design the split between reasoning and execution and prove the control layer works before it touches the ledger. If you are scoping touchless AP automation or broader process automation, our consulting team can pressure-test it: hello@infonaligy.com or 800-985-1365.