TM Forum Community

 View Only
  • 1.  From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?

    Posted 9 days ago

    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.

    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)
    ------------------------------


  • 2.  RE: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?

    Posted 7 days ago

    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)
    ------------------------------



  • 3.  RE: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?

    Posted 5 days ago

    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
    ------------------------------



  • 4.  RE: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?

    Posted 5 days ago

    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
    ------------------------------



  • 5.  RE: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?

    Posted 2 days ago

    Thank you George - this is an extremely valuable architectural perspective.

    What I find particularly important in your explanation is the distinction between:

    • a largely static underlying infrastructure, and
    • a dynamic, intent-driven session layer where autonomy actually becomes operationally meaningful.

    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.

    If intelligence is recursive, distributed and domain-specific - and if we do not want to introduce a new centralized "super-controller" - then perhaps the question becomes:

    What is the minimum architectural function needed to maintain coherence across autonomous domains?

    That is increasingly how I have been thinking about the idea of an Operational Cognition System (OCS):

    not as a single intelligence engine,
    but as a cognitive function / architectural pattern that helps reconcile:

    • local domain autonomy
    • session-level intent fulfilment
    • policy constraints
    • and cross-domain operational continuity

    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.

    That raises what is, for me, perhaps the key architectural question:

    In an ODA-based Autonomous Network, should "operational cognition" be understood as a centralized capability, a federated capability, or simply an emergent property of recursive autonomous domains?

    I would be very interested to hear how others in the community see that.



    ------------------------------
    Ngoc Linh Nguyen
    Vietnam Posts and Telecommunications Group (VNPT)
    ------------------------------



  • 6.  RE: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?

    Posted 2 days ago

    Let's distinguish between governance (requiring some centralized control) and runtime operations (which will be decentralized – choreographed, not orchestrated).

    Network and IT workloads in telecoms operate, in practice, in multi‑vendor, multi‑cloud environments. For complex processes spanning multiple IT and network domains, coordination is required between AI agents operating across different domains and vendor stacks. Today, MCP, A2A, and event‑driven architectures provide foundational mechanisms for sharing intent, context, and state between these agents.

    However, this alone is not sufficient to deliver trustworthy AI for telecoms. Agents must integrate with existing IT and network systems; share a common understanding of telecom‑specific language for reasoning and intent expression; and operate with telco‑grade security, observability, and reliability across highly complex, mission‑critical processes. Some of these capabilities - such as shared domain models and ontologies -can be defined up front as common operational context, while others require centralized governance, policy, and lifecycle control (but not centralized runtime decision‑making).

    Recent work in TM Forum's Collaboration Program and Innovation Hub has been extending ODA to address these needs:

    • ODA provides a common language (via SID, eTOM, and the TM Forum Intent Ontology), Open APIs, MCP support in ODA Component specifications and the ODA Canvas, and reference architectures for intent‑driven operations and closed‑loop automation.
    • The AI‑Native Blueprint projects add managed access to LLMs (Model‑as‑a‑Service), data product lifecycle management, and a framework for secure and governed agent interactions.
    • The ODA Canvas is being extended to support automated lifecycle management of AI agents, including Canvas Operators that enable the AI‑Native Blueprint and consistent enforcement of guardrails.
    • The Innovation Hub is building reference implementations that demonstrate cross‑domain, intent‑driven use cases automated by autonomous agents and ODA Components running on an AI‑Native Canvas.

    While there is still work to do, the architectural patterns are becoming clearer. Autonomous domains will combine shared understanding with centralized governance where needed, while operations are choreographed through intent and events-rather than orchestrated by a central brain.



    ------------------------------
    Andy Tiller
    TM Forum
    ------------------------------



  • 7.  RE: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?

    Posted 22 hours ago

    Thank you Andy - this is an extremely valuable distinction.

    I think your separation between governance and runtime operations is particularly important.

    The idea that runtime autonomy should remain decentralized, choreographed through intent and events rather than orchestrated by a central brain, feels both architecturally sound and operationally realistic - especially in the multi-vendor, multi-domain, multi-cloud environments that telecom operators actually have to deal with.

    At the same time, your point also reinforces something I have been trying to better understand: if runtime cognition is distributed, what is the minimum explicit architectural structure needed to keep that distributed autonomy coherent, trustworthy, and governable at scale?

    That, to me, is where the discussion becomes especially interesting. Because I fully agree that OCS should not be understood as a centralized runtime controller. But I also wonder whether there is still a need for something more explicit at the system level - not to make decisions for every domain, but to help ensure that intents remain interpretable across domains, trade-offs remain explainable, policy boundaries remain enforceable, and coherence does not depend purely on emergent behavior alone.

    In that sense, I am increasingly thinking that if something like OCS is useful, it may be better understood not as a "central brain", but as a way to make the relationship between: shared operational understanding, governance and distributed runtime cognition more architecturally explicit.

    Your point about shared models / ontologies, AI lifecycle management, and governed agent interaction is especially helpful in this regard, because it suggests that some of the foundations for this may already be emerging inside the broader ODA / AI-Native direction.

    So perhaps the deeper architectural question is not: "Should AN have centralized intelligence?" but rather: "How much explicit system-level cognition is needed to make decentralized autonomy trustworthy and coherent?"

    I think that is where this discussion becomes very relevant for the next phase of Autonomous Networks.



    ------------------------------
    Ngoc Linh Nguyen
    Vietnam Posts and Telecommunications Group (VNPT)
    ------------------------------



  • 8.  RE: From Federated Autonomy to Operational Cognition: Do Autonomous Networks Need a System-Level "Cognition Architecture"?

    Posted 13 hours ago
    Edited by Andy Tiller 13 hours ago

    Thanks, Ngoc

    Indeed, there is a lot of work going on in ODA to address the above issues.  For example

    • MCP support in the ODA Component specifications enables ODA Components expose tools towards AI agents
    • Architectural patterns for intent-driven operations illustrate closed loop automation among autonomous domains
    • The TM Forum Intent Ontology, enables agents to negotiate intents with precise telecoms understanding
    • The ODA Canvas supports automated configuration, deployment and lifecycle management of agents, integrated within the existing ODA architecture
    • Our AI-native Blueprint project has published architecture patters for the necessary central governance and control of agentic AI in telecoms, including data product lifecycle management, Model-as-a-Service (MODaaS), secure agent interactions and guardrail enforcement, and our Innovation Hub is extending the ODA Canvas reference implementation to support these features


    All of the above will be demonstrated by TM Forum members at DTW this year in Copenhagen, showcasing how AI together with ODA can deliver Level 4 autonomy for scenarios such as dynamic network slicing and fault management.

    There is still more work to do in ODA to support fully AI-native operations; for example, improved support for event-driven architectures, more work on telecoms ontologies, and making ODA itself a data product for consumption by agents running in developer environments.  All TM Forum members are welcome to participate in this work.

    One small additional point, OCS is familiar already as "Online Charging System". These days it's difficult to come up with a telecoms acronym that isn't already taken :-)

    ------------------------------
    Andy Tiller
    TM Forum
    ------------------------------