Is an agentic operating layer a new ERP?

No. It sits around the systems of record you already use and coordinates work across them under defined permissions. The ERP, CRM or project platform remains authoritative for its own data.

Does it let the company run itself?

No. It automates defined paths within one operating domain, and people keep authority over consequential decisions. Wider scope, if any, is expanded domain by domain after results are accepted.

Is it the same as an AI agent or a chatbot?

No. An agent or chatbot may be one component. The layer is the surrounding structure: routing, rules, permissions, evidence, exception handling and audit.

What should we ask a vendor who offers one?

What it can read and write, how each action is limited and logged, how a person overrides it, what happens when it fails, who owns it afterwards and how you would leave.

What is an agentic operating layer?

The phrase sounds large. The idea is modest and specific. An agentic operating layer is a coordinating structure around one operating domain, for example customer-to-cash, that routes work between your existing systems, deterministic rules, bounded AI and accountable people, and records what happened and why.

It is not a new ERP or a chatbot, and it does not run the company on its own. This article defines the concept and its boundaries, so that a CIO, a security stakeholder and a process owner can judge any proposal that uses the term, including ours. It does not decide how to source the components, which is covered in configure, buy, integrate or build, and it does not rule on which steps need AI, which is covered in AI or deterministic automation.

A working definition

An agentic operating layer is:

Domain-bound. It covers a defined operating domain with named owners, not the whole company at once.
Built around systems of record. Your ERP, CRM, project platform and document stores stay authoritative for their own data. The layer reads and writes through permitted interfaces.
Mixed-logic. Rules handle known paths, AI interprets ambiguous information within limits, and people approve consequential decisions.
Inspectable. Its permissions, evidence and limits can be read and tested by IT, security and the process owner.
Operated. It has monitoring, exception queues, incident ownership, change control and a handover plan.

If any of these is missing, you have a different thing: a script, a chatbot, a point tool or an unmanaged agent.

Why “agentic”

Microsoft’s agent guidance, which is vendor documentation, describes agents as a fit for tasks that need multistep decisions, use many tools or systems, or need adaptive behavior when inputs are incomplete. It also says that structured, predictable tasks do not need an agent. An operating domain usually contains both kinds of work, which is why a layer is mixed-logic rather than “all agent”. “Agentic” here means that some components can choose a next step within limits. It does not mean the whole layer is unconstrained.

The same guidance notes that a design with several cooperating agents is the starting point where a use case crosses security and compliance boundaries or involves multiple teams. That is a design choice, not a virtue; more agents mean more interfaces to control.

The components

This is a reference design, proposed by Sembium, not a description of a finished product.

The components
Component	Job	What to check
Systems of record	Hold authoritative data and enforce their own rules.	Which system is authoritative for each data item?
Connectors and service identities	Read and write through supported interfaces.	Least privilege per action; no shared admin accounts; credentials stored and rotated safely.
Case and state tracking	Keep each unit of work (a dispute, an RFI) with its status and history.	Can you see where every case is and who holds it?
Deterministic rules	Validate, calculate, route and change state on known paths.	Are rules versioned and tested against agreed examples?
Bounded AI steps	Read, classify, compare, retrieve and draft for ambiguous inputs.	Defined input, output and allowed actions; measured accuracy on real examples.
Human decision points	Approve consequential actions and handle exceptions.	Named role, authority limit, evidence shown with the request.
Exception queue	Hold anything outside rule or confidence boundaries.	Owner, age limit, escalation rule.
Evidence and audit trail	Record inputs, decisions, approvals and writes.	Can you reconstruct who or what decided, on what basis, with what result?
Monitoring and cost limits	Watch accuracy, drift, failures, latency and spend.	Alert thresholds and an on-call owner.
Rollback and kill switch	Undo or pause a change and stop automated action.	Tested, not merely documented.

What it is not

What it is not
It is not	Because
A replacement ERP, CRM or project system	It coordinates around them; replacement is a separate decision made only if evidence supports it.
A chatbot on top of documents	A chat interface can be one entry point, but the layer acts on a process with permissions and state.
A blanket permission to act	Each action is allowed explicitly, limited and logged.
A company that runs itself	It automates defined paths in one domain; consequential decisions stay with accountable people.
A security boundary by itself	Its controls complement, and do not replace, the permission models of the underlying systems.
A promised outcome	Value must be measured against a baseline; none is assumed.

