From One Agent Runtime to Many: What Actually Needs to Stay Centralized

Overview

"Centralized" and "decentralized" get used as if they name one axis. An agent stack has at least three that move independently: where the reasoning runs, how a call reaches a tool and proves whose authority it carries, and how the behaviour is recorded. Treat those as one decision and you end up either locked into one team's framework roadmap, or with a dozen teams reimplementing token audience validation slightly wrong.

Networking settled this argument twenty years before agents existed, and the vocabulary is worth borrowing. NIST SP 800-207 separates a control plane from a data plane, where the control plane is used to "maintain and configure assets; judge, grant, or deny access to resources" while the data plane carries the actual work. Istio draws the same line: a data plane of proxies that "mediate and control all network communication between microservices" and a control plane that "manages and configures the proxies to route traffic". Nobody argues about whether to run five control planes.

So the useful question is not whether to decentralize but which plane a concern belongs to, asked once per concern. The answers do not all point the same way, and the one for connectivity surprises people who came here expecting a case for fragmenting everything.

Where One Runtime Breaks Down

Take an organization that stood up one service to run agents: one framework, one team operating it, one review queue for anything new. It works with two agents built by the team that owns the service. It stops working around the point where five other teams each want an agent, because every new tool, every framework upgrade and every design review now competes for the same calendar. The central team did not get worse at the job. The number of people depending on the job grew faster than the team did.

Name the failure precisely, because the fix people reach for is too broad. The problem was never that one team ran the reasoning loop for everybody. It was that the reasoning loop, the credential path and the audit trail were all queued behind the same team.

There is an arithmetic reason to believe this. Execution work scales with the number of agents, and each agent's is independent of the others. Connectivity work scales with the number of systems you integrate, and it is shared: the second team to need the billing API needs the integration the first team built, with different scopes. Fragmenting the first kind buys throughput. Fragmenting the second buys duplicate work with divergent bugs.

Three Planes, One Decision Each

Here is the decision as a table, because the whole argument is that the rows have different answers.

Table 1 — The same question asked four times, with three different answers.

Connectivity + identity plane --> SaaS and internal APIs Team C agent (visual builder) -/ (one catalog, one vault, -> Operations plane one trust domain) (one log schema, one eval bar) Execution fragments across teams and frameworks. The planes below it do not. -->

Figure 1 — Decentralize where teams need independence. Keep one shared answer where consistency is the point.

The Execution Layer

This is where the reasoning runs: the framework, the prompting approach, whichever pattern the team building the agent thinks fits their task. It churns fastest. Frameworks get replaced, engineers have real opinions about which one suits their workload, and a mandate to use one runtime company-wide ages badly inside two product cycles.

Fragment it without much argument. Let a support team build in whatever their engineers already know, and a data team run something code-first while a business team uses a visual builder. None of that creates the coordination problem that made the central runtime painful, because none of it needs a shared source of truth the way credentials do.

The protocols are built for this. MCP identifies revisions by date rather than by semantic version, "to indicate the last date backwards incompatible changes were made", and the current revision is 2026-07-28. Clients and servers "MAY support multiple protocol versions simultaneously", each request carries its own version in _meta, and a server that cannot honour the requested version answers with an UnsupportedProtocolVersionError listing what it does support. A client that wants to know up front calls server/discover, which servers MUST implement. None of that requires the clients to be the same software, which is the whole point: heterogeneous execution against one connectivity plane is the case the wire format was designed for.

What fragmenting execution does require is that every one of those runtimes plugs into the same layer underneath. Which brings us to the part worth protecting.

The Connectivity Layer

This is the layer most people mean when they say decentralize, and the one we would argue hardest against fragmenting. Connectivity is how an agent finds a tool, authenticates, and gets narrowed to what this call actually needs, which the Agent Access Control Taxonomy files under aact:enforcement-point/gateway.

The concrete argument is the obligation list. In the current MCP authorization spec a protected server "acts as an OAuth 2.1 resource server". It MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728) so clients can discover the authorization server. It MUST validate "that access tokens were issued specifically for them as the intended audience", per RFC 8707. Clients MUST send the resource parameter in both authorization and token requests, and MUST do so "regardless of whether authorization servers support it". And the sharpest line in the document: "MCP servers MUST NOT accept or transit any other tokens." Forwarding an inbound token downstream is forbidden outright, because it produces the confused deputy problem.

Then there is the part almost nobody implements twice correctly. A server that needs a scope the caller does not have SHOULD answer 403 with a challenge naming the scopes it needs:

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                  scope="files:write",
                  resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                  error_description="File write permission required for this operation"

The client is then expected to re-authorize with the union of what it already had and what the challenge asked for, because servers may emit per-operation scopes and a naive client that requests only the new one drops permissions it still needs. The spec also warns against challenging incrementally, since that "forces multiple authorization round-trips for a single operation".

Count what a second implementation costs. Audience validation, issuer validation under RFC 9207 with its four-row truth table, the scope union, retry limits on step-up, and the discipline never to pass a token through. Then multiply by teams. Centralizing connectivity is not control for its own sake. The list is long, mostly invisible when it is wrong, and identical for everyone.

