IA Agêntica
More agents increase the risk of intelligence silos
Specialized agents can make each domain smarter. The challenge is making sure that intelligence can cross the boundaries between tools, teams, and technologies to understand the operation as a whole.
When each agent knows only part of the operation
In recent articles, I have been discussing how artificial intelligence is beginning to shift an important frontier in IT and Telecom operations. First, we looked at what happens when agents stop merely recommending and progressively take part in decisions. Then, drawing on the TM Forum’s Autonomous Networks journey, we saw in autonomous networks: an architecture prepared for autonomy that reaching higher levels of autonomy requires much more than simply adding more sophisticated agents. You need to prepare the architecture, organize knowledge, and build context so that decisions can be made safely.
That evolution now leads us to another problem, perhaps a less obvious one. As agentic AI spreads across companies, we will hardly have a single agent responsible for understanding the entire operation. The most likely scenario is the existence of several specialized agents, developed by different vendors or by the organizations themselves, each acting on certain systems, technologies, processes, or domains.
That makes a lot of sense. An agent specialized in Kubernetes may know the workings of clusters and containers in depth. Another may be prepared for IP networks, while different agents act on cloud, security, databases, applications, ServiceNow, or specific observability platforms. In Telecom, this specialization may extend further to access, transport, core, OSS, BSS, and other domains.
The problem appears when we confuse the individual intelligence of these agents with the intelligence of the operation as a whole.
In practice, an incident can cross different domains of the operation, regardless of how we distribute responsibilities among teams, tools, or vendors. A problem can start in an infrastructure component, produce symptoms in another domain, degrade an application, and finally affect a service used by the customer. Each agent may correctly interpret what is happening within its specialty and yet none of them, alone, understands the complete incident.
In a way, this problem is not new. Operations have lived for years with silos of tools, data, and teams. Monitoring has one view, observability another, ITSM holds additional information, inventory systems know part of the topology, and specialists accumulate knowledge that is often not formally recorded in any of these environments.
AI can help reduce that fragmentation, but there is also a risk of simply reproducing it on a new layer.
Today we have silos of tools and data. Tomorrow we may also have silos of intelligence.
This risk grows precisely because agents are becoming more capable. The better an agent performs its function within a given domain, the easier it will be to conclude that the domain is sufficiently automated. However, optimizing each part of the operation individually does not guarantee that the decisions made by those parts are coherent when analyzed together.
Imagine that an agent responsible for a given application identifies degradation and concludes that restarting a service is the best response. At the same time, another agent notices an anomaly in the infrastructure that supports that application, while a third identifies a recent change in a related component. Each has relevant information, but the best decision depends on the ability to relate them.
The question is then no longer just how much each agent knows, and starts to include what agents can understand together.
Distributed intelligence requires shared context
The first answer to this problem is usually orchestrating agents in production. If we will have many agents, we need mechanisms able to coordinate them, define responsibilities, and let them exchange information.
That will certainly be necessary, but coordination alone does not solve the whole problem.
Two agents can exchange messages perfectly and still interpret reality in different ways. One system may call a given element a service, another a resource, and a third may use completely different identifiers to represent the same entity. More importantly, each agent may know only the relationships available within the platform or domain it has access to.
To collaborate effectively, agents need to share more than messages. They need to share meaning.
Knowledge plane: building a shared view of the operation
This is why concepts such as knowledge plane, ontologies, and knowledge models are starting to gain relevance in the discussion on Autonomous Networks.
As we saw in the previous article, the knowledge plane seeks to turn fragmented data into contextualized knowledge that artificial intelligence can reuse. The TM Forum has been highlighting this need as part of the evolution of autonomous networks, allowing different systems and agents to understand the environment, reason about the information available, and coordinate decisions across different domains.
For that to be possible, it is also necessary to represent in a structured way what the organization knows about its own operation. This is where knowledge models and ontologies come in. In simplified terms, a knowledge model organizes the main elements of a given domain and the relationships among them. An ontology adds a more formal and shared definition of those entities, relationships, and meanings, creating a common vocabulary that different systems and agents can interpret.
In a Telecom operation, for example, this can help different intelligences understand that certain network resources support a service, that this service serves certain customers, and that a change to one component can have effects on other related elements. Instead of each agent interpreting these relationships only from the information available in its own platform, there is a shared reference for what the elements represent and how they relate.
This point connects directly to a distinction I have been exploring throughout this series. Technical knowledge and operational context are not the same thing.
An agent’s technical knowledge can be extremely sophisticated and, to a large extent, reusable across organizations. How Kubernetes, a cloud platform, or a given network protocol works does not change completely from one company to another. What changes is how these technologies are combined in each environment, which components depend on one another, which services use a given infrastructure, what was changed recently, and which relationships matter at that moment.
That context belongs to the operation.
That is why simply putting several digital specialists in conversation does not guarantee a systemic view. If each one receives only the view offered by its tool, we can end up with an architecture made of extremely competent agents that still see only different fragments of the same reality.
The challenge becomes building a contextual foundation that makes it possible to relate those perspectives. Alarms, events, metrics, changes, topology, inventory, tickets, and other information stop being just data coming from distinct platforms and start making sense when we can establish the relationships between them.
Those relationships can come from different sources. Some can be discovered dynamically by analyzing data, while others represent deterministic knowledge about the environment: one component depends on another, a given resource supports a service, two elements have a known relationship, or a certain sequence of events has a specific operational meaning.
This combination is particularly important because not all the knowledge needed to operate an environment has to be inferred by artificial intelligence. Many relationships are already known to the organization and can be explicitly represented, making the context more reliable and reducing the need for each agent to rebuild on its own what the company already knows about its own operation.
The desired outcome is not to make all agents the same or give them indiscriminate access to all information. Specialization will remain important. The goal is to let different forms of intelligence work from a sufficiently consistent understanding of the relationships that cross their domains.
The more specialized the agents are, the greater the need for a shared view of the operation.
This matter becomes even more important in heterogeneous environments. A large organization will hardly use agents from a single vendor. Observability platforms may offer their own agents, cloud providers will have others, ITSM tools will incorporate agentic capabilities, and corporate models may coexist with solutions developed in-house.
In that scenario, locking operational knowledge into each agent individually creates not only a technical problem, but also a strategic one. If all the understanding of a given part of the operation is embedded in a specific platform, switching technology can mean losing part of the context built over time.
The challenge is not having more agents, but making them understand the same operation
This perspective changes how we can think about the architecture of future agentic operations. Instead of imagining one large central agent able to know everything, we can have multiple specialists working on different domains, but supported by mechanisms that allow sharing the context needed when a decision crosses those boundaries.
It is an architecture closer to how complex organizations themselves work. Specialists continue to exist because deep knowledge is necessary, but more complex incidents require different areas to build a common understanding of the problem before deciding.
The difference is that we are starting to reproduce this dynamic among artificial intelligence systems as well.
This creates new requirements for integration, interoperability, and governance, but above all it reinforces the importance of a layer able to relate what is happening in different parts of the environment. Technical knowledge will remain distributed among specialized agents, while operational context will need to be built and continuously updated from the organization’s specific reality.
This separation also helps reduce dependence on a given technology. An agent can be replaced by a more capable one in the future without requiring all knowledge about the operation to be rebuilt from scratch. New agents can consume the existing context and contribute new information, while the organization preserves what it has learned about its own environment.
It does not mean all agents will need to access a single database or that there will necessarily be a central platform responsible for all decisions. Distributed architectures will continue to make sense and different models will certainly emerge. The most important principle is another: intelligence can be distributed, but there needs to be some way to share the meaning and relationships needed to understand the operation beyond the limits of each domain.
This may be one of the most important changes agentic AI brings to operational architecture. For many years, we invested in specialized tools and then built integrations to make data flow among them. Now we are starting to face an additional challenge: it is not enough to make data flow. We need to let different intelligences interpret it within a common context.
The TM Forum has been advancing in precisely this direction by relating knowledge planes, ontologies, and contextualized knowledge to the evolution of autonomous networks. Recent cases presented in the ecosystem show the search for a shared understanding of services, customers, and operations so that agents can reason more consistently across different domains.
This discussion is still evolving and we will certainly see different approaches to solving the problem. But one conclusion is starting to look increasingly important.
Adding intelligence to each domain can make each part of the operation more capable. Building shared context is what can make those parts intelligent together.
As we move in that direction, another question will inevitably arise: even when agents have enough context to make a decision, how much control are we really willing to hand over to them?
That will be the topic of the next article.
From vision to practice: ARGUS
One of the risks of adopting specialized agents is reproducing, on a new technology layer, the same information silos that already exist in organizations. Each agent may know its domain very well and still have a limited understanding of what is happening in the operation as a whole.
ARGUS helps address this challenge by connecting information from different tools, correlating events, and representing relationships among components, systems, and services. This shared context can support both human teams and the AI agents that need to understand the environment before recommending or executing actions.
This approach also relates to the knowledge plane concept discussed by the TM Forum, although it is not the same as the full scope of that architecture. With AgentOps, we add another dimension to the challenge: besides sharing operational knowledge with agents, we need to track how these different intelligences act, interact, and produce results.
The goal is to prevent the multiplication of agents from resulting in an even more fragmented operation, with new intelligences working in isolation.
Learn about ARGUS and see how it works in practice.
About the author
Paulo Florêncio de Menezes is an entrepreneur, partner, and co-founder of companies such as Target Solutions, BiPTT, and ARGUS.
He holds a degree in Data Processing from the Federal University of Amazonas (UFAM), an MBA in Business Management from Fundação Dom Cabral (FDC), and a Professional Master’s in Economics from Fundação Getulio Vargas (FGV).
In his Master’s research, he developed the IBEOP-IA (Brazilian Index of Potential Occupational Exposure to Artificial Intelligence), investigating the potential exposure of Brazilian occupations to AI capabilities by combining occupational data, artificial intelligence patents, and natural language processing techniques.