Agent Swarms: Why CSPs Need to Rethink Their Architecture Before Scaling AI Agents

Moving from individual AI agents to collaborative agent ecosystems requires a different approach to architecture, security and operational control.

The telecoms industry is approaching another important shift in the way its networks and operations are managed. AI agents are moving beyond simple assistants that respond to questions or perform isolated tasks. Increasingly, they are being designed to interact with systems, use tools, exchange information and make decisions with a degree of autonomy.

For communications service providers (CSPs), the attraction is clear. An agent could investigate a network fault, another could assess the impact on services, while a third examines configuration changes and recommends a resolution. Instead of relying on multiple manual processes and teams to piece together information, these agents could collaborate to achieve an outcome much faster.

As these capabilities mature, the natural progression is towards multiple agents working together. What begins as a handful of specialised agents can quickly develop into much larger networks of interacting agents, each with its own responsibilities, permissions, information sources and dependencies.

This is where CSPs need to pause and think carefully about the architecture they are building.

The temptation will be to introduce agents wherever there is an opportunity to automate a process, allowing individual teams and business units to develop their own solutions. Over time, these agents may begin communicating with one another, sharing information and accessing common systems. What looks like progress at an individual project level can create a much more complicated operating environment across the business.

The challenge is that agent collaboration introduces a different level of complexity. Agents can influence one another’s decisions, pass on incorrect information, compete for resources and potentially expose systems to security risks through indirect interactions.

CSPs therefore need to look beyond the performance of individual agents. They need to consider how those agents are organised, connected, governed and controlled as part of a wider operational environment.

The objective should not be to build the biggest possible agent swarm. It should be to build manageable, secure and well-governed clusters of agents that can work together reliably, with the ability to connect them where there is a genuine business or operational benefit.

Pause animation

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

The danger of letting agent swarms develop in silos

Most CSPs are likely to approach agent adoption through existing organisational structures. Network operations may introduce agents to support fault management and service assurance. Customer operations may develop agents for customer interactions and service resolution. Security teams may deploy agents for threat detection, while IT and cloud teams explore automation across their own environments.

Individually, these initiatives may make perfect sense. Each has a defined objective and can demonstrate improvements in efficiency, speed or cost.

The problem begins when these initiatives start to overlap.

Agents developed by different teams may use different identity models, access different data sources and operate under different assumptions about security and authority. They may have no common understanding of how information should be validated, how decisions should be escalated or what happens when one agent passes work to another.

As the number of agents increases, the relationships between them become harder to manage.

An agent introduced to investigate a network incident, for example, might need information from a service assurance agent, which in turn relies on data from a customer impact agent. If these agents have been developed independently, there may be no consistent approach to validating the information being exchanged or establishing responsibility for decisions made further down the chain.

The risk is that CSPs gradually create an interconnected environment that nobody has designed or fully understands.

This is not simply an issue of AI governance. It is an architectural problem.

CSPs have already learned through years of network transformation that connecting systems without considering their dependencies, interfaces and operational responsibilities creates long-term complexity. Agent-based environments need the same architectural discipline.

Rather than allowing isolated initiatives to evolve into uncontrolled networks of agents, CSPs should establish a common framework for how agents are designed, deployed, connected and managed.

Start with manageable clusters, not uncontrolled swarms

A more practical approach is to organise agents into clearly defined clusters, each responsible for a particular business capability or operational domain.

For example, a CSP might establish a network assurance cluster containing agents responsible for fault analysis, performance monitoring, service impact assessment and remediation recommendations. These agents would work together within a defined operational boundary, sharing relevant information and coordinating activities through agreed interfaces.

A separate customer experience cluster could bring together agents responsible for customer interaction, service history, fault communication and case resolution.

A security operations cluster might include agents that investigate alerts, correlate threat intelligence, assess risk and coordinate responses.

The important point is that each cluster has a clear purpose and a defined scope. Its agents understand their respective responsibilities, the information they are allowed to access and the actions they are permitted to take.

This creates a more manageable environment than allowing every agent to communicate directly with every other agent across the business.

Clusters should also have clearly defined boundaries. An agent operating within network assurance should not automatically inherit access to customer records, security systems or privileged network configuration simply because another agent in a different domain can access them.

Where collaboration between clusters is necessary, it should take place through controlled interfaces and agreed processes.

For example, a network assurance cluster may identify a service degradation and pass a validated impact assessment to a customer experience cluster. The customer cluster can then coordinate customer communications without needing unrestricted access to the network management environment.

This separation helps contain errors, limit security exposure and make responsibility easier to establish.

It also means that a problem within one cluster is less likely to spread throughout the wider operational environment.

The aim is not to prevent agents from collaborating. It is to make collaboration deliberate, controlled and proportionate to the task.

