What I find particularly important in your explanation is the distinction between:
That framing helps make the challenge much clearer.
If I understand your point correctly, the real architectural problem is not simply how to automate individual domains, but how to preserve service/session coherence across multiple autonomous domains - especially when adaptation must happen in real time, under performance constraints, and without creating excessive control-plane chatter.
Your example of a session moving from one access domain to another (e.g. fixed to mobile) is especially powerful, because it shows that the real challenge is not only local self-healing, but also cross-domain continuity of intent fulfilment.
This is exactly where I think the discussion becomes interesting.
In that sense, I wonder whether what emerges is not a single OCS, but something closer to a federated set of cognitive functions across domains - each domain reasoning locally, while coherence is maintained through bounded, event-driven, policy-aware coordination.
I would be very interested to hear how others in the community see that.
Original Message:
Sent: Mar 27, 2026 18:11
From: George Glass
Subject: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?
A very interesting post Ngoc. I am not sure I can answer all of your questions, but I will lay out a few principles of the autonomous networks architecture that address some of the issues and ideas you raise.
Let's consider the TM Forums Autonomous Networks architecture, which is based on the Open Digital Architecture (ODA).

The design pattern for autonomous networks is recursive across the business, service and resource operations layers and domains therefore it's domains (Engagement, Party, Commerce, Production and Intelligence). The architecture is intentionally decoupled between the domains (and also the components – see note later). It is built around, and supports, intent based operations (at all levels), closed loop controls (multiple levels), intelligent orchestration (again at multiple levels to cover, product, service and resource orchestration and decomposition) and self-healing domains (which themselves have configuration, orchestration, monitoring and reporting capabilities within them).
The building block of ODA is the component – which encapsulates and exposes business capabilities via industry standard (and agreed) open APIs (these typically are REST based but increasingly we are experimenting with agentic interfaces e.g. MCP or A2A). Within a component – to enable the business capability we originally had a set of systems, people, processes and data. With the emergence of AI, we have expanded the definition of people to include agents i.e the "people" can be carbon (human) or silicon (AI agents).

