Four layers and one perimeter: what to decide before switching on an AI agent

In short. A company that wants to bring in AI agents has two questions to answer before choosing any technology: which process to start from, and how much the agent may do without asking. The diagrams doing the rounds help with the first, drawing four layers: the systems that record transactions, the systems where people work, analytics and models, and on top the agents, acting through everything below. The structure is useful because it does not ask anyone to replace the existing stack. Two promises that often come with it need correcting, though: authorisation is not a tick box in a chat, and an agent that writes to systems cannot be switched off back to where you started. Above the four layers you need a delegation perimeter, declared process by process, and alongside them a governance band that runs through all of them.

Which process would you hand to an AI agent first, and with how much autonomy? Most of the companies we meet answer with a list of use cases collected in a workshop rather than with a criterion. The agent then starts where the enthusiasm is, instead of where the data is reliable, a mistake is cheap and a person checks its work.

Answering with a criterion requires a map of what is already there. Agents do not arrive in an empty company: above the ERP and the CRM sit the tools people work in every day, and above those the dashboards, forecasts and models someone built over the years. An agent rests on all of this and acts through it, so the question of what to switch on first is really a question about how solid the layers underneath are.

A diagram doing the rounds these days organises that map into four layers and describes well how a company should take on agents. We redrew it the way we work on client projects, keeping the four layers and changing what sits above and beside them: the perimeter that sets how much an agent may do on its own, and the governance that measures each layer before launch.

The four layers in the diagram

At the bottom sit the systems of record: ERP, CRM, order management, MES, the data platform. They hold the transactions and are the source from which you reconstruct what happened. Above them are the systems people work in every day, from planning and procurement to logistics and supplier portals. The third layer gathers dashboards, forecasts, anomaly scores and the models already in use.

The fourth layer is the new one. Agents read the other three, hold a context that spans functions and act through the existing systems, so that each of their decisions lands in the ERP like any other transaction. People reach them through a conversational interface, where they ask questions, see options and authorise the action.

The underlying idea is sound. Building agents on top of the stack you already have recovers the value of past investments in analytics and data, and nobody has to change tools. We covered who owns the lower layers, and the decisions to take before the interface, in the piece on the agentic company in eight layers. Here we focus on two more operational questions: what happens when an agent is switched off, and who decides how much it can do on its own.

How reversible an agent is

Diagrams of this kind present the fourth layer as a low-risk choice: if it does not work, you switch it off and the company is roughly back where it was. For an agent that reads and summarises, that is true. For one that writes to the systems of record, the sentence only describes the switch, because the actions already taken stay where they were left.

Type of action	What remains after switch-off	What you need before switching it on
Reading and summarising	Nothing of consequence	Read-only permissions
Proposal approved by a person	The approved action, with its sign-off	A log of who approved what
Writing to an ERP or operational system	Moved orders, rescheduled supplies, changed records	A tested rollback and a log of every action
External communication	Messages received by customers or suppliers, commitments made	Explicit thresholds and human approval above them

Switching off and undoing are two different operations. Switching off stops future actions. Undoing requires knowing which actions were taken, in what order, with what effects on other systems, and having a procedure to bring them back. That procedure has to be written and tested in a test environment before production, because the moment you need it is also the moment with the least time to invent it.

The part of an error that leaves the company cannot be undone at all. An order confirmation sent to a supplier or a message that went out to a customer needs a correction and often an explanation, and the cost of that error has to be estimated when the level of autonomy is decided, not afterwards.

The delegation perimeter above the agents

In the original diagram, authorisation is a box inside the conversational interface, next to "ask questions" and "see options". It works for a single action and leaves open the question that comes first: which actions can the agent take without asking, and who decided that.

In place of the box we put a delegation perimeter, declared process by process using the three delegation levels we use in assessments.

Level	Who produces the output	Who checks it	What gets declared
AI-assisted	The person	The person	The tools made available
AI-first	The model	A person, on every output	Who reviews and against which criteria
AI-native	The model, end to end	Written rules and controls	Thresholds, exceptions, stop conditions

