Most writing about AI in the ERP falls into two camps. One asks whether agents belong near the general ledger at all. The other lists governance controls a buyer should demand. Neither opens the hood. The question a controller actually needs answered is more concrete: what is the runtime shape of the system, which component holds which responsibility, and where exactly does the deterministic ledger end and the probabilistic model begin.
That boundary is where every real risk lives. An AI-native ERP architecture that cannot draw it on a whiteboard is a wrapper around a legacy database with a chat window glued to the front. One that can draw it is a different kind of system, and the difference shows up on the audit trail. What follows is a walk through the five layers that matter: the orchestrator, the role-based finance agents, the retrieval layer, the tool and function boundary, and the ledger write path itself.
The Orchestrator Decides, the Agents Do Not
The orchestrator is the control plane. It receives an inbound event (an email with an invoice, a bank feed line, a close task becoming due) and decomposes it into a plan: which agent runs, in what order, on what data, with which approvals attached. The dominant production pattern is supervisor-style, where a central planner routes work to specialists and reconciles their outputs before anything commits. Industry write-ups of production deployments converge on the same shape, with the planner, policy, execution and state components kept as separate concerns rather than fused into one monolithic prompt. Microsoft's reference on AI agent design patterns catalogs the trade-offs; the supervisor variant is the one that survives SOX scrutiny because the plan itself is an auditable artifact.
Two properties of the orchestrator matter more than the rest. First, it is deterministic code, not a model: the planner may call an LLM for intent parsing, but the state machine that moves a workflow from "invoice received" to "posted" is ordinary software with explicit transitions. Second, it holds the only permissions that touch the ledger. Agents request; the orchestrator approves and executes. That split is the architectural reason a well-designed system can say, with a straight face, that the AI never writes to the books.
Role-Based Agents Mirror the Finance Org Chart
Specialization is not cosmetic. An AP agent, an AR agent, a controller agent and a CFO agent exist as distinct processes because their prompts, their tool access, their retrieval scopes and their approval thresholds all differ. Collapsing them into one general agent is how you get a system that can post a journal it was never supposed to touch.
The AP agent handles the extract, code, three-way match and schedule-for-payment loop. The AR agent handles application of cash, dunning cadence and dispute triage. The controller agent owns reconciliations, accrual calculations and close checklists. The CFO agent runs variance analysis and board-pack narrative against the closed books. Each one has a bounded tool set and a bounded data scope. The AR agent cannot call pay-vendor, and the AP agent cannot see customer credit limits. This is the same principle a controller already applies to human staff; the ERP enforces it in code. For the mechanics of where thresholds should actually sit, the piece on AP agent approval thresholds and the architectural note on what an agent cannot do inside a ledger carry the detail.
Retrieval Is Where Grounding Lives
Agents without retrieval hallucinate. Agents with retrieval cite. RAG in ERP is a narrower problem than general enterprise RAG because the corpus is more structured and the freshness bar is harsher. A controller agent asked "what accrual did we book for this vendor last quarter" needs the actual GL rows, not a summary of a PDF of a report of the GL.
Three retrieval surfaces usually coexist. The structured surface is direct, parameterized SQL against the ledger and sub-ledgers, read-only, scoped by entity and period. The semi-structured surface is vector search over invoices, contracts, bank statements and emails. The policy surface is a smaller, curated store of accounting policies, approval matrices, chart-of-accounts rules and vendor master records. A good agent query hits all three: pull the matching invoice document, pull the contract clause that governs its treatment, and pull the three most recent similar postings so the proposed coding sits inside precedent. The pattern is the one described in IBM's primer on retrieval augmented generation, adapted to finance by making the ledger itself one of the retrieval targets rather than a downstream destination.
Freshness and permissions are where this gets hard. Research reports that 77% of enterprises do not have real-time access to ERP data, which means most retrieval layers bolted onto legacy systems are reading a snapshot that is already stale. An AI-native ERP collapses that gap because the retrieval index and the ledger share the same event stream. The second hurdle is governance: Gartner's February 2025 survey found that 63% of organizations either lack AI-ready data management practices or are not sure they have them, and predicted that through 2026 organizations will abandon 60% of AI projects that lack AI-ready data. The retrieval layer is where "AI-ready" stops being a slogan and starts being row-level permissions and entity-scoped indexes.
The Tool and Function Boundary Is the Safety Rail
An agent cannot read a database. An agent cannot post a journal. An agent can only call a function, and the function is where the controls live. This is the single most important design decision in the stack, and it is also the one most easily smudged in a sales demo.
Every meaningful action an agent takes passes through a typed function call with validated inputs, declared side effects and a logged return value. propose_journal(entries, memo, source_docs) returns a draft with a proposed posting date and a confidence score; it does not write. commit_journal(draft_id, approver_id) is a separate call, available to the orchestrator only after policy checks pass, and it is the only path that mutates the ledger. The split matters because it lets the system reason about the proposal as data (route it, score it, show it to a human, batch it) before any debit or credit exists.
The function layer is also where tool access is scoped per agent role. The AP agent gets propose_journal, match_invoice_to_po, schedule_payment and request_vendor_clarification. It does not get commit_payment above its threshold or edit_vendor_master. The AR agent has its own list. Changelog entries, approval chains and the input and output of every call are written to an immutable audit log keyed by workflow ID. A controller running a sample test should be able to reconstruct, for any posted journal, the full chain: inbound document, extraction confidence, matching evidence, policy check results, proposing agent, approving human or threshold, posting timestamp. This is also the enforcement layer behind an Acceptable Use Policy that means something.
The Ledger Write Path Stays Deterministic
The ledger is a double-entry database with the usual guarantees: ACID transactions, period locks, reversal rules, entity hierarchies. The AI touches none of it directly. A proposed journal enters a staging table with its full provenance. Deterministic rules evaluate the proposal against the chart of accounts, the open period, the approval matrix and the duplicate-detection heuristics. Only after those gates clear does a plain SQL transaction post the entry.
This is the architectural reason daily reconciliation proof is possible at all. If the agent could reach around the gates, every reconciliation would need to re-verify agent behavior from scratch. Because the write path is narrow and logged, reconciliation reduces to the ordinary comparison of ledger to sub-ledger to bank, and the AI's role is confined to proposing matches and explaining breaks. The posture matters because the current state of agent reliability is still modest: on the OSWorld 2.0 benchmark of long professional workflows, the best agent completed only 20.6% of tasks end to end as of June 2026. A deterministic ledger does not need the agent to be right 100% of the time; it needs the agent to be observable and reversible 100% of the time, which is a lower bar and a solvable one.
How the Pieces Fit at Runtime
A single AP transaction, traced through the stack, makes the architecture concrete. An invoice email arrives. The orchestrator opens a workflow, dispatches the AP agent, and attaches the vendor's master record and the open POs as retrieval context. The agent extracts header and line data, proposes a GL coding against the three most similar historical postings, and calls propose_journal with the matched PO as evidence. The orchestrator runs policy checks: amount under threshold, vendor active, period open, no duplicate within 60 days. If all pass, commit_journal fires. If any fail, the workflow suspends and routes to the controller agent, which composes a human-ready exception. The audit log records every step with timestamps and inputs.
The same shape repeats for cash application, accrual calculation and close task completion. The orchestrator plans, the agents propose, retrieval grounds, the function layer validates, the ledger commits. For a buyer evaluating vendors, this is the diagram to ask for and the one to interrogate. Where does the model write? What is the function signature of the write call? What is logged, and who can read the log. The secure AI agent access piece covers the identity and permission layer in more depth, and the erp.io platform page shows how these components are packaged in production.
What a Buyer Should Verify
Architecture claims are easy to make and hard to test. Four questions separate a system engineered the way vendors describe it from a system that merely narrates the description. First, show the function catalog: every tool each agent can call, with signatures and side effects. If the list is marketing bullets rather than typed functions, the boundary is not real. Second, show a sample audit log for a posted journal, end to end, from inbound document to committed entry. Third, demonstrate the retrieval scope: ask the AR agent for AP data and watch what happens. Fourth, pull the deterministic rule set that gates the write path, including the duplicate detection window and the period lock behavior.
None of this is exotic. These are the same questions a finance-systems lead would ask of any new sub-ledger or integration before letting it near production. The novelty is that an AI-native ERP architecture collects more of the answers into the vendor's own code, which means they can be inspected rather than inferred. A system that cannot show its orchestrator, its agent roster, its retrieval surfaces, its function boundary and its ledger write path as separate, named components is almost certainly a chat layer on a conventional database. A system that can is worth the second meeting.