Designing the Agentic Enterprise

What Changes When Software Stops Waiting to Be Told

For thirty years enterprise architecture has been organized around applications. Finance lived in ERP. Sales lived in CRM. People lived in the HR platform. Each application owned its processes, its interface, and its business logic, and employees learned how the company worked by learning where each function lived.

That relationship is inverting. Work is beginning to be organized around outcomes rather than systems, with agents determining what has to happen, which systems hold the information, which rules apply, and which transactions get executed. The applications do not disappear. They become less visible, and less important.

This is not a change to the interface. It is a change to where the architectural centre of gravity sits, and therefore to what an enterprise owns, controls, and can be held accountable for. What follows are six observations on what the agentic enterprise requires. They lead to one conclusion: the hard problem is no longer building agents. It is governing a population of them without accumulating a decade of decisions that cannot be reversed.

1. Applications Are Becoming Infrastructure

• "Applications used to be where the work happened. They will become where the data sits."
• "The system holds the record. It does not hold the context."
• "There is a serious fear that you just become a dumb database."

The application-centric enterprise assumed that business logic and user experience belonged together, inside the system that owned the data. That assumption is being unbundled. Systems of record stay, because the data has to live somewhere with integrity and auditability. Everything above them, the orchestration, the context, the memory, the policy, and the decision, is being pulled into layers that span multiple platforms.

The reason this is happening is more specific than the usual account. Systems of record contain the record and not the reasoning. A CRM holds the numbers and the stage, while the context that determines whether a deal renews sits in email, calendar, chat, and documents. Salespeople do not enter the reasoning, and when they do enter something it is frequently the narrative rather than the situation. Any system that wants to act rather than report needs the context, and the context was never in the system of record. That is what pulls intelligence into a layer above rather than inside.

The strategic consequence is direct. Applications are becoming infrastructure, and infrastructure is not where advantage lives. An enterprise that owns a best-in-class core platform and does not own the layer above it has bought a very expensive database. The vendors understand this precisely, which is why they are building their own agentic front ends rather than conceding the layer. It is worth noting that being an excellent system of record is a legitimate position, and a well-run one is genuinely valuable. It is simply not where differentiation for the enterprise comes from.

Questions:

• If our core applications became invisible to users within three years, which of our current modernization investments would we still make?
• Where does the context that actually drives our decisions live, and is it anywhere near the system of record?
• Who owns the layer above our systems of record today, and is it us, a vendor, or nobody?

2. The Stack Has Settled, and Orchestration Is the Control Point

• "We needed one standard way of interacting with the core, rather than every team building its own."
• "Nobody owns this. It grew."

Enterprises working through this independently are arriving at strikingly similar architectures, which suggests the shape is real rather than fashionable. Beneath everything sit infrastructure and systems of record. Above them, a defined and discoverable interface to each core system, so that every team does not build its own path into it. Then the data layer, then a knowledge and context layer carrying the enterprise ontology, then an intelligence and orchestration layer, and finally the experience surfaces where people and customers meet it.

The interface layer to the core deserves more attention than it gets. Without it, each team that wants to reach the ERP or the CRM builds its own connection, and the enterprise accumulates dozens of undocumented integration paths that nobody can govern or replace. Defining a single owned entry point per core system, and making it discoverable, is unglamorous work that determines whether the layers above it are replaceable later.

Orchestration is where control concentrates. It determines which agents exist, what they can reach, which policies bind them, how cost is allocated, and who is accountable when an outcome is wrong. The most common failure is not a bad choice but the absence of one. Orchestration capability is arriving inside every major platform simultaneously, each competent within its own boundary and blind outside it, so an enterprise can accumulate several orchestration layers without ever deciding to have one. The parallel risk is duplicated spend, paying for embedded AI inside vendor products while also funding an internal layer, with no stated position on which is strategic.

Questions:

• Do we have a defined and owned interface to each core system, or does every team build its own path in?
• How many orchestration layers do we have, and can anyone name the owner of each?
• Where are we paying twice, once inside a vendor product and once in our own layer, and is that deliberate?

3. An Agent Is Not a Feature. It Is an Entity That Needs Governing.

