The agentic company: an eight-layer architecture and the decisions to take before the interface

In short. The diagrams enterprise software vendors use to present their artificial intelligence offering all draw the same tower: systems of record, context, agents, a conversational interface. They leave open the question of who owns the lower layers, where cost, confidentiality and the ability to switch vendor are decided. The architecture of the agentic company breaks down into eight layers, each with a decision to take before building it, and it is designed from the bottom up, with the AI Rating model and the decision gates as measurement tools.

The vendors' common diagram

Over the past few months almost every large enterprise software vendor has published its own diagram of its AI offering, from the most widely used CRM to the office suite installed on nearly every laptop, through to vertical platforms for logistics and distribution. Product names change from one quarter to the next, sometimes from one month to the next, and anyone following the announcements struggles to tell what is available from what has only been presented. Placed side by side, though, the diagrams draw the same tower.

At the bottom sit the systems where the company's truth lives. Above them, a layer turns data into context a language model can read, and higher up the agents work, reasoning and acting. At the top a conversational interface collects people's questions and their approvals. Around everything appears, almost always as a frame and almost never as a floor, the set of services nobody buys separately that holds the structure together: permissions, security, action tracking, evaluation of results.

The tower describes reasonably well where companies are heading. It leaves out a question that those who draw it prefer to take for granted, namely who owns the lower layers: where the model runs, where the context is assembled, who can read the log of what the agents have done. Operating cost, data confidentiality and the ability to change vendor without rebuilding everything all depend on that question.

The issue bears directly on the gap measured by the Artificial Intelligence Observatory of Politecnico di Milano (February 2026): 71% of large Italian companies have active AI projects, 9% have structured governance. An agentic architecture bought whole, with no decisions on the lower layers, widens that gap, because it moves outside the company exactly the parts governance should oversee.

The map of the eight layers

The abstract version of the tower, valid for any organisation and independent of brands, has eight layers. They are read from the bottom up because that is the order in which they should be designed, while most projects start from the top, with the choice of the assistant to roll out to employees or of the model to adopt.

Layer	What it contains	Question to ask before building it
0. Compute and models	where inference runs: cloud, company servers, workstations	which data can reach which model?
1. Systems of record	ERP, CRM, document archives, warehouse	for each piece of data, which is the single owning system?
2. Domain logic	objects, rules, approval flows, permissions	which rules today live only in someone's head?
3. Context	entity identity, ontology, agent memory, vectorised text	what does the information mean, and who decides?
4. Agency	reasoning, planning, specialised agents, execution loops	which tasks are delegated, and with which stop condition?
5. Harness	governance, security, observability, evaluation, model choice	what can an agent do without asking, and who checks it?
6. Headless exposure	APIs, MCP servers, command line, skills	which contract does the layer above see?
7. Interface	commercial assistants, company chat, voice, in-house apps	where do people already work?

Layer 5 carries a number for ease of reading. In the diagram it should be read as a frame around layers 3 and 4, because it governs context and agents rather than resting on top of them.

Layer 0: compute and models

This is the layer nobody buys explicitly and everybody pays for. In the vendors' towers it coincides with their cloud and barely appears in the drawings, yet it decides where every sentence an agent reads ends up and how much reading it costs. The decision concerns where inference takes place and, before that, the rule that assigns to each class of data the models authorised to process it.

Layer 1: systems of record

Companies have known these systems for thirty years. With the arrival of agents they ask for a single rule, the hardest one to keep: every piece of data has one owning system, and all the others reference it instead of copying it. A customer record duplicated in two systems produces, within a few months, two diverging versions of the same information, and a model that reads both picks at random which one to report.

Layer 2: domain logic

Here data becomes process. An order has a status and a discount above a certain threshold requires a signature. Part of these rules lives in the code of the business systems, part in procedures written years ago, and a sizeable share only in the experience of those who have done the job for a long time. The data model is a theory of the company, with the simplifications chosen by whoever designed it, perhaps to make cost accounting add up, and agents inherit it as it is.

Layer 3: context

In this layer the company tells the model what its information means. The word "customer" in finance means someone with an open invoice, in sales someone with an active opportunity; two different names may refer to the same person; a decision taken at a meeting in March may supersede the one from January. The layer includes the ontology, identity resolution, the agents' long-term memory and the text of documents made searchable with semantic retrieval techniques.

