Federate the Control, Distribute the Execution: A Reference Architecture for Governed Multi-Agent Systems in CSPs

As CSPs deploy AI agents across BSS, RAN and the core, two instincts collide. One is to centralise everything for control, which is slow, brittle and creates a single bottleneck. The other is to let every domain build its own agents, which is fast but inconsistent and ungoverned. Neither scales to the enterprise.

A federated architecture resolves the tension: a central control plane for governance and assurance, and distributed domain cells where agents execute close to the systems they serve. This article explains how that architecture works, what each block contributes, and how CSPs can realise value from it safely.

Pause animation

(opens the full-size diagram in a new tab)

Why Federation Suits Multi-Agent Systems in a CSP

A CSP is not one operational domain. BSS, RAN and core differ in speed, data sensitivity, vendors, change processes and the cost of error. A single central brain struggles with that variety, while fully independent domain solutions cannot deliver end-to-end outcomes or consistent control.

• Speed and locality: Agents that sit close to the systems they act on respond quickly and keep working even if the centre is slow or unreachable.
• Domain expertise: Each cell can be owned and tuned by the team that understands its systems and risks.
• Contained failure: A fault or misbehaving agent in one cell is less likely to spread across the estate.
• Consistent governance: Policy, assurance and accountability are defined once, centrally, and applied everywhere.
• End-to-end outcomes: Cross-domain objectives, such as an SLA that spans BSS, RAN and core, are coordinated centrally rather than negotiated between silos.

The Architecture at a Glance

The diagram shows three layers. The central federated control plane holds two planes: governance and policy, and assurance. The distributed data and execution plane holds the domain cells where agents work. At the bottom sits the physical and logical telco stack that the agents ultimately act upon.

Five flows connect them. Policy is pushed down from governance to the cells. Action override lets the control plane stop or change what a cell is doing. Telemetry and state are synchronised upwards so the centre can see what is happening. Cells signal to each other directly using agent-to-agent (A2A) and Model Context Protocol (MCP) interactions. And every action on the telco stack passes through deterministic API calls.

The Central Control Plane: Six Capabilities

The control plane has two halves. The governance and policy plane decides what is allowed. The central assurance plane checks what is actually happening. Together they provide six capabilities:

1. RBAC and guardrail deployment. Roles, permissions and guardrails are defined once and deployed to every cell. Each agent receives only the access its role requires, and the same rules apply whichever team built it.
2. SLA and intent definitions. Business intent and service commitments are expressed in machine-readable form, so every agent knows which outcomes matter and cells stay aligned on them.
3. Global saga coordination. Changes that span domains, such as activating a service across BSS, RAN and core, are run as sagas: a series of local steps, each with a defined compensating action. If one step fails, earlier steps are undone, which keeps the estate consistent without locking every system.
4. Continuous drift and behaviour audit. Agent behaviour is compared with what was approved and tested. Gradual drift, such as an agent taking different actions over time, is detected early and the evidence is retained.
5. Cross-domain topology and state graph. A live graph of how services, resources and domains relate gives the control plane the cross-domain context that no single cell has. It supports impact analysis and conflict detection, building on the shared context layer.
6. Anomaly and feedback-loop detection. Agents can react to each other’s actions and set off oscillations or cascades. The detector spots abnormal behaviour and runaway loops, and can trigger an override before they cause harm.

The Domain Cells: Where Agents Execute

Each cell, for BSS, RAN and core, has the same three-part structure, which keeps them consistent while allowing each to specialise:

• Local mini-gateway: The controlled entry and exit point of the cell. It authenticates requests, applies the policy pushed from the centre, and mediates access to tools and data.
• Local orchestrator: Plans and sequences the work of the cell’s agents, and handles local coordination without waiting for the centre.
• Specialised domain agents: Experts in the domain’s tasks, such as order handling in BSS, radio optimisation in RAN or session and policy management in the core.

Cells collaborate through inter-cell signalling over A2A and MCP, so an issue seen in RAN can inform BSS or core without routing everything through the centre. Because the gateway enforces policy and telemetry flows upward, that collaboration remains visible and governed.

The Deterministic Boundary

The most important line in the diagram is the one between the cells and the telco stack. Agents reason in a probabilistic way, but they act only through deterministic API calls to the systems below: BSS, OSS, MANO, the core network, RAN controllers and the SLA engine. Those APIs behave the same way every time, are versioned and validated, and can be logged and rolled back.

In other words, the intelligence may be flexible, but its reach is not. An agent cannot do anything to the network that an approved, controlled interface does not allow.

The Business Value

• Faster delivery: Cells let domain teams ship and improve agents quickly, while shared governance removes the need to re-approve every project from scratch.
• Lower operating cost: Automating cross-domain coordination reduces manual hand-offs, rework and escalations between BSS, RAN and core teams.
• Fewer costly failures: Drift detection, feedback-loop detection and central override limit incidents caused by agents themselves.
• Resilience: Cells keep operating locally, and a problem in one domain is contained.
• Regulatory and board confidence: Central audit and accountability give leaders evidence that autonomous systems are under control.
• Reuse: Governance, assurance and the topology graph are built once and used by every agent and domain.

Realising the Return on Investment

1. Build the control plane once, then add cells. The return grows with each additional domain and use case that reuses the same governance and assurance.
2. Start where cross-domain value is clear. Choose a journey that spans domains, such as service activation or fault resolution, and measure it end to end.
3. Baseline before you automate. Record cycle times, manual touches, escalations and incident rates so improvements can be evidenced.
4. Stage autonomy. Begin with recommendations, move to approved actions, and allow autonomous action only within proven limits.
5. Fund shared capabilities as shared assets. Treat the control plane as infrastructure with clear ownership, and measure the value it delivers across all cells.

Layered Guardrails for Probabilistic Agents

Agents powered by large language models are probabilistic. They may reason differently each time, be confidently wrong, or be steered by malicious content. The telco stack is deterministic. The federated architecture addresses this mismatch with defence in depth, so that no single control carries all of the risk:

1. Central policy and RBAC. Guardrails and least-privilege roles are defined centrally and deployed to every cell.
2. Local enforcement at the gateway. Each cell’s mini-gateway applies policy to every request in real time, close to the agent.
3. Bounded orchestration. The local orchestrator limits what its agents may attempt, in what order and how often.
4. The deterministic API boundary. Agents can act only through validated, versioned interfaces, never directly on network elements.
5. Saga compensation and rollback. Cross-domain changes can be undone step by step if any part fails.
6. Continuous assurance. Drift audit and anomaly and feedback-loop detection watch agent behaviour and the state of the network.
7. Override and containment. The control plane can override an action or isolate a cell immediately.
8. Secure inter-agent communication. A2A and MCP traffic is authenticated and policy-checked, and external content is treated as untrusted input.
9. Audit and accountability. Decisions, actions and overrides are recorded for investigation and regulatory review.

The same thinking underpins our article on the assurance fabric, and applies directly to domain-specific cases such as 5G network slicing.

Federate the control. Distribute the execution. Keep the boundary deterministic.

Questions for the Leadership Team

• Where does governance live today, and does it apply equally to every agent and domain?
• Can we see, in one place, what every cell is doing and how its behaviour is changing?
• How are changes that span BSS, RAN and core coordinated, and what happens if one step fails?
• Do agents act only through controlled, deterministic interfaces?
• Are we funding reusable control and assurance, or paying for them again in every project?

A question for every CSP leadership team:

If an agent in one domain began to behave unexpectedly tomorrow, how quickly could we see it, contain it and prove what happened?