Centralized Agent Registry vs. Decentralized Service Mesh Discovery: Which Multi-Agent Pipeline Topology Actually Survives Enterprise Zero-Trust Mandates in Q4 2026?

There is a question quietly tearing apart architecture review boards at Fortune 500 companies right now: when your zero-trust mandate finally reaches the on-premises AI cluster, which multi-agent pipeline topology do you keep? The one that is elegant and centrally governed, or the one that is resilient and self-discovering? This is not a theoretical debate. By Q4 2026, major regulatory frameworks including updated NIST SP 800-207 guidance and the EU AI Act's operational security annexes are pushing enterprise security teams to enforce microsegmentation down to the workload level, and AI agent pipelines are directly in the crosshairs.

The two dominant topologies that have emerged over the past two years are the Centralized Agent Registry (CAR) and the Decentralized Service Mesh Discovery (DSMD) model. Both solve the problem of "how do agents find each other and coordinate tasks," but they make radically different bets about where trust, identity, and routing authority should live. Under normal network conditions, the differences are mostly philosophical. Under enterprise network segmentation requirements, those differences become existential.

This article breaks down both architectures with surgical precision, tests them against the real-world constraints of a zero-trust, segmented on-premises environment, and gives you a defensible recommendation for your Q4 2026 infrastructure planning cycle.

Setting the Stage: What Zero-Trust Actually Demands of AI Agent Networks

Before comparing the two topologies, it is worth being precise about what zero-trust architecture (ZTA) actually requires in the context of multi-agent AI pipelines. Zero-trust is not a firewall rule. It is a philosophy operationalized through several hard technical requirements:

• Identity verification at every hop: Every agent-to-agent call must carry a verifiable identity token, typically a short-lived mTLS certificate or a signed JWT issued by a workload identity provider like SPIFFE/SPIRE.
• Least-privilege access per transaction: An agent performing a data retrieval subtask should not carry the same authorization scope as the orchestrator agent that spawned it.
• Microsegmentation enforcement: Network policies must be enforceable at the individual workload level, meaning an agent running in VLAN segment C cannot reach an agent in segment D unless a policy explicitly permits it.
• Continuous authorization: Trust is not established once at session start. It is re-evaluated on every request, meaning long-running agent conversations must periodically re-attest.
• Audit logging with cryptographic integrity: Every agent interaction must produce a tamper-evident log entry suitable for compliance review.

Now apply these requirements to a pipeline where dozens of specialized agents (a planner, several retrieval agents, code execution sandboxes, summarizers, and a critic) are dynamically spawned, communicate asynchronously, and may be scheduled across multiple physical racks in a segmented data center. The routing and discovery layer is no longer a convenience feature. It is a security boundary.

Architecture One: The Centralized Agent Registry (CAR)

How It Works

In a Centralized Agent Registry model, a single authoritative service maintains the canonical list of all active agents, their capabilities, their network addresses, and their current health status. When Agent A needs to delegate a subtask to a summarization agent, it queries the registry, receives a pointer, and initiates a direct connection. The registry is the single source of truth for the entire pipeline topology at any given moment.

Popular implementations of this pattern include purpose-built agent orchestration platforms that have adopted a control-plane-and-data-plane separation, where the registry acts as the control plane and agent-to-agent communication flows over a separate data plane. Frameworks like LangGraph's hosted execution environment, early versions of the OpenAI Assistants API's thread management, and enterprise platforms built on top of Microsoft's AutoGen infrastructure all lean toward centralized coordination semantics, even if the registry itself is clustered for high availability.

Where CAR Shines

• Governance simplicity: Policy enforcement is straightforward. You secure one registry endpoint, and you control the entire topology. Access control lists, capability-based permissions, and audit logs all flow through a single choke point.
• Observability: The registry has a complete, real-time view of the pipeline. Debugging a failed multi-agent workflow is dramatically easier when you can query a single service and reconstruct the full agent interaction graph.
• Compliance auditability: For regulated industries (finance, healthcare, defense), the ability to produce a complete chain-of-custody log for every agent decision is non-negotiable. A centralized registry makes this tractable.
• Deterministic routing: In workflows where task ordering and agent selection must be reproducible (for model governance and explainability requirements), centralized dispatch provides the determinism that decentralized gossip protocols cannot guarantee.

Where CAR Breaks Under Zero-Trust Segmentation

Here is where the architecture starts to crack. In a heavily segmented network, the centralized registry must be reachable from every network segment that hosts an agent. This creates a connectivity requirement that directly conflicts with microsegmentation principles. You are forced to punch firewall rules from every segment to the registry segment, which means the registry becomes the highest-value lateral movement target in your entire AI infrastructure.