Layer 4: agency

This is the part that plans, chooses the tools, executes and checks the result, in a loop that repeats until a stop condition. The decision to take concerns the degree of delegation, which ZeroFive.AI describes on three levels. At the AI-assisted level the person does the work and AI helps at the margins, at the AI-first level AI does the work and a person reviews every output, at the AI-native level AI runs the whole process and people write policies and constraints. The highest level is an option to assess process by process: acquisitions and litigation remain activities where full delegation makes no sense.

Layer 5: harness

It covers everything an agent in production needs that is not the model: the permissions it acts with, the rules that set when it must ask, the action log, automated checks on results, the choice of model by data class. In turnkey offerings it is the least mature layer, and the one a company has the most interest in designing in house.

Layer 6: headless exposure

It makes what lies underneath available without a screen, through APIs, MCP servers, the command line and shared skills. It defines the contract the upper layers see: which operations can be requested, with which permissions, with which guarantees on the result.

Layer 7: interface

Thanks to layers 5 and 6 it can be almost anything, from a commercial assistant to an in-house application, by way of company chat and voice. The guiding question is where people already work, because an interface that forces them to change habits starts with an adoption cost no model can offset.

Common mistakes and signs of maturity

Layer	Common mistake	Sign of maturity
0. Compute and models	all data sent to the same external model for convenience	a written rule assigning permitted models to each data class
1. Systems of record	duplicated master data aligned by hand	a single owner for each entity, referenced by the other systems
2. Domain logic	rules known only to those who do the work	written, versioned rules with an accountable owner
3. Context	meaning left to the model's interpretation	a minimal ontology with types, relations and an arbiter for conflicting sources
4. Agency	agents with no delegation level and no stop condition	delegation level declared per process, confidence thresholds
5. Harness	technical accounts with broad permissions, no log	three-tier permissions, human approval on writes, a readable log
6. Headless exposure	logic locked in the prompts and agents of a single product	MCP servers and shared skills operating with the real person's permissions
7. Interface	interface chosen first, before the layers that feed it	several interfaces on top of the same contract

The interface as a contract

For twenty years enterprise software coincided with its screen. Companies bought licences per seat and trained people on the interface, and the vendor kept the customer through visual habit, because changing CRM meant retraining hundreds of people to click in different places. The value sat in the interface, and the underlying data was the price of using it.

In the agentic company the relationship is reversed. People work in the assistant they prefer, in company chat or by voice while on the move, and ask the assistant to fetch information where it lives and act on their behalf. The interface multiplies and thins out, becoming a surface that changes with the moment and the device, and in the coming years with physical space too. What a company has to design for its agents is a contract, with permitted operations, permissions and guarantees on the result.

The Model Context Protocol (MCP) is today the most widespread form of that contract, and the reason layer 6 has become something a mid-sized company can design without a large development team. An MCP server exposes a system's tools to any compatible client, and the same server serves the employee using a commercial assistant and the overnight agent preparing Monday's reports. One rule should be set from the start: the model always operates with the real permissions of the person using it, never with a technical account with full access.

Dependence on a vendor can be measured with a simple test, worth raising in the first meetings: if employees switched assistant tomorrow, how much work would have to be redone? When the logic lives in prompts saved inside a vendor's product, in its memories and in its preconfigured agents, almost everything has to be redone. If it lives in layers 3 to 6, the switch comes down to configuration, and choosing the assistant becomes once again a decision about cost and confidentiality.

Context and harness in production

In a demo an agent answers a question about the customer portfolio in a few seconds, drafts an offer and proposes the next commercial step. In production the same agent has to know that "customer" means different things in different departments, must not read margins if the person querying it is not authorised to see them, has to leave a trace of what it did and has to stop when confidence is low. These requirements live in layers 3 and 5, which do not appear in demos and absorb most of the time of a serious project.

Meaning decided before the model

