Agentic ERP architecture

The five layers

Only one of these involves a model.

Trigger layer

Events rather than screens. A bill arrives, a feed updates, a contract is signed, a period opens. This is what makes the system agentic rather than assistive, and it is the piece most retrofits skip.

Shared data model

An agent reasoning about a bill needs the contract, the PO, the budget, and the payment history in one query. Six systems joined by a sync cannot supply context at reasoning time.

Typed proposal

The agent emits a structured object — action, targets, amounts, dimensions, policy, confidence — not a natural-language instruction. The boundary between probabilistic and deterministic is a schema.

Deterministic policy engine

Code evaluates the proposal against your configuration and returns permit, hold, or reject. It never reads a prompt, so no phrasing changes its answer.

Audit schema

Model version, context, sources, reasoning, confidence, policy version, approver, resulting entry — designed for automated activity rather than adapted from a user log.

The typed proposal is the load-bearing decision

The interface between the probabilistic part of the system and the deterministic part determines almost everything about whether the result can be governed. If that interface is natural language — the model tells the system what to do in prose — then enforcement has to interpret text, and interpretation is exactly the thing you were trying to remove from the critical path.

Making it a typed object changes the properties available to you. The boundary becomes versionable, testable, and inspectable. A proposal can be logged, replayed, and compared. And crucially the policy engine never reads a prompt, so there is no phrasing that produces a different enforcement outcome.

If the boundary between the model and the ledger is prose, enforcement means interpreting text — which is the thing you were trying to keep off the critical path.

What a proposal contains

Action type, target record identifiers, monetary amounts by line, dimension assignments, the policy the agent believes applies, source records consulted, a reasoning summary, and per-field confidence. The engine reads the structured fields; the reasoning summary is recorded for humans and is explicitly not part of the control.

Why this is hard to retrofit

Every incumbent can add a model. What is hard to add to a system designed around human-initiated screens is the surrounding structure, and the difficulty is specific rather than general.

Permissions describe people. Existing role models answer what a user may do. Extending them to software means either giving agents user accounts — which destroys the audit trail — or building a parallel model, which is where conflicting duties hide.
Business logic lives in the UI. In screen-driven systems, validation and workflow frequently sit in the interface layer. An agent bypassing the screen bypasses the rules, which is why some retrofits are quietly unsafe.
The data model is per-module. Context assembly across modules is an integration project rather than a query, so agents get thin context and behave accordingly.
Audit logs record CRUD. Adding model version, confidence, and policy to an existing schema is straightforward; making historic entries comparable is not.

None of these are insurmountable and we would not bet on the gap lasting indefinitely. They are the reason it takes longer than a release cycle, and the reason "AI-native" describes something real rather than being purely positional.

Judge any vendor on this

Ask where the permission check happens, what the interface between the model and the ledger is, and whether business rules can be bypassed by not going through a screen. The answers are architectural and hard to fake in a conversation.

Questions

What engineers ask.

Which models do you use?

The inference layer is abstracted and the providers are published in the sub-processor list. Model choice is a configuration and an evaluation question rather than an architectural one, which is deliberate.

What happens during a provider outage?

Agent workflows queue; the ledger, close, reporting, and integrations are unaffected. The system degrades to a conventional ERP with idle agents rather than failing.

Is the policy engine extensible?

Policies are authored through the builder rather than through code. We have deliberately not exposed arbitrary code execution in the enforcement path, because a policy engine you can script is a policy engine you can subvert.

How do you test the boundary?

Property-based tests over the ledger invariants, plus adversarial tests that attempt to construct proposals violating period state, balance, and authority. Those run in CI on every change.

Can we build our own agents on this?

Yes — custom agents use the same tools, policy engine, and audit schema, so a bespoke agent is governed identically rather than being an exception to your controls.

What has to be true for software to initiate financial work

Technical deep dive