• "We can create agents far faster than we can retire them."
• "You discover one day that it is running a core part of your business."
• "If they built it and they leave, I have just lost ten people."

The governance model most enterprises apply to agents is the one they use for software features: build, test, deploy, monitor for errors. That does not survive contact with entities that hold credentials, take actions, retain context, and interact with each other.

The employee lifecycle is the more useful analogy, and it exposes how much is missing. An agent needs an authenticated identity, entitlements scoped to what it needs rather than what was convenient at build time, a named human owner, a defined retention position on its memory, observability sufficient to reconstruct what it did, and a termination process. Almost nobody has built the last one. Very few enterprises can produce a complete list of the agents running inside them, which is the precondition for governing any of it. Those that have started describe the problem as familiar: individually built tools that quietly become load-bearing, in the same pattern as departmental databases and desktop robotics before them.

Two extensions matter and are not yet standard practice. The first is that the population is not only agents. It is also the applications individuals are now building for themselves, at volume, some of which reach customers before anyone in technology knows they exist. The workable pattern emerging is a sanctioned environment where individuals can build freely against their own credentials and their own data access, with the explicit rule that what they build belongs to them and leaves with them, and anything that needs to cross into shared data, production, or customers goes through a refactoring and accountability gate. The second is key-person risk, which has inverted. The productive individual who builds ten tools is no longer just valuable. They are a concentration of undocumented operational dependency, and when they leave the enterprise loses more than a headcount.

Duplication is the unsolved piece. Nobody has good tooling. The approaches in use are reading system prompts across the estate to cluster similar capabilities, and structured domain-by-domain conversations between technology and business units where each shows the other what they are building. Neither scales well, and both are better than nothing.

Questions:

• Can we produce a complete list of agents and individually built applications running today, with an owner named against each?
• What is our process for retiring an agent, and has it ever been used?
• If our most productive builder resigned this quarter, what would stop working, and would we know before it did?

4. Autonomy Is a Decision the Enterprise Makes, Not a Property of the Model

• "The question is never whether the agent can act. It is whether we have decided it should."
• "Human in the loop is not a policy. It is an answer to a question nobody asked precisely."

The common framing treats autonomy as a capability threshold, where agents become autonomous once models become good enough. That framing produces bad governance. Autonomy is a decision the enterprise makes about a specific task, informed by the consequence of being wrong, the reversibility of the action, the regulatory exposure, and the cost of the human review being demanded.

Blanket human-in-the-loop policies are the symptom of not having made that decision. They are applied uniformly because uniform is easy to write, and they break on contact with volume, at which point they are either quietly circumvented or they cap the value of the deployment. A policy requiring human review of every AI-influenced decision is affordable at conversational pace and unaffordable at transaction pace, and enterprises operating at both have to hold both positions at once.

The workable approach is to classify decisions before deploying agents. Build a decision catalogue, rate each decision by consequence and reversibility, and set the autonomy level, escalation path, logging obligation, and retention period against the classification rather than the technology. It is worth being honest about where the practice currently sits: most production deployment remains assistive to employees, customer-facing autonomy is growing, and agent-to-agent interaction in large enterprises is still largely experimental outside specific well-bounded processes. Designing the classification now is cheap. Retrofitting it across a population already in production is not.

Questions:

• Do we have a decision catalogue, or an autonomy policy applied uniformly because classification was too much work?
• Where is human-in-the-loop acting as a control, and where is it a bottleneck we have stopped examining?
• How much of what we describe as agentic is actually assistive, and would we describe it that way to the board?

5. One-Way Doors and Two-Way Doors

• "Some of these are one-way doors. Most are two-way doors, and we keep treating them the same."
• "The ontology is a one-way door. It takes years, because it is business ontology, not technology."
• "We are staffing against decisions that perish."

The most useful architectural discipline available right now is to sort every decision by how expensive it is to reverse, and then to spend deliberation in proportion.

The one-way doors are consistent across enterprises that have done this work. The data layer. The knowledge and semantic layer. Identity, entitlements, governance, and the registry. And above all the enterprise ontology, which takes years precisely because it is a business artefact rather than a technical one and cannot be bought or accelerated. These deserve slow, senior, expensive decisions. The two-way doors are models, agent frameworks, coding assistants, and user interfaces. These deserve fast decisions, deliberate replaceability, and no emotional attachment.