Authority and the human role

The sharpest design question is who may do what. A useful test is to list every action the layer can perform and assign each one of four levels.

Authority and the human role
Level	Meaning	Example (synthetic)
Read	Look up information.	Fetch an order record.
Propose	Prepare a recommendation with evidence.	Suggest a dispute category.
Act within limit	Execute a reversible, bounded step automatically.	Send a standard acknowledgement.
Act with approval	Execute only after a named person approves.	Issue a credit note over a set amount.

Anything that cannot be rolled back, or whose consequences are material, belongs at the last level or is excluded. NIST’s generative AI profile expects human oversight roles to be recorded in AI system inventory entries and expects post-deployment monitoring that includes appeal and override, incident response, recovery and change management. A layer that cannot show those is incomplete, whatever its demonstration looks like.

A synthetic walk-through

The following is illustrative and invented; it describes no client.

A company runs customer-to-cash across an ERP, a document store and an email inbox. A customer disputes an invoice.

The layer opens a case, links it to the invoice by exact reference and sets its status. (rules)
It reads the message and classifies the reason; the result is stored with the evidence it used. (bounded AI)
It checks delivery evidence and contract terms through read-only connectors. (rules and retrieval)
It drafts a recommended resolution. (bounded AI, propose level)
The amount exceeds the agreed limit, so the case goes to a named credit controller with the evidence attached. (human decision)
After approval, the layer writes the credit note through a service identity limited to that action, logs the write, and notifies the customer. (rules, act with approval)
A case it cannot classify, or whose connector fails, lands in the exception queue with an owner and an age limit.

At no point does the layer replace the ERP, and at no point does AI alone commit a material change.

Failure modes

Failure modes
Failure mode	How it shows up	Safeguard
Scope creep to “everything”	The layer is stretched across domains before one works.	Domain-by-domain expansion after accepted results.
Over-broad permissions	A component can write more than its job requires.	Per-action permissions and limits; periodic access review.
Silent connector failure	Data goes stale; decisions use old information.	Health checks, freshness indicators and alerts.
Rubber-stamp approvals	People approve without reading.	Show evidence, sample-check approvals, track overrides.
Duplicate or conflicting actions	Two paths update the same record.	Idempotent writes, state checks and a single owner per record type.
Injection through documents	Content in an email tries to steer the AI.	Treat document content as data; restrict tools; validate outputs against records before acting.
No kill switch	A faulty release keeps acting.	Tested pause, rollback and manual fallback procedures.
Orphaned system	The builder leaves; nobody can change it.	Documentation, tests, handover plan and a named owner.
Compliance assumed	A rule or regulation is treated as satisfied by default.	Assess applicability per case with qualified legal advice.

On the last point: the European Commission’s AI Act page states that the Act became generally applicable on 2 August 2026, with phased exceptions for some obligations. Whether and how it applies to a given layer depends on its role, use and geography. That is a question for legal review, not an assumption in either direction.

Questions to ask of any proposal

Which domain, which systems of record, which owners?
What can each component read, propose and do, and under which limit?
Where are the human decision points and what authority does each have?
What happens when a connector, a model or a rule fails?
How are actions logged and how would you reconstruct a decision?
How is a change rolled back and the layer paused?
Who owns monitoring, incidents and change control after handover?
How would you leave, with your data, rules and documentation?

What this does not prove

This article defines a concept and a proposed reference design. It does not show that a layer improves cost, speed, quality or cash in any particular business, and the cited guidance comes from a vendor, a voluntary standard and an official policy page, each with its own limits. The walk-through is synthetic. A real design needs your systems, permissions, exceptions and acceptance tests, and a review of regulatory applicability.

Where Sembium fits

Sembium designs and builds this kind of layer as part of a whole-operation program: analysis, redesign, integration, adoption, measurement and handover, with rules, bounded AI and accountable people. See the approach for the stages and controls, and customer-to-cash for one operating domain where the pattern applies.

Got a bottleneck that costs you $1M or more, and you want it solved? Book the 30-minute bottleneck call. Bring one bottleneck. You leave with one practical recommendation and a clear answer on fit.