shared connectivity plane plane computes effective scopes = user scopes INTERSECT agent scopes plane calls the MCP server with an audience-bound token server answers 403 insufficient_scope with scope="files:write" plane unions previously granted and challenged scopes, steps up once, retries plane returns the result; the agent never handles the token -->

Figure 2 — One step-up flow, implemented once. This is the sequence that gets subtly wrong five times if every team owns its own connectivity.

Identity and the Trust Domain

Identity is the layer where centralization is not really optional, because the standards define it that way. SPIFFE identifies a workload with a URI of the form spiffe://trust domain/workload identifier, the taxonomy's aact:identity-model/workload-identity, where the trust domain "represents the trust root of a system" and may correspond to an individual, organization, environment or department running its own SPIFFE infrastructure. Identity documents come as X.509 certificates or JWTs, and the Workload API has the property that makes bootstrapping tractable: it "does not require that a calling workload have any knowledge of its own identity, or possess any authentication token when calling the API".

Two trust domains is a decision, not an accident. It means federation before Team A's agent can prove anything to Team B's service, and two answers to "which workload is this". Sometimes right, at an acquisition boundary or a separate regulatory estate. Rarely right because two teams could not agree on a naming scheme.

The second identity in an agent call is the acting user, and it is the one that makes the intersection meaningful. An agent's effective reach should be the overlap of what the agent is allowed to do and what the person it is acting for is allowed to do. That intersection can only be computed somewhere that knows both, which is another way of saying it belongs to the shared plane.

Discovery Is Already Central

Worth noticing: the agent protocols did not decentralize discovery either. A2A publishes an Agent Card at https://{agent-server-domain}/.well-known/agent-card.json, using the path prefix RFC 8615 reserved in 2019 for "well-known locations". Beside that, A2A names curated registries as a primary mechanism, "employed in enterprise environments or public marketplaces, where Agent Cards are often managed by a central registry", with clients querying the registry to find agents by criteria. Direct configuration is the third option, for tightly coupled systems.

MCP's answer has the same shape. The official registry is "a community driven registry service for Model Context Protocol (MCP) servers" that stores metadata rather than hosting anything, organized under verified namespaces such as io.github.owner/name. Ownership has to be proven through GitHub authentication or domain validation, and the API froze at v0.1 in October 2025 while the service stayed in preview.

Two cautions, both from the specs. RFC 8615 says it "does not define a format or media type for the resource located at '/.well-known/', and clients should not expect a resource to exist at that location", so a probe is not an inventory. And MCP warns that serverInfo is "self-reported by the server and is not verified by the protocol", with clients told they SHOULD NOT rely on it for security decisions. Protocol discovery tells you what a cooperating endpoint claims: an input to a catalog, not a substitute for one.

The Operations Layer

Logging faces the same argument, for a related reason. The point of an audit trail is answering a question across every agent at once: which incident happened, whose agent caused it, whether the same failure is showing up elsewhere. Split that across five schemas and you keep the word observability while losing the property that made it useful.

A2A's enterprise guidance points at the same place, recommending distributed tracing through OpenTelemetry with comprehensive logging that carries taskId, sessionId and trace context so a multi-agent call can be followed end to end. Be honest about the state of the shared vocabulary, though: OpenTelemetry moved its generative-AI attributes out of the main semantic-conventions repository into a dedicated one, the old entries are marked deprecated in place, and the well-known values still carry Development stability. A shared schema is the right call. Pin a version of it and expect churn.

Regulation supplies the deadline. The EU AI Act's Article 12 requires high-risk systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system", and Article 26(6) puts the duty on deployers to keep those logs "for a period appropriate to the intended purpose" of at least six months unless other Union or national law says otherwise. The implementation timeline now puts the Annex III high-risk obligations at 2 December 2027. Five incompatible log schemas is not a technical preference at that point. It is an answer you cannot assemble.

Evaluation has the weaker version of the same problem. A team grading its own agent against its own bar grades generously, and two agents measured differently cannot be compared. None of this means a central group owns the dashboards. The schema is shared; the teams producing records stay independent.

What Decentralizing Actually Costs

Both directions cost something, and the pitch usually leaves out this half.

A single central path is genuinely simpler: one review process, one place to look when something breaks. It is also the highest-value target in the estate, and NIST says so plainly. Any administrator with configuration access to the decision rules "may be able to perform unapproved changes or make mistakes that can disrupt enterprise operations", a compromised administrator component "could allow access to resources that would otherwise not be approved", and disruption of the enforcement or decision path by denial of service "can adversely impact enterprise operations". The blunt version: "An operational error could prevent an entire enterprise from functioning if the [decision] or [administrator] component becomes inaccessible from the network." The recommended mitigation is not fragmentation. It is putting the shared path in a properly secured environment or replicating it across several locations, with configuration changes logged and audited.

Replication and duplication are different things, and conflating them is how these arguments go wrong. Three replicas of one connectivity plane share one scope model. Three teams' connectivity planes do not.