To further understand how autonomous networks will work you have to think of the network as being made up of multiple domains that utilize different technologies and each having an underlying set of connections made up from different technologies that are "static" and managed in a traditional way based on planning, installation and then put into operation where they are monitored reactively and proactively for performance and capacity. For an autonomous network there is also the concept of the session that runs over the "static" network but in itself is "dynamic". It is the session that is "intent-based" where the user describes their connectivity in terms of the outcome they want, not the technology used to deliver the outcome. And it is the "dynamic" nature of the network session that enables a network, from a user's perspective or the operator's perspective, to become autonomous.
What we are seeing emerging are patterns for the use of AI within the architecture. Many of the intent-based requirements can be implemented with generative AI, many of the complex data processing functions leverage predictive AI e.g. anomaly detection within a network and now we see agentic capabilities being embedded into orchestrators, domains and even resources themselves. This means that the functionality of ODA within the various domains Party, Commerce, Production is not always fully defined up front – perhaps aligning with Stefano Talamo's comments.
To illustrate this point, let's assume we have a network session running that is using a specific access domain for example, a fixed line connection. Within that access domain an AI enabled anomaly detection function will be encountering known and new anomaly conditions and is learning, or is being trained, how to react appropriately to these anomaly condition over time as it builds its intelligence to enable it to repair itself i.e. become "self-healing"
While this domain is learning to self-heal, it is also reporting to a cross-domain controller (an intelligent on its current status. If it does not repair itself in time the cross-domain controller (itself AI enabled) will then make a decision on how to best deal with the situation. With a traditional network, or automated network, the user is likely to experience a service outage, as the access path and technology was predetermined when the session was established. So if the network connection breaks or fails the service fails and the user notices a problem.
However, with an autonomous network the cross-domain controller (remember it is figuring out how to manage this dynamic network session in real time) will re-examine its intent based request for a service (based on a set of service characteristics e,g bandwidth, latency, QoS etc.), and either activate another similar connection service (using an alternative fixed line connection) or …. and this is where autonomous networks get interesting, it, the cross-domain controller, makes the decision to switch to a mobile access connection that can meet the same service characteristics that the previous fixed line access domain was initially achieving before its service degraded. For this to work fast enough so that the user does not notice the change in access domains I would argue that it needs to happen in less than 100ms. To achieve this the cross-domain controller needs to know all of the access domains available to it when the session is initiated and retain that information for the duration of the session.
This is where it gets interesting… I have heard suggestions that we put agents in every resource (I'm fine with that) and the cross-domain controller becomes an agent (hmmm…..) that can discover all of the domains (agents) and their characteristics at session startup (sort of okay with this). The cross-domain controller selects the preferred initial domain (yes!) and the session starts. The suggestion then is that the agent in the cross-domain controller can retain communication (MCP or A2A) with the selected and alternate domain agents so if the initial preferred domain degrades it can switch control to one of the alternative domains. This is where I get nervous… within a network we need to use the network to manage both the session and the control. If the control traffic is prolific, as will be the case for the multiple simultaneous sessions running over a network at any given time, we will need to manage the communication between domains. So, I am fine with the cross-domain controller identifying all available domains at session start up and retaining that information. It then selects its preferred domain, and the remaining domains only communicate with the cross-domain controller if their status (discovered by the cross-domain controller) dips below the service characteristics that the cross-domain controller requested for the session (in architectural terms, an event-based approach to status updates).
So, what I am showing is that if we consider an autonomous network session the intelligence of the architecture emerges and is not fully defined up front. The control points of the architecture, the various orchestrators and control loops operate with constraints (policies) but do not enforce a design of an adjacent domain, because that domain itself is autonomous. This means that intelligence is federated across the architecture.
I would argue that there cannot be one centralized intelligence engine or orchestrator within the ODA based Autonomous Networks architecture as my network may, and in many cases likely will, extend beyond the boundaries of my organization. So, to achieve the level of intelligence required across the entire network, what we have is a federated set of autonomous domains (or components) each of which could be thought of as having its own operational cognitive system (OCS).
The power of ODA with respect to autonomous networks is in the decoupling and recursive patterns of a set of intelligent domains and components, where you can treat a domain or a component as a "black box" that delivers or supports a set of business capabilities that themselves are implemented via systems, people or agents, process and data. The overall intelligence of the architecture effectively emerges over time as the various domains learn how to deliver their particular business capabilities.
------------------------------
George Glass
TM Forum
Original Message:
Sent: Mar 27, 2026 15:29
From: James Crawshaw
Subject: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?
Hi Ngoc. Really interesting posts. I don't really have the expertise to answer your questions.
C'mon @Andy Tiller, @George Glass, @Guy Lupo - please share your thoughts.
------------------------------
James Crawshaw
Omdia
Original Message:
Sent: Mar 24, 2026 23:28
From: Ngoc Linh Nguyen
Subject: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?
Building on the discussion so far, I recently came across an interesting perspective shared by Stefano Talamo from Fibercop S.p.A.
The idea is that coordination in Autonomous Networks may not need to be fully designed upfront, but could instead emerge as a form of collective intelligence, similar to how complex systems like ant colonies or beehives operate.
At the same time, this perspective also highlights the importance of a policy layer, acting as a set of guiding principles that shape and constrain this emergent behaviour.
This introduces a very interesting architectural tension:
Should coherence in Autonomous Networks be primarily designed, or should it emerge from distributed autonomous domains under shared constraints?
In relation to the earlier discussion on federated operational cognition, this raises another question:
Could an architecture such as an Operational Cognition System (OCS) be understood not as a centralized intelligence, but as a way to enable and guide emergence, rather than replace it?
I would be very interested to hear how others in the community see this balance between emergent coordination and architectural structuring.
------------------------------
Ngoc Linh Nguyen
Vietnam Posts and Telecommunications Group (VNPT)
Original Message:
Sent: Mar 23, 2026 21:01
From: Ngoc Linh Nguyen
Subject: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?
Following a recent discussion on Autonomous Network interconnection and the idea of "federated operational cognition", I would like to share a conceptual perspective that emerged from that exchange.
The discussion highlighted several converging directions:
· intent-based interconnection rather than topology exchange
· domain-level autonomous control loops
· agent-to-agent cooperation across administrative boundaries
· policy-mediated coordination and orchestration
Taken together, these suggest that the challenge is not only enabling autonomy within domains, but also ensuring coherent system-level decision-making across distributed intelligence.
The emerging question: If multiple autonomous domains - potentially across operators - are each running their own closed-loop control and decision systems, so what is the architectural mechanism that ensures coherence across these distributed decisions?
Current approaches (intent APIs, orchestration layers, agent coordination) provide important building blocks. However, they are often described as interfaces and interactions, rather than as a unified system-level architecture.
A conceptual perspective: Operational Cognition System (OCS)
One way to think about this is to treat the operations environment as an Operational Cognition System (OCS). In this view, OCS is not a centralized controller, but a system-level architectural model that integrates:
· distributed autonomous control loops operating within domains
· shared intent and policy reasoning across domains
· cross-domain coordination mechanisms to manage dependencies and conflicts
The role of such a system would be to continuously:
· perceive operational state across domains
· interpret service, customer, and business intent
· coordinate decisions across distributed agents
· maintain alignment between autonomous execution and system-level objectives
The notion of federated operational cognition suggests that coordination emerges from interaction between autonomous domains.
The question is whether this can (or should) be made more explicit: Can we move from loosely coupled federation toward a structured cognition architecture, where the relationship between intent governance, domain autonomy, and cross-domain coordination is clearly defined?
This perspective raises several questions:
· Where should operational cognition reside - fully distributed within domain agents, or partially structured at a higher level?
· How do we ensure global service coherence while preserving domain autonomy and sovereignty?
· What is the architectural boundary between intent governance and autonomous execution?
· How should conflicts between local optimisation loops be detected and resolved?
· Could a "cognition layer" become a first-class concept in Autonomous Network architectures?
This is still an early conceptual exploration, but it seems to align with many of the directions currently discussed around:
· Autonomous Networks (L4+)
· intent-driven operations
· multi-agent coordination
· cross-domain orchestration
I would be very interested to hear perspectives from the community:
· Does the idea of an Operational Cognition System resonate as a useful abstraction?
· Or is "federated cognition" better left as an emergent property of loosely coupled domains?
· Are there existing frameworks or implementations that already address this at a system level?
Figure: Conceptual view of the Operational Cognition System (OCS), illustrating the continuous cognition loop that integrates perception, intent-driven reasoning, governance, and autonomous execution across domains.
#DigitalTransformationMaturity
------------------------------
Ngoc Linh Nguyen
Vietnam Posts and Telecommunications Group (VNPT)
------------------------------