AiStack

Agentic ERP systems of record.

Procurement, commerce, assets and healthcare - each a full system of record that exposes the same operations to people over REST and to agents over MCP. One authorization. One immutable audit trail.

PeopleREST
one coreone authorization
one audit trail
AgentsMCP

every module runs on this one core

The idea

One core, two surfaces.

No forked logic, no bolted-on API, no privileged back door. People and agents reach the same operations through the same authorization - and every change becomes one tamper-proof record, regardless of who made it.

people - REST

POST /po/4471/approve

agents - MCP

po.approve { id: 4471 }

one authorization
ledgerPO-4471APPROVED

In plain terms

What an agentic ERP system of record is for.

Conventional ERP was designed on the assumption that a person types every consequential action. That assumption is what breaks when software starts acting on its own behalf. These modules keep the discipline of a system of record - one authoritative version of what happened - while making every operation something an agent can also perform, under the same controls.

What is a system of record, and why does an agent need one?

A system of record is the authoritative source for a domain: not a report or a copy, but the place where the state legally and operationally lives. Agents need one because autonomy without an authoritative record produces work nobody can verify afterwards. If an agent approves a purchase order, the approval has to exist in the same ledger a person's approval would - otherwise you have automation you cannot audit.

How is this different from bolting AI onto an existing ERP?

Most ERP surfaces were built for human input and expose automation as an afterthought - a scripting layer or an integration bus bolted to the side, usually without the permission model that governs the UI. Here the machine-operable surface and the human surface are the same surface, sharing one authorization model and one audit trail, so an agent cannot reach anything a correspondingly scoped person could not.

How do the modules fit together?

Each module owns one domain: SCM owns procurement, WMS owns physical stock, RMS owns retail and quotes, EAM owns asset lifecycle, FMS owns the books, HMS owns clinical and hospital operations, MFG owns production, TMS owns how goods move, and BOS owns banking exception handling. They share identity and authorization through ICE, so a scope granted in one place means the same thing everywhere and evidence produced in one module is usable in another - warehouse receipts and procurement records reconciling into finance, for example.

Do you have to adopt all of them?

No. Each module is a system of record for its own domain and runs on its own. The compounding benefit is real but incremental: adding a second module means the evidence trail extends across a boundary that usually requires manual reconciliation. Most teams start where the manual reconciliation hurts most.

Where does the agent layer come in?

The modules make operations governable; Arin, PECO and Semorel make them autonomous. A module exposes its actions with scopes attached, and an agent performs them under a token that grants exactly those scopes and nothing more. That separation matters: the record does not trust the agent, it trusts the authorization, so the safety property holds regardless of how the agent reasons.

What stays a human decision?

Anything you say does. The design assumption is that the routine majority of operational work is mechanical and the small remainder carries genuine judgment or liability - approving spend above a threshold, releasing a clinical order, posting to the ledger. Agents are built to clear the first category and prepare the second, not to quietly absorb both.

▷ agentpo.approve→APPROVED

Put people and agents on the same system of record.

We're onboarding design partners replacing back-office systems with ones an agent can operate as safely as a person. Tell us which operation you'd hand over first.