Worse, when the registry is unavailable (planned maintenance, network partition, or a security-triggered isolation event), the entire pipeline stops. In a zero-trust environment, isolation events are not rare edge cases. They are designed to be frequent and fast. An architecture that treats the registry as a single point of failure will experience that failure regularly in a mature ZTA deployment.

There is also a subtler problem: the registry must hold live network addresses for agents across segments. In a dynamic, container-scheduled environment (Kubernetes across multiple isolated namespaces, or VMware-segmented bare-metal nodes), those addresses change frequently. Keeping the registry consistent across segment boundaries requires either a highly privileged network observer or constant agent-initiated heartbeat traffic, both of which create security surface area that zero-trust teams will flag immediately.

Architecture Two: Decentralized Service Mesh Discovery (DSMD)

How It Works

In a Decentralized Service Mesh Discovery model, agents find each other through a distributed discovery protocol embedded in the service mesh data plane. There is no single registry. Instead, each agent registers its capabilities and identity with a local mesh sidecar (think Envoy proxy or a purpose-built agent sidecar), and capability advertisements propagate through a gossip protocol or a distributed key-value store (like etcd shards or Consul with WAN federation). When Agent A needs a summarizer, it queries its local sidecar, which resolves the request using a distributed capability index without ever requiring a connection to a central authority.

This model draws heavily from service mesh patterns pioneered by Istio, Linkerd, and Consul Connect, but extends them with agent-specific semantics: capability matching (not just service name resolution), intent-based routing, and stateful conversation context propagation. Projects in the open-source space like the Agent Communication Protocol (ACP) specification and CNCF's emerging AI workload working group are pushing toward standardizing exactly this kind of mesh-native agent discovery.

Where DSMD Shines

• Network partition resilience: Because discovery is local-first, an agent can still find and communicate with peers in its own segment even if cross-segment connectivity is severed. Pipelines degrade gracefully rather than failing catastrophically.
• Zero-trust alignment: The sidecar model is a natural fit for mTLS enforcement. Every agent-to-agent connection is terminated at the sidecar, which handles certificate rotation, policy enforcement, and traffic authorization without the agent code itself needing to implement any of this logic.
• Horizontal scalability: There is no central bottleneck. As you add agents and segments, discovery capacity scales with the mesh rather than requiring you to scale a centralized registry service.
• Segment-aware routing: A well-configured service mesh can enforce topology-aware routing policies, preferring in-segment agents over cross-segment agents, which directly reduces the blast radius of any single segment compromise.

Where DSMD Breaks Under Zero-Trust Segmentation

The decentralized model is not without its own serious failure modes in a zero-trust context. Gossip protocols and distributed key-value stores require their own cross-segment communication channels to maintain consistency. If you segment too aggressively, you can split the discovery fabric itself, resulting in agents in different segments having inconsistent views of what capabilities are available. This is the distributed systems equivalent of a split-brain scenario, and it is particularly dangerous in agentic workflows where an orchestrator agent might dispatch a subtask to an agent that no longer exists in the current topology snapshot.

Observability is also significantly harder. When a pipeline fails in a DSMD environment, reconstructing the interaction graph requires correlating logs from dozens of individual sidecars across multiple segments. Without a centralized telemetry aggregator (which reintroduces some of the centralization you were trying to avoid), debugging becomes an exercise in distributed forensics that most enterprise operations teams are not staffed to handle efficiently.

Finally, capability-based discovery in a gossip model introduces a timing problem. A newly spawned agent's capabilities may not have fully propagated through the mesh by the time an orchestrator queries for them, leading to routing failures that are intermittent, hard to reproduce, and maddening to diagnose in production.

Head-to-Head: Scoring Both Topologies Against Enterprise ZTA Requirements

Let us score both architectures across the dimensions that matter most for a Q4 2026 enterprise deployment operating under zero-trust mandates:

