Most enterprise AI today stops at suggestion. It drafts the email, summarises the ticket, proposes the journal entry, and then hands the work back to a person who re-enters it somewhere else. That is useful, but it is not operations. The moment software starts acting on its own behalf, a different question matters more than how well the model reasons: where does the action land, and who can prove it happened?

The record is where the state lives

A system of record is the authoritative source for a domain. Not a report, not a copy, not a cache. It is the place where the state of a purchase order, a stock location or a patient encounter legally and operationally lives.

People have always worked against systems of record. When a buyer approves a purchase order, that approval is written to the procurement record, stamped with who did it and when, and checked against the same rules every time. Nobody has to trust the buyer's memory of what they did.

Agents need exactly the same thing, for exactly the same reason. If an agent approves a purchase order, that approval has to exist in the same ledger a person's approval would. Otherwise you have automation you cannot audit.

What goes wrong without one

There are two common shortcuts, and both break in the failure case.

The side channel. An agent works through an integration bus or a scripting layer bolted to the side of an existing ERP. It gets things done, but usually without the permission model that governs the UI. The automation happens off the books and has to be reconciled later, by hand.

The chatbot on top. An assistant produces text and leaves the system unchanged. When it is wrong it wastes your time. When you wire it to act, it inherits whatever access the integration has, which is almost always more than the task needs.

In both cases the question an auditor will eventually ask, who or what changed this, and were they allowed to?, has no clean answer.

One surface for people and agents

The approach behind the Splenta Agentic Enterprise modules is to make the machine-operable surface and the human surface the same surface. They share one authorization model and one audit trail.

That has a few practical consequences:

  • An agent cannot reach anything a correspondingly scoped person could not. It acts under a token that grants exactly the scopes the task needs, issued by ICE, the shared authorization server for the whole family.
  • Human and agent actions carry the same weight in the audit trail. Every write records a before-and-after snapshot, attributed to whoever, or whatever, made it.
  • Denied actions are recorded too. When an agent tries something outside its scope, the refusal is part of the record, not a silent failure in a log nobody reads.

The record does not trust the agent. It trusts the authorization. That separation is what lets the safety property hold regardless of how the agent reasons.

What this changes for the team

The point is not to remove people from the loop. It is to put them on the part of the loop that needs them. Most operational work is mechanical: in-policy orders that just need to advance, receipts that need to be posted, invoices that match their order. A small remainder carries genuine judgment or liability.

When agents operate on the record, they can clear the first category and prepare the second, with the evidence attached, instead of quietly absorbing both. The team's attention goes to the handful of items that need it, and every routine action is still one click away from a full explanation.

If you want to see how this plays out in a specific domain, the procurement use cases walk through purchase order triage, goods receipt reconciliation and invoice matching on the SCM record.