Table 2 — Symptom to cause to fix. The first two rows are what fragmenting connectivity actually feels like.

The trade is worth making once a single team reviewing every agent has become the real constraint on shipping. It is not worth making for one or two agents built by one team, which has no bottleneck yet and would pay pure coordination cost. Build the central version first. Split execution when the review queue, not the architecture diagram, says it is time.

Where Fabriq Fits

Agentic Fabriq is built as the shared plane rather than the runtime. It holds credentials per user in a vault and attaches them server-side at the moment of the call, so an agent in any framework never handles the secret. Every call carries two identities, the agent and the acting user, and an agent's effective tool list is the intersection of the user's scopes and the agent's. Refresh runs behind that boundary with last-used tracking.

The limits matter here. Clearing a vault copy is not revoking a grant upstream, so the call to the provider's revocation endpoint is still yours to make. And a shared plane does not decide which actions an agent may take on its own initiative; that is a separate layer.

Frequently Asked Questions

Should each team run its own MCP server? For a tool that only that team uses, and where the team will own the authorization obligations, sometimes. Read the MUST list first: protected resource metadata, audience validation, issuer validation, scope challenges, and no token passthrough. Most teams that say yes have not read it, and the second server is where the first mistake ships.

Is a service mesh enough? It handles workload-to-workload authentication and transport, and Istio's control plane already issues the certificates. It does not know what an agent's acting user may do in a SaaS application, which is the decision agent connectivity turns on.

Do we still need a central catalog if we use A2A and MCP discovery? Yes. A2A names curated registries as a primary discovery mechanism for exactly this reason, and RFC 8615 says clients should not expect anything to exist at a well-known path. Protocol discovery finds cooperating endpoints; a catalog records what exists.

How do we let teams choose frameworks without five credential stores? Put the credential and scope decision behind a call boundary every framework can reach, rather than in a library that embeds secrets. Heterogeneous clients against one plane is the case MCP version negotiation was designed for.

Does the EU AI Act require centralized logging? It does not name an architecture. Article 12 requires automatic event recording over the system's lifetime and Article 26(6) requires deployers to retain those logs for at least six months. Whether you meet that with one schema or five is your choice; only one of those is answerable during an incident.

Conclusion

The advice worth taking from "centralized versus decentralized" is not one answer applied to a stack. It is a decision per plane, and the planes point different ways. Let execution fragment, because that is where a shared mandate becomes a queue and where teams have legitimate reasons to disagree. Keep connectivity, identity and the log schema shared, because those are where five inconsistent answers are worse than one imperfect one, and because the specs hand every additional copy the same long list of obligations.

Getting it wrong has a predictable shape either way. Centralize everything and one team becomes the queue for the company's agent roadmap. Fragment everything and you get five credential stores, five scope models, two trust domains and an audit trail covering whichever team remembered to build one. Then replicate what you centralized, because a shared plane that goes down takes the estate with it.

Sources

All URLs read 2026-09-29.

• Agent Access Control Taxonomy — the enforcement-point dimension, which asks where the authorization decision is enforced, and the identity-model dimension, where a platform-issued workload identity is its own term.
• NIST SP 800-207, Zero Trust Architecture — section 3.4 on the control plane and data plane split, and sections 5.1 and 5.2 on subversion and availability risk at the shared decision path.
• MCP specification, Authorization (2026-07-28) — the resource-server role, RFC 9728 and RFC 8707 requirements, audience validation, the ban on accepting or transiting other tokens, and the step-up scope challenge.
• MCP specification, Versioning — the YYYY-MM-DD revision format, the current revision, and simultaneous multi-version support.
• MCP specification, Discovery (2026-07-28) — server/discover as a mandatory RPC, and the warning that serverInfo is self-reported and unverified.
• Official MCP Registry — a metadata catalog rather than a host, verified namespaces such as io.github.owner/name, and the v0.1 API freeze.
• A2A Protocol: Agent Discovery — the /.well-known/agent-card.json path and curated registries as an enterprise discovery mechanism.
• A2A Protocol: Enterprise-Ready Features — agents as standard HTTP enterprise applications, security schemes declared in the Agent Card, and OpenTelemetry tracing with task and session identifiers.
• RFC 8615: Well-Known Uniform Resource Identifiers — the reserved /.well-known/ prefix and the caution that clients should not expect a resource to exist there.
• SPIFFE concepts — the spiffe://trust domain/workload identifier format, trust domain as trust root, X.509 and JWT SVIDs, and the Workload API needing no prior credential.
• Istio architecture — the data plane of Envoy proxies, the control plane that configures them, and istiod as certificate authority.
• OpenTelemetry semantic conventions, GenAI attribute registry — the gen_ai.* attributes moved to a dedicated repository, with Development-stability values.
• EU AI Act Article 12, Record-Keeping — automatic recording of events over the system's lifetime.
• EU AI Act Article 26, Obligations of Deployers — the duty to keep automatically generated logs for at least six months, and the Annex III timeline.