A model connected to data without declared types and relations rebuilds the meaning of information on its own, each time in a slightly different way, and two answers to the same question a week apart stop matching. An operational ontology fixes object types, the relations between them and the actions permitted on each. It also has an economic effect finance departments grasp immediately, because it reduces the tokens an agent spends getting its bearings. The same principle applies to the context window, where superfluous material competes with what is needed instead of being discarded. The role of ontologies as infrastructure is covered in a dedicated article.

The four families of harness rules

In at least one of the most ambitious announcements of autumn 2026, governance and security appear among the platform's capabilities with a note that they are partly still to be built. The part of the system that decides what an agent can do without asking, who checks it and what remains on record afterwards is the least mature in turnkey offerings. In the ZeroFive.AI method it is written before the agents, with four families of rules.

• Three-tier tool permissions: denied, allowed with confirmation, allowed without confirmation. Every tool starts at the most restrictive tier and moves up only by explicit decision.
• Human approval of writes: the model proposes, a person signs off, and no information enters company memory without an owner identified by name.
• Deterministic checks: whatever can be verified by a script is taken away from the model's judgement, from the total of a quote to the validity of a change package.
• Action log: every call leaves a readable line with who requested it, which model executed it and which data left the perimeter.

The harness is also where architecture meets regulation. For high-risk systems, Regulation (EU) 2024/1689 (AI Act) requires automatic recording of events in Article 12 and human oversight in Article 14, obligations that for Annex III systems, after the Digital Omnibus, apply from 2 December 2027. ISO/IEC 42001 in turn requires a management system documenting roles, controls and monitoring. A harness built on the four families of rules produces a good part of the evidence these standards require. This work prepares the organisation for the conformity assessment, which is a legal evaluation, and for ISO/IEC 42001 certification, which accredited bodies issue.

Ownership of the lower layers

Every time an agent works, the context is assembled and sent to the model. That package contains the most valuable distillate a company produces, namely the way it classifies customers and the decisions it has taken along with their reasons. In a tower bought whole, that distillate travels to an external data centre, under the guarantees of the signed contract, at a per-token price that can change at the next price list revision, on models the vendor can withdraw with a few months' notice. These are acceptable conditions for many classes of data, provided they are known before signing, which happens less often than one might think.

Data classification

In the ZeroFive.AI method data sovereignty is decided by data class, with no objection in principle to the cloud.

Class	Examples	Where it can be processed
Open	public research, content drafts, material already published	the most capable model available, external included
Internal	operational documents, internal communications, process data	external vendors with adequate contractual guarantees on retention, use for training and location
Confidential	confidential financial data, trade secrets, special categories of personal data	a model running inside the perimeter, or an anonymisation step before sending

For a long time the third class had few practical solutions, because open models were far behind commercial ones and running them required skills a typical company did not have. Today layer 0 can be owned. Open source local inference projects such as LocalAI or vLLM run open models on company hardware, from the server room to a department workstation, and expose a programming interface compatible with that of the main commercial vendors. The upper layers do not notice the change, and a company can run a local model alongside a commercial one and route calls by data class without rewriting context and agents.

The hybrid architecture

The resulting agentic company is almost always hybrid. Compared with the tower bought whole, what changes is where the core sits: ontology, memory, rules and logs stay inside the company, and the model becomes a reader that can be replaced or switched off without losing anything. Changing vendor stops being a migration project and becomes a configuration change.

The eight layers in the AI Rating model

The ZeroFive.AI AI Rating model measures maturity on four dimensions, with a scale from 0 to 5, classes from A to D and non-compensable critical gates. Dimensions and layers sit on different planes, yet each dimension mainly observes certain layers, and reading them together shows where an investment produces effects and where it stalls.

Dimension	Layers mainly observed	What it reveals about the agentic architecture
AI Readiness	0, 1, 2, 3	data classification, ownership of systems of record, explicit rules, ontology
AI Delivery	4, 6	ability to put agents into operation, integration with systems, monitoring
AI Risk	5, with effects on 0	permissions, approvals, action log, model choice by data class
AI Confidence	7	actual adoption by people, trust in outputs, commitment from the top

The non-compensable nature of the gates weighs heavily on this reading. A missing harness caps the class even when agents are technically sophisticated, and a high score on AI Delivery does not offset the lack of an owner for the data. Risk is measured during the diagnosis, before use cases are selected, because a governance issue found once the system is live costs far more than one spotted on the map. A self-assessment produces an estimate, while class A is reserved for assessments verified through a structured interview.