Establish a common architecture before the number of agents grows

For this approach to work, CSPs need to establish some common architectural principles across the organisation.

At the heart of this should be a consistent way of managing agent identity, permissions, communication, information exchange and execution of tasks.

Every agent should have a recognised identity, a defined purpose and an explicit set of permissions. Those permissions should reflect the work it is expected to perform, rather than the capabilities of the platform or tools it happens to use.

Equally important is how agents delegate work. When one agent requests another to perform a task, the receiving agent should be able to establish who initiated the request, whether the request is legitimate and whether the requested action is within its permitted scope.

Delegation must not become a way of bypassing security controls.

CSPs should also consider introducing a common orchestration and policy layer. This would provide a consistent way to manage how agents are registered, how they discover approved services, how they communicate and how their activities are monitored.

It should not become a single point through which every decision must pass. Rather, it should establish the rules and controls within which individual clusters can operate.

This distinction is important. A highly centralised architecture can create bottlenecks and undermine the very efficiency that agent-based automation is intended to deliver. Equally, allowing every cluster to establish its own rules can create fragmentation and inconsistent levels of control.

The challenge is to establish common standards while allowing individual clusters enough independence to operate effectively.

Containing failures before they spread

One of the most important reasons for introducing cluster boundaries is the ability to contain failures.

In a conventional workflow, an incorrect decision may affect one process or system. In an agent environment, that same decision could be passed between multiple agents and influence a much wider sequence of actions.

Consider an agent that incorrectly identifies a network fault. It passes its findings to a remediation agent, which recommends a configuration change. Another agent updates the incident record, while a further agent uses the same information to assess customer impact.

By the time the mistake is identified, several downstream processes may already have acted on incorrect information.

Shared memory and common knowledge repositories introduce another dimension. If inaccurate information is written into a shared context, other agents may treat it as established fact. The original error can then influence future decisions long after the initial incident has passed.

CSPs need to design their clusters to prevent this kind of uncontrolled propagation.

Information exchanged between agents should carry sufficient context to establish its source, reliability and status. There should be a distinction between verified information, assumptions and recommendations. Critical decisions should be subject to additional validation before they trigger consequential actions.

Clusters should also have defined limits on their authority. An agent may be permitted to investigate, analyse and recommend a network change, but that does not necessarily mean it should be allowed to execute that change independently.

Where something goes wrong, the CSP should be able to isolate the affected agent or cluster, suspend its activities and prevent further propagation while the issue is investigated.

This is where familiar distributed systems engineering principles become particularly valuable. Failure isolation, circuit breakers, rate limits, timeouts and backpressure should all form part of the design.

The intention is to ensure that a failure remains manageable rather than becoming a business-wide incident.

Security needs to follow the interaction between agents

Traditional security models are largely concerned with protecting systems, users, applications and data. Agent-based environments introduce another consideration: the relationships and trust established between autonomous agents.

An agent with limited permissions may still become a route into more privileged systems if it can influence another agent with greater access.

For example, a compromised agent operating within a customer support process could potentially pass manipulated information to another agent that has access to operational tools. If the receiving agent trusts the source without validating the request, the boundary between the two environments becomes much less meaningful.

Prompt injection makes this particularly relevant. Instructions embedded in tickets, documents, messages or other external content could influence an agent’s behaviour if the agent cannot reliably distinguish untrusted information from legitimate instructions.

For CSPs, the implications extend across network infrastructure, customer information, identity systems and operational platforms.

A zero-trust approach is therefore essential. Agents should not trust other agents simply because they belong to the same organisation or cluster. Each request should be evaluated according to the identity of the requesting agent, its authority, the nature of the task and the potential consequences.

Permissions should be granted at the level of individual tasks wherever possible, with privileged access tightly controlled and time-limited.

Cross-cluster communication deserves particular attention. Moving information between two clusters should not automatically mean transferring the permissions or authority of the originating agent.

CSPs also need to maintain an accurate understanding of the identities operating across their agent environment. As agents are created, updated, delegated or retired, their identities and permissions must be managed accordingly.

Without this discipline, the organisation risks creating a growing population of temporary digital identities with unclear ownership and excessive access.

You cannot manage what you cannot see

Another major consideration is operational visibility.

With several agents working together, it can become difficult to establish exactly what happened when a process produces an unexpected result.

An individual agent may appear to have behaved correctly, while the overall outcome is wrong. The cause may lie in an earlier handoff, an incorrect assumption, conflicting instructions or an unexpected interaction between agents.

For CSPs, this creates a significant challenge for network operations, service assurance and incident management.

If an agent-driven process makes an incorrect change or contributes to a service disruption, engineers need to reconstruct the sequence of events. They must understand which agents were involved, what information each received, what decisions were made and which tools or systems were accessed.

