IA Agêntica
Autonomous networks require shared operational context
Data can be available on dozens of platforms and yet none of them has a complete view of what is happening. For people, automations, and agents to decide better, fragmented information must be turned into a shared understanding of the operation.
Having all the data does not mean understanding what is happening
In recent articles, I have been discussing some of the changes that artificial intelligence is starting to produce in IT and Telecom operations. We talked about autonomy, about the architecture needed to support it, about the risk of creating new silos as specialized agents multiply, and, more recently, about how much control we are prepared to hand over to those agents.
There is, however, a question that runs through practically all of these discussions and is perhaps prior to artificial intelligence itself: how do we build a sufficiently consistent understanding of what is happening in the operation?
In complex environments, information is rarely concentrated in a single place. One platform monitors equipment and interfaces, another tracks applications, observability tools collect metrics, traces, and logs, the ITSM records incidents and changes, while other systems hold information about inventory, topology, security, customers, or performance. Each can perform its function very well and still none of them sees the complete problem on its own.
During an incident, this fragmentation becomes particularly evident. A device may generate a sequence of alarms, another platform may identify degradation in related components, the observability system may notice a change in an application’s behavior, and the ITSM may record tickets associated with the same service. Individually, all of those signals may be correct. The challenge is to find out which ones are part of the same problem, which are consequences, and what really helps explain what happened.
Over the years, we have invested heavily in expanding visibility into infrastructure, applications, and services. That was essential to deal with increasingly distributed and dynamic environments. But increasing the number of available signals does not eliminate the effort needed to interpret them. In some cases it produces the opposite effect: we have more information and, at the same time, more work to find out which information matters.
That is why a single view of the operation should not be confused with putting all the data on the same screen.
A shared view does not emerge when we can see all the information in the same place. It emerges when we can understand the relationships between them.
Imagine three platforms report a failure in a network component, a degradation in a given application, and an increase in the number of complaints related to a service. Bringing the three records together improves visibility, but it does not answer the main question: is there a relationship between them? For that, we need to understand dependencies, recent changes, the behavior of related elements, and other characteristics specific to that environment.
It is in this process that we begin to move from observing data to building operational context.
Today, much of this work is still done by people themselves. An experienced specialist does not look only at the alarm that shows up on the screen. They know the architecture, remember recent changes, understand dependencies, recognize patterns, and query different systems to complete what they cannot yet explain.
An important part of the operation’s context therefore exists in the combination of what tools report and what people know how to relate. This becomes a limitation when we intend to increase automation and, above all, when AI agents start to take part in analysis, decision, and execution.
If we want systems to understand enough to decide, we need to make explicit a portion of the context that today is still built implicitly by people.
Operational context is not a piece of data waiting to be found
With the popularization of LLMs, RAG, vector databases, and agents able to query different sources, it has become easier to imagine systems that look for the information they need before answering or making a decision. That capability is extremely useful, but there is an important difference between retrieving information and building context.
A document can explain how a given device works. A knowledge base can contain procedures for a known failure. A history can show how similar incidents were resolved. All of this enriches the analysis, but it does not necessarily represent the current state of that operation.
Context needs to combine this relatively stable knowledge with what is happening now: recent events, the state of components, changes made, relationships between resources and services, known dependencies, and information coming from different platforms.
That is why operational context should not be treated as just another database. It is the result of a continuous process of construction and updating.
Consider a simple example. An alarm reports that component A has failed. A known relationship shows that B depends on A. Another tool identifies degradation in B, and a third system records impact on a service C, which uses B. Separately, we have three pieces of information. Related, they produce a far more useful operational hypothesis about the chain of consequences of that incident.
In this example, part of the context was produced dynamically by the events and part came from existing knowledge about the environment. That combination matters because not everything needs to be inferred by artificial intelligence.
An organization already knows many deterministic characteristics of its operation: dependencies between components, resources that support certain services, known relationships between events, and conditions that must be considered during an investigation. Making this knowledge explicitly available avoids a model having to rediscover, at every incident, what the company itself already knows. At the same time, environments change and new correlations emerge, requiring this knowledge to be continuously combined with dynamic information.
This discussion is appearing more and more explicitly in architectures aimed at autonomous operations. In August 2026, TM Forum published the guide Context Management for AI-Native Operations, which treats context as the information needed to understand what is happening and decide what to do. The proposal seeks to make more explicit a process that still depends heavily on NOC professionals: gathering information from multiple sources, relating it, building a coherent view of the situation, and making it available to different systems and agents.
The concept is close to another discussion we covered earlier, the knowledge plane, a layer meant to turn fragmented data into contextualized knowledge that different forms of intelligence can reuse. They are complementary perspectives: one emphasizes building and managing context; the other, an architecture able to represent and reuse operational knowledge.
There is an especially important consequence for critical operations: this knowledge does not need to be made up only of inferences produced by AI. Deterministic relationships, rules, policies, models, and accumulated knowledge about the environment can also take part in this construction.
The more reliable this combination is, the better the conditions for people, automations, and agents to interpret the same situation before deciding what to do.
Context must belong to the operation, not to a tool
When we start treating context as part of the operational architecture, another question arises: where should that context live?
An observability tool knows its applications, a network system knows its elements, the ITSM knows incidents and changes, and, progressively, each of these platforms will be able to incorporate its own agents and intelligence mechanisms. If context remains restricted to each of them, however, we run the risk of reproducing in artificial intelligence the same fragmentation that already exists among the tools.
As we discussed in the previous article about silos of intelligence, specialized agents will remain important. The problem appears when a decision depends on information that crosses networks, applications, cloud, security, ITSM, and other domains.
Shared operational context does not necessarily mean building an enormous central database holding all the company’s data. It means creating mechanisms able to relate information and make a sufficiently consistent understanding of the situation available to whoever needs it.
The sources continue to exist, specialized systems continue to perform their functions, and agents can remain distributed. What needs to cross these environments is the operational meaning required to understand how what happens in one part may be related to what is being observed in another.
This need also appears in the evolution of TM Forum’s Autonomous Networks architectures, which move from intelligence within specific domains toward cross-domain coordination. But the problem is not exclusive to Telecom operators nor does it depend on fully adopting that architecture. Any complex operation made up of multiple technologies and tools faces some version of the same challenge.
That is also why operational context should be treated as an asset of the organization, not as the property of a given tool or agent.
Tools will be replaced, AI models will evolve, and new agents will be added. The architecture, services, dependencies, history, and accumulated knowledge about how that operation works, however, continue to belong to the company. Preserving this knowledge in a reusable way creates a foundation on which different forms of intelligence can work.
A specialist can use it to investigate an incident, an automation can query it before executing an action, and an agent can incorporate it into its reasoning before producing a recommendation. This does not mean everyone must receive exactly the same information. Governance, security, and purpose continue to determine what each person or system can access.
For years, a large part of the integration effort focused on making systems exchange data. APIs and connectors remain essential, but autonomy requires something additional: systems need to be able to use that data within a coherent understanding of the situation they are acting on.
That is the point at which integration and context stop being synonyms.
We can integrate dozens of platforms and still have isolated interpretations. We can gather millions of events and still depend on a person to find out which ones are part of the same problem. We can make all that data available to a sophisticated agent and still require it to rebuild on its own the relationships that explain that operation.
The leap happens when we manage to turn this information into a continuously enriched, shareable operational representation.
The path to autonomous networks does not run only through making systems smarter. It runs through allowing different intelligences to understand the same operation.
This principle connects the discussions of recent articles. Autonomy requires trust, trust depends on the quality of decisions, and better decisions depend not only on an agent’s technical knowledge, but also on the quality of the context available about that environment at that moment.
From vision to practice: ARGUS
In a network operation, different tools may present correct information about their respective domains and still none of them offers a sufficient understanding of the problem as a whole. This limitation becomes more important as automations and agents start to take part in decisions.
It is in this scenario that the proposal of ARGUS fits. The platform works on top of existing tools, integrating and correlating information from different sources and relating what is being observed to previously structured knowledge about the operation’s components, services, and dependencies.
The result is the construction of an operational context that is not limited to gathering data in a single environment. It seeks to represent how the different elements relate and how those relationships help interpret events, changes, and incidents.
This approach converges with needs present in the Context Management and knowledge plane concepts discussed by TM Forum. ARGUS does not replace those broader architectures, but it can contribute to their implementation by making shared operational context available to specialists, automations, and AI agents.
With AgentOps, the proposal also covers the monitoring and governance of the agents that use this context to act on the operation.
The challenge of autonomous networks, therefore, is not only to allow more agents to carry out activities. It is to ensure they can work from a sufficiently consistent understanding of the network, with adequate mechanisms of coordination and control.
Get to know 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.