The perimeter is signed by whoever runs the company, because deciding how much work to hand to a machine in a process that touches customers, suppliers or accounts is a business choice with consequences that no technical function can take on alone. AI-native is not always the goal: some decisions, such as an acquisition or the handling of litigation, stay human by choice, and declaring that is as much part of the perimeter as the list of what gets delegated.

The perimeter then becomes technical constraints. The procedures an agent may run, with their limits, are the subject of the piece on skills and agentic planning: a limit written into the model's instructions remains a request, while a limit enforced by the system that exposes the tool is a constraint.

The AI Rating dimensions across the four layers

In the original diagrams, the three lower layers nearly always carry the same note, "no changes needed". That is true of the architecture, since those systems stay where they are. For the decision to switch on an agent they are the first thing to look at, because an agent is worth as much as the data it starts from, the models it uses and the trust of the people who receive its work.

That is why in the redrawn diagram each layer carries the AI Rating dimension we use to measure it before launch.

Layer	The question before switching on an agent	Dimension
Agents	Is the declared autonomy consistent with the use case's risk class?	AI Risk, gate G3
Analytics	Are the models and forecasts in operation, monitored and kept up to date?	AI Delivery
Work	Do the people receiving the agent's work actually use it, and is that measured?	AI Confidence
Record	Is the data reliable, with a single source of truth?	AI Readiness

The fourth dimension, AI Risk, does not sit on one layer. In the diagram we drew it as a vertical band running through all of them, with four minimum elements: a log of every agent action, a named owner for every system, a tested rollback procedure and the use case's classification under the AI Act. On ownership we have already argued that no agent should go to production without a named owner, and it is the condition that makes all the others usable.

The gates along the way

At the bottom of the diagram are the six gates of our method, which mark the decisions in an AI initiative from the first question to ongoing oversight in operation. Each has a non-compensable criterion: a high score elsewhere does not make up for it.

Gate	Question	Non-compensable criterion
G0 Legitimacy	Does the problem deserve an AI solution?	A non-AI alternative assessed and ruled out in writing
G1 Readiness	Is the organisation ready to sustain it?	No dimension below threshold
G2 Validation	Did the prototype prove what it had to?	A falsifiable hypothesis declared before launch
G3 Authorisation	Is the risk governed?	Level of autonomy declared and consistent with the risk class
G4 Scale	Is operation sustainable?	Named owner and rollback procedure
G5 Oversight	Does it still do what it was approved for?	Adoption measured, not declared

For an agent the two decisive gates are G3 and G4, because they fall at the moment it leaves the prototype and starts writing to real systems. The delegation perimeter is the substance of G3, reversibility the substance of G4. G0 comes before everything else: a process that can be solved with a rule or an organisational change does not need an agent, and the value case with the non-AI alternative ruled out is the document that shows it.

The mistakes that keep coming back

Treating authorisation as a button is the most frequent one. Approving a single action in chat gives a sense of control and leaves open the question of all the actions the agent takes without showing them, which in a high-volume process are the majority.

Just as common is treating rollback as a property of the system instead of a procedure. Many ERPs let you reverse an entry, few let you reconstruct the chain of effects an agent produced across several systems in an hour of work, and you only find the difference by trying.

The three lower layers get skipped because "they do not change", and an agent ends up running on duplicated data or on forecasts nobody monitors any more. In these cases the agent amplifies a problem that already existed, at a speed it did not have before.

Finally, some assume AI-native as the destination for every process. The right level depends on the cost of the error and on whether it can be undone, and for some processes the correct choice is to stop at AI-first, explicitly and with reasons.

Where to start

The distinction between delegation levels, with the business case for each, is in AI-assisted, AI-first, AI-native. The full reading of the stack, from ownership of the lower layers to the interface, is in the agentic company: an eight-layer architecture.

For an overview of what separates an agent from an assistant there is AI agents in the enterprise, and the service through which we design agents and take them into operation is described on the AI Agents page.

To find out where your four layers stand before switching on an agent, you can start an AI Rating or book an assessment call.