Executive summary
Enterprise AI is moving from systems that suggest to systems that act. That shift changes the central engineering question. When an agent drafts text, the risk is wasted time. When an agent approves a purchase order or posts a receipt, the risk is an action nobody can explain afterwards.
This paper describes the architecture Splenta uses to make agent actions governable. It rests on three commitments:
- One record. Agents and people act on the same authoritative system of record, through the same surface.
- Scoped authority. Every agent action runs under a token that grants exactly the scopes the task needs, issued by a single authorization server.
- Complete evidence. Every action, including every denied action, lands on an append-only audit trail with a before-and-after snapshot.
Together these make the safety of an agent a property of the system, not of the model's reasoning.
1. The problem with bolted-on automation
Most ERP surfaces were built for human input. Automation arrived later, as an afterthought: a scripting layer, an integration bus, a service account with broad access. These paths typically sit outside the permission model that governs the UI.
That produces three recurring failures:
- Over-privilege. The integration holds far more authority than any single task needs, because scoping it finely was never part of the design.
- Off-the-books changes. Automated changes happen in a side channel and have to be reconciled with the record later.
- Unattributable outcomes. When something goes wrong, the trail shows a service account, not the agent, the policy or the reason.
Adding a more capable model to this setup makes it more useful and more dangerous at the same time.
2. Principle one: the record is the interface
In the Splenta Agentic Enterprise modules, each domain has one system of record: SCM for procurement, WMS for physical stock, RMS for retail and quotes, EAM for asset lifecycle, FMS for the books, HMS for clinical and hospital operations, MFG for production, TMS for transportation and BOS for banking exception handling.
Each module exposes its operations with scopes attached. The workbench a person uses and the surface an agent uses are the same operations, enforcing the same rules. There is no second, more permissive path for automation.
The consequence is simple to state: an agent cannot reach anything a correspondingly scoped person could not.
3. Principle two: authority is brokered, not assumed
All modules share identity and authorization through ICE, a single OAuth 2.1 authorization server for the whole family. A scope granted in one place means the same thing everywhere.
An agent receives a token carrying exactly the scopes for its task. Some steps are withheld from agents by default because they carry liability, for example the approve step on a purchase order, or anything that touches payment. Those remain human decisions unless you deliberately change that.
Because the boundary is enforced by tokens rather than prompt instructions, it holds even when the agent's reasoning is wrong. The record does not trust the agent. It trusts the authorization.
4. Principle three: evidence by construction
Every write produces an immutable before-and-after snapshot attributed to its actor. Human and agent actions carry the same weight in the trail. Denied attempts are recorded as well.
This gives an organisation three things it rarely has with automation:
| Question | Where the answer lives |
|---|---|
| What changed? | The before-and-after snapshot on the record |
| Who or what changed it? | The actor on the audit entry, person or agent |
| Were they allowed to? | The scopes on the token, and any recorded denials |
Evidence produced in one module is usable in another. Warehouse receipts and procurement records can reconcile into finance without a manual re-keying step in between.
5. The agent layer
On top of the records sit three ways of applying autonomy:
- Arin is a single-tenant agent that runs a function continuously. It handles the routine within policy and surfaces only the decisions that need judgment.
- PECO lives inside an application: a plain-language assistant and a visual builder over one shared action model, so a request becomes a confirmed, repeatable automation.
- Semorel is a client-side SDK that lets a trusted agent read what is on screen in your own application and invoke only the actions you authorize, in-session.
All three act through the same scoped authorization and land on the same audit trail.
6. Operating model: autonomy as a setting
Agents run at the level you configure: observe, propose, act with confirmation, or act within policy. Teams typically start in observe mode on one workflow, compare the agent's proposed actions with what people did, and widen the envelope as the quality of its escalations proves itself.
Each change to that envelope is itself a configuration change, recorded like any other.
7. Adoption path
Each module is a system of record for its own domain and runs on its own. Most organisations start where manual reconciliation hurts most, then add a second module when they want the evidence trail to extend across a boundary that currently needs manual work.
Conclusion
The question for enterprise AI is no longer whether agents can do operational work. It is whether that work can be explained, bounded and trusted afterwards. Putting agents on the same record, behind the same authorization, with the same evidence as people, is how Splenta answers it.
To discuss how this applies to your stack, get in touch.
