Agentic Mesh and the Governance That Has to Come With It

Ten days ago, on August 2, the remainder of the EU AI Act became enforceable. From now on, AI systems operating in the EU — including the agent fleets we've been talking about for the last ten weeks — are subject to a regulatory regime that did not exist six months ago. ISO/IEC 42001 certification is becoming a buyer-side requirement. For financial services, DORA's operational resilience rules apply with full force.

This post is about what that does to architecture. Because the story most people are telling — "AI compliance is a legal review" — is wrong. The honest story is that compliance is becoming an architectural constraint on how you build agent systems, and the architecture that responds to it well is the same architecture that responds to scale well. We have a name for that architecture now: the agentic mesh.

What the mesh actually is

The metaphor borrows from service mesh. In a service mesh, you have many services communicating; the mesh is the layer that handles routing, identity, observability, policy, and resilience across all of them, so that individual services don't each have to reinvent it.

In an agentic mesh, you have many agents — possibly hundreds, possibly thousands, across an organization. The mesh is the layer that handles:

• Discovery. Which agents exist. What they can do. How to address them.

• Routing. Which agent handles which kind of request. Often with semantic routing.

• Identity. Agent credentials, scopes, hand-off chains. (Week 9's topic.)

• Shared context. Memory and state that agents can both contribute to and read from.

• Observability. Tracing requests across multiple agents. Cross-agent metrics. System-level audit logging.

• Policy. Constraints on what can be done, by whom, in which contexts. This is where governance lives.

The Extency piece on agentic mesh, published in March, frames the mesh as four layers: agent, orchestration, context, governance. I'd flatten that slightly — discovery, identity, shared state, policy, and observability are the load-bearing pieces, and they cut across rather than stack neatly.

The point is the same. When you have more than five or six agents in production, you stop reinventing each of those concerns per agent. You factor them out into the mesh layer.

Why governance becomes architecture

Here is the part that surprises leaders. Governance — until 2026 — was an after-the-fact activity. Build the system, ship it, then have legal review whether it complies with the relevant regulations. If not, retrofit.

That model breaks under the EU AI Act, for two reasons:

1. The regulations specify obligations on the system in operation, not just at design time. Continuous monitoring. Logging. Incident reporting. Human oversight in specific decision contexts. You cannot retrofit continuous monitoring into a system that wasn't built to be observed.

2. The cost of non-compliance is structural. Article-29 obligations on providers of high-risk AI systems include conformity assessments, technical documentation, post-market monitoring, and incident reporting. Each of these is an engineering requirement, not just a paperwork requirement. If your system can't produce the artifacts, you can't meet the obligation.

ISO/IEC 42001 codifies the management system around AI similarly. DORA, for financial-services-specific systems, layers on operational-resilience obligations: dependency management, third-party risk, incident classification, business-continuity testing. These are not legal requirements applied to your architecture. They are architectural requirements dressed up as legal text.

The architecture that meets them is the mesh, because the mesh is the place where you can implement them uniformly without per-agent retrofitting.

What policy-as-code looks like in the mesh

The mesh-level policy layer is the most important piece for governance. Done well, it does five things:

1. Defines what an agent is authorized to do. Per role, per context. Read-only by default, with elevation paths for write actions.

2. Enforces constraints at the boundary. When an agent calls an MCP server, the mesh's policy engine checks: is this agent allowed to call this tool, on this resource, with these arguments? Block or allow.

3. Logs every decision. Every policy check, allow or deny, becomes an audit log entry. This is what you'll need for the EU AI Act's post-market monitoring obligations.

4. Supports human-in-the-loop. For high-risk actions, the policy can require human approval. This is what the EU AI Act's "human oversight" requirements look like in code.

5. Allows policy to evolve. Policies are version-controlled. Changes go through review. This is how you handle the post-incident "we need this never to happen again" engineering response.

The fact that policy lives in code — readable, diffable, testable — is what makes the governance layer a first-class engineering artifact rather than a Word document.

What I'd build, in order

For a leader standing up the mesh, the sequence I'd recommend:

1. Start when you have three or more agents in production. Below that, the mesh is over-engineering. At three to five, you start to feel the pain. Above five, the mesh is necessary.

2. Build the observability layer first. Distributed tracing. Per-agent logs. Cross-agent traces. You cannot govern what you cannot see. Many teams skip this for six months and regret it the day they have to file an incident report.

3. Identity and policy next. From Week 9 — per-role agent credentials, scoped capabilities, audit-logged actions. Implement at the MCP-server boundary. Wire up to the mesh's policy engine.

4. Discovery and shared context after that. Once you have multiple agents, you need a way for them to find each other and exchange state. This is where the agentic-mesh-specific tooling matters.

5. Then formalize governance. Map your obligations from the EU AI Act, DORA, ISO/IEC 42001, sector-specific regulations. Map each obligation to mesh-level controls. Document. This is what gets you through an audit.

Note that the order matters. Most teams want to start with governance ("what do we need to comply") and back-fill the architecture. That order produces compliance theater. The order I'm recommending produces a system that is observable, controllable, and therefore compliant.

Why the timing matters

The reason this post lands in the August window is deliberate. August 2 is when the EU AI Act's main provisions become enforceable. For models and systems already on the market before August 2, 2025, the compliance deadline is August 2, 2027. That gives organizations a one-year runway to bring legacy systems into compliance.

If you have agent systems in production now, the architectural work to be compliant by August 2027 is starting now, not next year. The mesh is the architecture that gets you there with the least retrofitting.

Vendors are reading this market shift correctly. The enterprise platform pitches I'm seeing in 2026 all foreground governance: every major agent platform now advertises mesh-level controls, audit trail, and EU-AI-Act alignment. The procurement filter has tightened. The vendor that can't answer "show me your compliance posture" is no longer a serious contender.

The bigger pattern

We started this series eleven weeks ago with spec-driven development. We have moved through context, protocols, capability, coordination, expertise, harness, evals, identity, and now governance-as-architecture. The single thread connecting all of it is the bottleneck migrating outward. Prompts to contexts. Contexts to harnesses. Harnesses to meshes. Meshes to governance. Each layer subsumes the last; none of the earlier work goes away.

The agentic mesh is the layer where this stops being "individual engineering work" and becomes "organizational engineering work." It is the point at which AI infrastructure starts looking like the rest of enterprise infrastructure — networks, identity, observability, policy — done well enough to support the next decade of work.

If your team is approaching this transition and wants help mapping obligations onto architecture, that is exactly the engagement my team at Applied Futures does most often these days.

Next week, the closer: world models, continual learning at the harness, and what the next era of this story looks like.