Most enterprises invert this. They deliberate for months over which model to standardize on, which is a two-way door, and let the ontology and entitlement model accrete by default, which is a one-way door. There is also a hopeful trend worth naming: as abstraction improves, decisions that were one-way doors are becoming two-way ones, including parts of the data layer that were previously monolithic. The posture that follows is what one enterprise called owning the seams. If a capability is bought from a provider who supplies three things, own the joints between those three things, so that any one of them can be unplugged and replaced without renegotiating the others.

Underneath all of this sits the risk that governs the whole paper. Decisions in this environment perish. An enterprise can staff a team, build a customized capability, and find eighteen months later that a general-purpose product does it better and cheaper. That is not an argument against building. It is an argument for building only where the door swings both ways, and for being ruthless about which category each decision actually belongs to.

Questions:

• Which of our current decisions are one-way doors, and are we giving them proportionally more deliberation?
• Do we own the seams between the capabilities we buy, or only the capabilities themselves?
• What have we built in the last eighteen months that a general-purpose product now does better, and did we notice?

6. Every Layer Adds Cost, and Nobody Is Doubling the Budget

• "It is cost layered on cost layered on cost."
• "In three years, when the platforms catch up, will we look back and find we built all of this for nothing?"

The architecture described in this paper has an unresolved economic problem, and it deserves to be stated rather than glossed. The enterprise is still paying for best-in-class applications and the expensive interfaces inside them. Each of those applications is now adding its own agentic layer with its own charge. Above that sits the enterprise's own orchestration and intelligence layer. Above that sit direct relationships with model providers. Each layer is individually defensible. Together they are additive, and no budget is growing to match.

Pricing is moving in the same direction, from per seat toward consumption and then toward outcome or resolution. That is a more honest basis for agentic work, and it removes the predictability that finance functions depend on. The two demands, predictability and optimization, are genuinely in tension, and the resolution most enterprises will need is a contractual ceiling above consumption-based pricing rather than a choice between the two.

The strategic question underneath has no settled answer, and enterprises are splitting on it. One position is patience: the platform vendors are well funded and competent, they will eventually deliver a strong bundled experience, and custom-building agentic surfaces now risks a large write-off later. The other is that this is a rare window in which customization is cheap, and waiting cedes the layer that determines differentiation. The most defensible middle position is to buy the commoditized surfaces, which are the generic assistants for policy, HR, and IT, and to custom-build only the surfaces for roles where the enterprise intends to be differentiated. It is worth remembering that interfaces are stickier than they appear. Users resist changes to a familiar interface even when the replacement is objectively better, which means an owned surface is more durable than its underlying technology suggests.

Questions:

• What is the fully loaded cost of our agentic stack across every layer, and does anyone own that number?
• Which surfaces are we building because we are differentiated there, and which because they were easy to start?
• If we cut one layer out of the stack this year, which one is it, and what breaks?

What This Adds Up To

The agentic enterprise is not a new interface layered on the old architecture. It is a different operating model in which intelligence sits between intent and execution, and the applications underneath become infrastructure.

The technical work is the easier half. Enterprises can build agents now, quickly and cheaply, and most already have more of them than they can name. The unsolved problems are governance and economic: who owns the orchestration layer, how a population of agents and individually built applications is enumerated and retired, which decisions the enterprise has actually decided to delegate rather than defaulted into delegating, and how a stack that adds a charge at every layer stays affordable.

The discipline that matters most is knowing which decisions can be undone. Ontology, identity, entitlements, and the knowledge layer are built once and lived with. Models, frameworks, and interfaces will be replaced repeatedly. Enterprises that deliberate hardest over the things that change fastest will spend the next three years rebuilding.

The defining characteristic of the agentic enterprise will not be how many agents it runs. It will be whether it can explain what they did.

© 2026 Executive Technology Board. All rights reserved. This document is the proprietary work product of the Executive Technology Board and is intended for the use of board members and authorized recipients. No part of this document may be reproduced, distributed, quoted, or republished, in whole or in part, without the prior written consent of the Executive Technology Board.

Executive Technology Board (c)