Decision gates along the stack

Decisions on the architecture pass through six gates, which the client crosses before spending on the next phase. Each one questions different layers of the tower.

Gate	Question	Layers involved and criterion
G0 Legitimacy	Does the problem deserve an AI solution?	2 and 4: written comparison with the non-AI alternative, often a script on domain logic
G1 Readiness	Is the organisation ready to support the initiative?	0 to 3: organisational check, valid for all initiatives until the annual review
G2 Validation	Did the prototype prove what it had to?	3 and 4 on a narrow scope, with a falsifiable hypothesis declared before the start
G3 Authorisation	Is the risk governed?	4 and 5: autonomy level declared and consistent with the risk class
G4 Scale	Is operation sustainable over time?	1, 5 and 6: named owner, rollback procedure, documented exposed contract
G5 Oversight	Does the system still do what it was approved for?	5 and 7: action log and adoption measured in the field

At G0 no use case enters the portfolio without the comparison with the alternative that does not use AI, filled in before the answer is known. In a share of cases a well-written script solves the same problem at a fraction of the cost, and that outcome is worth as much as a green light. At G2 validation takes place through rapid prototypes on real data in the protot.ai prototyping unit, before the company commits budget to production.

The bottom-up path

Requests reaching an AI consultancy almost always start at the top of the tower: which assistant to buy, or how to connect the CRM to company chat. The first piece of work is to set the tower back on its feet and draw, with the team, the map of the eight layers as they stand today. For each layer the team records the owner, the contract exposed to the layer above and whether it could be replaced without touching the others.

The maps that emerge tend to look alike. Systems of record exist and work, domain logic sits half in software and half in people, context and harness are missing, and the interface has already been bought by someone. From there the path climbs from the bottom, in this order.

1. Classification of data into the three classes, which sets what can be done at layer 0 and which models may read what.
2. One owning system for each piece of data and a minimal ontology, with object types, relations and a criterion for deciding when two sources contradict each other.
3. A harness written before any agent goes into production, with permissions, approvals, automated checks and an action log.
4. Exposure of systems through MCP servers with people's real permissions, and shared skills that make every assistant speak the same company language.
5. Choice of interface, often more than one, based on where people already work.

The platform ZeroFive.AI uses to manage its clients' projects already applies many of these rules, from one owning system per piece of data to human approval of the proposals generated by agents, and it connects to assistants through MCP. It is the case we use in the classroom and in first meetings, because it shows how things work in practice before a company decides whether to build its own system.

Skills to govern the stack

The architecture works only if the company has people able to reason about it. ZeroFive.AI's AI Training programmes are built on four disciplines, each tied to a zone of the tower: prompt engineering for the interface, context engineering for the context layer, loop engineering for the agents and harness engineering for the frame that governs them.

A company that buys the stack without anyone able to work on these four zones gets a system that works as long as conditions stay as they were at the start. When a process, a vendor or a regulation changes, nobody knows how to correct it, and nobody knows how to push it towards uses more advanced than those planned at the time of purchase.

Foundations and interface in the years ahead

Over the next two years the interface will change several times. Today's assistants will be renamed, merged or replaced by others not yet known, and part of the work will move from chat to voice and to physical environments. A company that has built its context, its harness and the exposure of its systems in house will change assistant as easily as people change browser today, choosing each time the model suited to the class of data at hand.

Whoever has bought the tower whole will negotiate every year with the vendor the price of access to their own context, that is, to the most accurate description of themselves they have ever produced. Vendors will draw the tower, and it is legitimate that they do. The foundations, however, each company will have to decide whether to keep in house or rent, and the map of the eight layers is the first document on which to take that decision.

The rule for deciding what to entrust to the model and what to deterministic rules is in probabilistic and deterministic. The choice of channel through which context reaches the model is in RAG or connectors, and the way AI connects to company data is in why you need an AI Company OS.

The map is built with the people who really know the systems, and its first version already shows which past investments can be reused and which will have to be redone. To start it you can book an assessment session or write to hello@zerofive.ai.