Monitoring individual agents is not enough. Visibility must extend across the entire cluster and, where appropriate, across the interactions between clusters.

This means designing observability into the architecture from the beginning.

Every meaningful handoff should be traceable. Decisions and actions should be recorded with sufficient context to support investigation. Operational teams should be able to identify unusual behaviour, repeated failures, excessive retries, unexpected access requests and performance degradation.

There also needs to be a clear operational view of the health of each cluster.

• How many tasks are active?
• Are agents waiting on one another?
• Are requests exceeding expected limits?
• Are failures increasing?
• Is one agent creating an unreasonable amount of work for other agents?

These are the kinds of questions that CSP operations teams should be able to answer without having to investigate each agent independently.

Observability should not be treated as a reporting feature added after deployment. It is a fundamental requirement for operating agent-based systems safely.

Rethinking the operating model, not just the technology

Architecture alone will not solve the problem. CSPs also need to reconsider how responsibility for agent-based operations is organised.

In many organisations, AI initiatives are being driven by individual business functions, technology teams or transformation programmes. This is understandable while experimentation is taking place, but it becomes increasingly difficult to sustain as agents begin interacting across organisational boundaries.

Someone needs to own the overall environment.

This does not mean creating a central team that controls every agent and every decision. It means establishing clear accountability for the standards, policies and operational controls that apply across all clusters.

Network operations should retain responsibility for the operational outcomes within their domain. Security teams should define and oversee the security requirements. Architecture teams should establish common design principles and integration standards. AI and platform teams should ensure that agents are developed and deployed within those boundaries.

There also needs to be a clear process for approving new agents, introducing new capabilities, changing permissions and connecting clusters.

Before a new agent is introduced, CSPs should understand what it is intended to do, what information it needs, which tools it can access and what happens if it fails. Before two clusters are connected, the organisation should understand the operational and security implications of that relationship.

This is how CSPs avoid creating an environment in which every new automation project introduces another set of dependencies that nobody is fully accountable for.

A more measured path towards agent autonomy

The transition towards agent-based operations should be progressive.

CSPs do not need to move directly from isolated agents to highly autonomous, interconnected swarms. In fact, doing so would introduce unnecessary risk before the organisation has established how to manage the underlying complexity.

A more sensible approach is to begin with small, well-defined clusters that address specific operational challenges.

Initially, agents can focus on gathering information, analysing problems and making recommendations. Once their behaviour is understood and the necessary controls have been tested, selected activities can be allowed to proceed with greater autonomy.

Each expansion should be supported by evidence that the cluster can operate reliably, recover from failures and remain within its security and operational boundaries.

Testing should also examine how agents behave when things do not go according to plan.

• What happens when an agent becomes unavailable?
• What if two agents disagree?
• Can an agent be prevented from exceeding its permissions?
• Can the cluster be isolated without disrupting other services?
• Can an engineer reconstruct what happened after an incident?

These questions should be answered before the cluster is trusted with more consequential responsibilities.

Over time, successful clusters can be connected to other domains through controlled interfaces. This creates the opportunity to build a wider ecosystem of collaborating agents without losing the ability to understand and manage the individual components.

It is a more deliberate route to scale, but one that gives CSPs a much better chance of maintaining control as adoption grows.

The real opportunity is in building manageable ecosystems

Agent swarms have the potential to change how CSPs operate their networks, manage services and interact with customers. They could reduce the time spent coordinating complex activities, bring together information from disconnected systems and allow operational teams to focus on more valuable work.

But the long-term value will not come simply from deploying more agents or giving them greater autonomy.

It will come from the ability to organise those agents into manageable operational units, connect them where necessary and maintain control over how they interact.

CSPs should resist the temptation to let agent swarms develop as a collection of disconnected initiatives. The architecture, security model, governance and operating processes need to evolve together.

The important shift is to move away from thinking about individual agents as standalone automation tools and towards treating clusters of agents as managed components of the wider technology estate.

That means clear boundaries, controlled handoffs, defined responsibilities, consistent identity and access management, failure isolation and end-to-end observability.

It also means recognising that autonomy needs boundaries. Not every task should be delegated, not every decision should be automated and not every agent needs access to every other agent.

CSPs already know what it takes to operate complex, interconnected networks. The same engineering discipline now needs to be applied to the AI-driven systems being introduced to manage them.

The organisations that get this right will be better placed to scale agent-based automation without creating an operational environment that becomes increasingly difficult to secure, understand and control.

The future is unlikely to be about one enormous agent swarm. It should be about a well-engineered ecosystem of smaller, trusted and manageable agent clusters, working together within clearly defined boundaries.

That is how CSPs can turn the promise of agentic AI into something they can operate with confidence.