IA Agêntica
Autonomous networks start with architecture, not agents
Reaching higher levels of autonomy does not depend only on smarter agents. It depends on preparing data, processes, integrations, and context so that decisions can cross the different domains of the operation.
When automating is no longer enough
In the last article, I discussed a question that is gaining importance as we move forward with agentic AI adoption: are we really prepared to give artificial intelligence autonomy in critical environments? The question came out of the discussions I followed during Telco Transformation Latam and led to an important reflection.
The more autonomy we intend to give agents, the greater our capacity must be to provide context, governance, and security so that they understand the environment before deciding and acting.
But that discussion naturally leads to a second question: how does an operation actually evolve toward higher levels of autonomy?
In the Telecom sector, this question has been structured by TM Forum through the Autonomous Networks journey, which sets a reference for the evolution from predominantly manual operations to networks capable of perceiving changes, making decisions, and executing actions with increasing levels of autonomy.
The model defines six levels, from L0 to L5, but it would be an oversimplification to read them only as a scale that measures how much a company has already automated. In the early levels, people still have a significant share in observation, analysis, and decision making. As maturity increases, systems progressively take over some of those functions. At L2 we already find partial automation in certain scenarios and, at L3, machines take a more direct part in analysis and decision, although human supervision still plays a relevant role.
The jump to L4 is particularly important because it involves intent-driven operations, predictive analytics, continuous learning, and closed loops capable of managing services with a much greater degree of autonomy.
TM Forum itself characterizes this evolution as a shift from automation processes previously defined by humans to effective forms of autonomous decision making.
That does not mean an operator simply moves from one level to the next until its entire network can be declared L4. Evolution happens by specific domains and scenarios. An organization may have different levels of autonomy in fault management, optimization, provisioning, or assurance, for example, advancing progressively as it manages to demonstrate safety, reliability, and value.
This perspective also helps avoid an interpretation that tends to gain strength with the popularization of agentic AI: imagining that reaching an autonomous network simply means adding ever more sophisticated agents to the operation.
An agent can analyze a failure, query systems, recommend a change, and even receive permission to execute certain actions. All of this can represent important progress, but end-to-end autonomy involves a bigger problem, because incidents and services rarely respect the boundaries of the technology domains in which we structure our operations.
Consider a failure that starts in the access network, produces symptoms in transport, affects an application, and finally compromises the experience of a given group of customers. We can have excellent automation mechanisms in each of those areas and still depend on people to realize that the signals observed on different platforms are part of the same problem. To move toward an autonomous response, it is necessary to understand the relationships between those components, identify the services involved, and assess the consequences of an action before executing it.
The TM Forum reference architecture reflects this need by treating Autonomous Networks as intent-driven, context-aware systems supported by knowledge and intelligence. The question is no longer just where we can place an agent, but which process or service we want to make progressively more autonomous and what the architecture needs to offer for that to happen safely.
This is where one of the most interesting concepts in the recent evolution of this architecture appears: the knowledge plane.
From operational data to knowledge about the operation
Telecom operations have always produced large volumes of data, and that volume has grown significantly as new technologies and specialized systems were added to the environment. Alarms, metrics, logs, configurations, inventories, topologies, tickets, changes, and service information are available on different platforms, often in real time.
Having access to that data, however, does not mean understanding what is happening. During an incident, one platform may record packet loss while another reports a recent change on a nearby device. An observability system identifies degradation in an application and, shortly after, complaints about a certain service begin to appear. Individually, each piece of information describes a part of reality. The challenge is to discover which of them are related and what that combination reveals about the problem.
This is the work that experienced specialists do every day. They know the architecture, know which systems depend on others, remember recent changes, and recognize behaviors learned over time. When they investigate an incident, they do not analyze only the available data. They interpret that data based on the knowledge accumulated about that specific operation.
In previous articles, I have been calling this difference operational context. Technical knowledge explains how a given technology works or which causes usually produce a given type of failure. Operational context explains how that technology sits in that environment, which components relate to it, what has changed recently, and which services may be affected.
In 2026, TM Forum deepened the concept of the knowledge plane as a layer capable of turning fragmented data into contextualized, reusable knowledge, allowing different systems and agents to use that knowledge to reason, coordinate actions across domains, and produce more explainable decisions.
The proposal points to an important shift: more autonomous operations need to manage not only data and processes, but also the knowledge continuously produced from them.
There is an important convergence between this proposal and the concept of operational context. In practical terms, one of the essential functions of a knowledge layer is to allow the signals observed at that moment to be interpreted based on what is already known about the architecture, the relationships, the dependencies, the services, and the history of that environment.
If a given piece of equipment fails, for example, it is not enough to know the event it recorded. To understand the incident, it may be necessary to know which components depend on that resource, which services use that path, which changes happened recently, and whether other signals observed on different platforms are symptoms of the same problem. These relationships are what help turn a collection of information into operational knowledge useful for a decision.
That knowledge also needs to keep up with the dynamics of the environment itself. Networks change continuously, configurations are altered, elements are added, services migrate between infrastructures, and new dependencies appear.
If progressively more autonomous systems use these relationships to make decisions, the quality and freshness of the context directly influence the reliability of those decisions.
The challenge of legacy environments and multiple vendors
The challenge becomes even greater because operators are not building this architecture from a blank sheet. Decades of investment have produced environments made up of OSS, BSS, inventory systems, monitoring and observability tools, automations, customer service platforms, and technologies from different vendors. Part of the operational knowledge may also live in procedures developed by the teams, in incident history, and in the experience accumulated by specialists.
Preparing an operation for higher levels of autonomy therefore involves some foundational actions that may seem less sophisticated than deploying new agents, but are equally important: integrating tools, organizing data, exposing APIs, representing relationships and dependencies, and creating mechanisms so that this knowledge can be used by different parts of the operation.
There is also a strategic consequence. Tools change, AI models evolve, and new agents will be added to the environment. But the architecture, dependencies, history, services, and relationships that characterize that operation belong to the organization itself. That is why operational knowledge needs to remain available and reusable, regardless of the specific technology being used to analyze it.
This may be one of the most interesting implications of the knowledge plane concept: allowing people, automations, and different forms of intelligence to work on a more consistent understanding of the same operation, as I explore further in The path to autonomous networks goes through shared operational context.
The journey to autonomy starts before autonomy
If the evolution to autonomous networks requires an architecture capable of organizing knowledge and context, the next question is where to start. And here there is an important characteristic in the TM Forum approach: higher levels of autonomy do not need to emerge as the result of one big project that transforms the entire network at once.
Evolution can start with concrete scenarios. Fault management is a good example. A single incident can generate dozens or hundreds of alarms spread across different platforms, requiring specialists to identify relationships, assess dependencies, investigate recent changes, estimate impact, and decide which action to run. Making this process progressively more autonomous means improving not only the execution of the response, but mainly the ability to understand the incident before acting.
Automating only the last step may simply increase the speed at which an inadequate decision is executed. Autonomy needs to be built on a growing capacity to perceive, correlate, understand, and assess consequences. For that reason, known, well understood, lower-risk processes can initially receive higher levels of autonomy, while critical or ambiguous situations continue to depend on human participation.
This approach also helps prevent Autonomous Networks from becoming a technology race to reach a given maturity level. The goal should not be to reach L4 just because the market set that level as a reference. Progress needs to produce concrete results for the operation and for the business.
In June 2026, TM Forum reported that 81% of the operators surveyed intend to reach L4 or higher levels by 2030. At the same time, the discussion is no longer motivated only by cost reduction and operational efficiency and now incorporates goals such as resilience, service quality, customer experience, and the ability to introduce new services with less complexity.
This puts the journey in a more adequate perspective. Reaching L4 does not depend on finding an AI model powerful enough or on deploying a platform capable of solving the entire operation. It requires combined evolution of architecture, data, processes, knowledge, and governance, applied progressively to the scenarios in which autonomy can generate value.
AI agents will play an important role in this transformation, but more capable agents do not eliminate the structural problems that already exist in the operation. If data remains fragmented and important relationships are not available, intelligence will also work from a fragmented understanding.
That is why perhaps the main transformation needed to reach autonomous networks happens before autonomy itself. We need to build operations capable of continuously representing their reality, connecting data, relationships, and knowledge so they can be understood by people, by today’s automations, and by the agents that will progressively take part in decisions.
Autonomous networks do not start when we give agents permission to act. They start when we build an architecture capable of providing enough knowledge and context for autonomous decisions to be made with confidence.
This is the foundation on which autonomy can grow progressively, without losing sight of what really matters: making the operation more efficient, reliable, and able to respond to the needs of the services it sustains.
From vision to practice: ARGUS
The evolution toward autonomous networks requires more than introducing AI agents capable of executing specialized tasks. For the different components of the operation to act in a coordinated way, it is necessary to build a shared knowledge base about the state of the network, its relationships, and its dependencies.
This need is directly related to the knowledge plane concept discussed by TM Forum and also to the proposal of ARGUS.
Through its AIOps capabilities, ARGUS connects information from different operational sources, correlates events, incorporates known rules and relationships of the environment, and helps turn distributed signals into shared operational context. That context can support specialists, automations, and agents that need to understand the situation before recommending or executing actions.
ARGUS does not intend to represent, on its own, all the components of a knowledge plane. Its contribution lies in one relevant layer of that architecture: relating operational information and making a more consistent understanding of the environment available to different forms of intelligence.
With AgentOps and AI Gateway, this proposal can be extended to also include the orchestration, observability, and governance of the agents that start taking part in the operation.
The combination of shared operational knowledge and control mechanisms over how agents act is one of the conditions for advancing on the autonomy journey without multiplying silos of information and decision.
In the next article, I will go deeper into a consequence of this transformation: the more specialized agents we put into the operation, the greater the risk of creating new silos of intelligence.
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.