• Microsegmentation compatibility: DSMD wins. The sidecar-per-agent model aligns naturally with per-workload policy enforcement. CAR requires segment-crossing connectivity to the registry, which creates policy exceptions that ZTA teams will resist.
• Identity and mTLS enforcement: Tie. Both architectures can be implemented with SPIFFE/SPIRE-based workload identity. DSMD has a slight edge because the sidecar handles certificate management transparently. CAR requires the registry itself to participate in the PKI chain.
• Audit logging and compliance: CAR wins decisively. Centralized dispatch produces a complete, ordered log of every agent interaction. DSMD requires significant investment in distributed tracing infrastructure (OpenTelemetry pipelines, segment-crossing trace aggregation) to achieve equivalent auditability.
• Resilience to isolation events: DSMD wins. Segment isolation is a feature, not a bug, in a DSMD topology. CAR treats isolation as a failure condition.
• Operational complexity: CAR wins. A centralized registry is a well-understood operational pattern. DSMD requires deep expertise in service mesh operations, distributed systems failure modes, and gossip protocol tuning. The talent pool for this is still thin in most enterprise IT organizations.
• Blast radius containment: DSMD wins. Compromise of a single sidecar or segment does not expose the global topology. Compromise of a centralized registry potentially exposes the entire agent network map.
• Latency at scale: DSMD wins at high agent counts. Local sidecar resolution is faster than a round-trip to a centralized registry, particularly in multi-rack on-premises deployments where network hops between segments carry real latency costs.

The Hybrid Answer Nobody Wants to Hear (But Everyone Ends Up Building)

Here is the uncomfortable truth that emerges from this comparison: neither pure topology survives a mature enterprise zero-trust environment without significant compromise. The organizations that are actually shipping production multi-agent pipelines on segmented on-premises infrastructure in 2026 are converging on a hybrid pattern that borrows the best properties of both models.

The pattern looks like this:

• A federated registry model where each network segment hosts a local registry shard. Shards synchronize with each other through authenticated, rate-limited replication channels that are explicitly permitted in the segmentation policy. The global registry is eventually consistent rather than strongly consistent.
• A service mesh data plane handles all agent-to-agent traffic enforcement, mTLS termination, and per-request authorization. The mesh does not own discovery; it owns enforcement.
• A centralized telemetry aggregator (typically an OpenTelemetry Collector cluster with segment-aware exporters) provides the unified audit trail that compliance teams require, without requiring the registry itself to be globally reachable.
• Capability advertisements are signed and versioned. Each agent publishes a signed capability manifest at registration time. Orchestrators verify the signature before dispatching tasks, preventing spoofed capability announcements in the mesh.

This hybrid is more complex to build and operate than either pure topology. But it is the only architecture that satisfies the full matrix of ZTA requirements without requiring your security team to accept unacceptable policy exceptions.

Practical Recommendations for Q4 2026 Planning

If you are in the middle of your Q4 2026 infrastructure planning cycle, here is where to focus your energy:

1. Start with your segmentation policy, not your agent framework. Too many teams pick an agent orchestration framework first and then try to retrofit it into their network architecture. The segmentation policy is the constraint that does not flex. Your agent topology must conform to it, not the other way around.
2. Treat the registry as a security boundary, not just an operational one. Whether you go centralized, federated, or mesh-native, the registry holds the keys to your entire agent network. It needs the same security posture as your identity provider: HSM-backed keys, immutable audit logs, and a well-tested break-glass procedure.
3. Invest in distributed tracing before you invest in agent capabilities. The most common failure mode in production multi-agent deployments is not the agents themselves; it is the inability to diagnose what went wrong when a pipeline fails across segment boundaries. OpenTelemetry with W3C Trace Context propagation through agent message payloads is the current best practice.
4. Test your topology under simulated isolation events. Run chaos engineering exercises where individual segments are isolated and verify that your pipeline degrades gracefully. If the answer is "the whole pipeline stops," you have a CAR topology that is not ready for a zero-trust environment.
5. Align with emerging standards now. The CNCF AI workload working group and the SPIFFE community are actively developing agent-specific identity and discovery specifications. Aligning your internal architecture with these emerging standards will reduce the cost of future upgrades significantly.

Conclusion: The Topology That Survives Is the One Built for the Network You Have

The honest answer to the question posed in this article's title is that neither a pure Centralized Agent Registry nor a pure Decentralized Service Mesh Discovery topology fully survives aggressive enterprise network segmentation under zero-trust mandates as they stand in Q4 2026. CAR offers governance and auditability at the cost of segmentation compatibility and resilience. DSMD offers resilience and ZTA alignment at the cost of observability and operational complexity.

The organizations that will successfully deploy production multi-agent AI pipelines on segmented on-premises infrastructure are the ones that stop treating this as a choice between two competing philosophies and start treating it as an engineering problem with specific, measurable constraints. Federated registries, mesh-enforced data planes, and centralized telemetry aggregation are not a compromise. They are the correct architecture for the environment that actually exists in enterprise IT in 2026.

The agents are getting smarter. The networks are getting stricter. The topology that survives is the one designed for both realities simultaneously.