A useful AI assistant can tell a manufacturer that a delivery is late. A more capable agent might find another way to keep the customer’s factory running. But before it can arrange that alternative, it needs answers that intelligence alone cannot provide: whose equipment it may use, which commitments take priority, and who can authorise the change.
Those answers belong to the company. As we give AI more responsibility for acting, the company needs a reliable way to make them available—and enforce them—where the work happens.
This is the problem I am exploring through the Enterprise Agentic Mesh (EAM): an architecture for coordinating AI agents, people and existing business software around a shared business outcome, with explicit rules about what each participant may do.
Consider a fictional manufacturer whose new machine will arrive late. Purchasing searches for the missing part. Logistics looks for faster shipping. The service department has a demonstration machine that could let the customer start production on Monday.
An experienced employee might connect those facts and propose a temporary loan. An agent could help discover the same option. Yet “a machine is available” does not mean “we can promise it to this customer.” An engineer must assess suitability. The equipment owner must approve its use. Transport and installation need arranging. The next customer’s booking must remain protected.
The useful unit of work is therefore larger than any one department’s task: enable production on Monday without creating an unacceptable commitment elsewhere.
EAM gives that work a common structure. In this proposal, it brings together four things:
- Discoverable capabilities. A maintained description of what the company can do: assess suitability, lend equipment, arrange installation. Each capability identifies its owner, required information and conditions of use.
- A shared account of the case. Participants can see the relevant facts, outstanding questions, approvals and confirmed commitments. The case links to the systems that hold the authoritative records. Before a commitment is made, those systems must confirm that the facts and approvals still hold. Access remains limited by role.
- Coordination across participants. An agent can propose a route, an engineer can judge suitability, and existing software can calculate dates and reserve equipment. The work has a responsible owner and a way to escalate or recover when a step fails.
- Checks at the point of action. The system that makes a booking verifies the required approval and current constraints. A persuasive explanation from an agent is insufficient. The result is recorded so later steps can distinguish a proposal from a completed action.
EAM names the agreements that let independently owned capabilities work together across cases: how they describe what they can do, exchange case information and carry authority across their boundaries. “Mesh” describes those connections. It does not require every participant to talk to every other participant, or every task to use an AI agent. A workflow engine may coordinate a particular case. Existing applications can remain responsible for their records and transactions.
This becomes useful when agents repeatedly propose actions across departments and the route cannot be fully specified in advance. The move from answering questions to choosing actions changes what an AI system must know.
For a document assistant, retrieving the equipment policy may be enough to help a person. An agent preparing a loan must also connect that policy to this machine, this booking and this approval. If several agents participate, their work must preserve those connections as facts change. Without shared definitions and authority, applications can develop conflicting versions of how the company works, leaving employees to reconcile the differences.
The next requirement follows from that problem: reusable business capabilities, consistent meanings and explicit authority across systems. EAM is my proposed way of organising them. The need for coordination follows from the work; the choice of this architecture still has to justify its cost.
The broader idea has precedents. McKinsey describes an agentic AI mesh as a modular, distributed architecture for coordinating agents across systems with governed autonomy. My emphasis here is the connection to enterprise architecture: how the company’s intended way of working becomes something those participants can actually use.
Take one condition of the loan: the demonstration machine must return early enough for inspection before its next booking. Someone must define what “early enough” means, who owns that rule and who may approve an exception.
Enterprise architecture can help connect those business decisions to the capabilities and systems they affect. The equipment owner determines the condition. Engineering and platform teams implement it. The booking service enforces it. Architecture makes the relationship traceable, so a policy change can be followed through to its operational consequences.
This is the limited, practical sense in which enterprise architecture becomes a compiler: approved business definitions and decisions are translated into versioned instructions, checks and permissions that software can use.
It is not automatic translation of a strategy document into correct software. Ambiguous intentions still require human decisions. Changes still require implementation, testing and release. The compiler metaphor is useful only if it makes that translation visible and testable.
Suppose the owner increases the inspection allowance from one day to two. The planning constraint and booking check must both be updated. Uncommitted plans must be reassessed before confirmation. Existing commitments need an identified person to resolve any conflict. Editing a policy document alone has not changed the operation.
The relationship is straightforward: enterprise architecture helps define and connect the business meanings, responsibilities and constraints; EAM coordinates work using them; the systems performing actions enforce the relevant conditions. Evidence from that work shows where the definitions or implementation need correction.
An experienced architect could reasonably object that APIs, workflow engines, case management and policy controls already cover much of this. They do. EAM is a proposal for how to connect and govern those capabilities across cases, rather than a claim to have invented their functions. If a stable workflow solves the machine-loan problem reliably, adding a mesh would need another justification.
The stronger case arises when useful responses repeatedly combine capabilities across departments in ways that are difficult to specify in advance. Agents may help discover and propose those combinations. The architectural challenge is to let the route vary while keeping responsibility, permissions and commitments dependable.
The benefit must also survive the first successful case. A one-off loan does not create a maintained company capability. Someone must decide whether to offer it again, fund the work and keep its information and conditions current. A successful exception does not become general permission by repetition.
I would start with one recurring problem that crosses departments, one accountable owner and a small set of existing capabilities. Then test whether a second team can use them, whether a changed rule reaches the action checks, and whether a failed step leaves commitments in a known state.
The economic test is equally concrete: do cases reach a confirmed outcome faster and with less rework, without increasing conflicting commitments—and does that improvement outweigh the cost of maintaining the shared knowledge and controls?
That is the opportunity I see in EAM. As agents gain more freedom to find a route through the company, the company needs a more explicit account of what its routes allow. Enterprise architecture becomes operational when that account guides real decisions—and changes when experience shows it should.
Revised 21 September 2026. EAM is presented here as an architectural proposal. The manufacturing example is fictional and illustrates the argument; it is not evidence of measured benefits.