Pages
More Information

Exosphere Agentic in ODA terms

Where the judgment layer sits in the ODA functional map, and how it composes with the Canvas you run

Exosphere Agentic gives AI agents a governed path into the systems of record an ODA estate already runs, using ODA's own rules. Exosphere Agentic runs on Azure and integrates with the Microsoft AI platform, deployed into the customer's own tenant — so context, data and governance stay where they belong.

Updated

Agents query. The owning block writes.

ODA keeps fast-moving engagement apart from stable systems of record. TM Forum's guidance on the functional blocks (IG1167) has Engagement Management read, while Party Management, Core Commerce Management and Production create, update and delete the data they own. A write needs the business rules that only the owner holds.

Exosphere, the judgment layer inside Exosphere Agentic, applies the same rule to agents. An AI agent sits on the engagement side and can ask anything it is entitled to ask. When it wants to change something, Exosphere routes the request to the owning block's TM Forum Open API, under policy, with the authority and the audit record attached.

  • No side doors. Every change is an Open API operation on the block that owns the record.
  • No new system of record. Party, commerce and production data stay where they are, unchanged.
  • One governed path. Authorise, observe and audit happen in the path of the call, not in a prompt.

Built for the Decoupling and Integration role

In the Exos view, Exosphere fills ODA's Decoupling and Integration role for agentic work. TM Forum guidance (IG1224) describes Decoupling and Integration as able to carry the API interactions between Core Commerce, Production and Intelligence Management. Exosphere adds what agents need on that path.

ODA blockWhat it doesWhat Exosphere adds
Engagement ManagementChannels, care, portals and AI agentsOne governed MCP surface into the estate
Decoupling and IntegrationCarries interactions between blocksThe telecom ontology, the policy decision (execute, route or block), sagas and idempotency, audit lineage
Party, Core Commerce, ProductionOwn and write their recordsReceive governed Open API calls, like any other consumer
Intelligence ManagementFast distributed loops and slow centralised loopsRecommended actions return through the same governed path

The ODA golden rules (IG1171A) put it simply: API first, and decoupled engagement. Exosphere is designed on both.

Exosphere in the ODA functional map

flowchart TB
    subgraph EM["ENGAGEMENT MANAGEMENT"]
        CH["Channels · care · portals"]
        AG["AI agents"]
    end
    subgraph DI["DECOUPLING AND INTEGRATION · EXOS VIEW"]
        EX["Exosphere<br/>TM Forum Open APIs · MCP"]
        GOV["Authorise · observe · audit"]
        ONT["Telecom ontology<br/>shared meaning"]
        EVT["Event mesh"]
    end
    subgraph SOR["SYSTEMS OF RECORD · UNCHANGED"]
        PM["Party Management"]
        CCM["Core Commerce Management"]
        PRD["Production"]
    end
    IM["Intelligence Management<br/>closed loops · insight"]
    RT["ODA Canvas or existing runtime<br/>gateway · identity · observability"]
    CH --> AG
    AG -->|"query and intent"| EX
    EX --- GOV
    EX --- ONT
    EX --- EVT
    GOV -->|"write via owning block API"| PM
    GOV -->|"write via owning block API"| CCM
    GOV -->|"write via owning block API"| PRD
    PM -->|"state events"| EVT
    CCM -->|"state events"| EVT
    PRD -->|"state events"| EVT
    EVT --> IM
    IM -->|"recommended action"| EX
    SOR -.->|"runs on"| RT
    classDef exos stroke:#0077B6,stroke-width:2px
    classDef sor stroke:#7A8DA5,stroke-width:1px
    class EX,GOV,ONT,EVT exos
    class PM,CCM,PRD sor
Exos view: Exosphere in the Decoupling and Integration role, with every write sent to the owning block's Open API.

Composes with the Canvas you already run

ODA standardises the component, not the runtime. A machine-readable component specification lists the APIs and events a component exposes and depends on, and the ODA Canvas reads it to wire up the API gateway, identity and observability. Because the contract is the component, Exosphere composes with whichever Canvas or runtime an operator runs, including Microsoft's ODA Canvas on Azure, which uses Azure Kubernetes Service, Microsoft Entra ID and Azure Monitor.

  • Component anatomy respected. Each ODA component has a core function plus security, management and operations, and notification and reporting (IG1171). Exosphere calls the core function's Open APIs and subscribes to its published events.
  • Events stay with the Canvas. Canvas operators configure how a component publishes events; Exosphere is a subscriber like any other.
  • MCP as one more API type. TM Forum's AI-Native Canvas work declares MCP servers as an interface type in front of the Open APIs. Exosphere's MCP surface follows the same pattern.
  • Human approval of business actions. The Canvas secures identity, scope and the gateway. Exosphere adds business approval of individual actions on top, delivered against each operator's own stack.

How Exosphere composes with an ODA Canvas

sequenceDiagram
    autonumber
    participant CMP as ODA component
    participant COP as Component operator
    participant APO as API and MCP operators
    participant IDO as Identity config operator
    participant GW as API gateway
    participant EVM as Canvas event management
    participant EXO as Exosphere
    participant AGT as AI agent
    CMP->>COP: Deploy with component specification
    COP->>APO: Exposed APIs incl. MCP interface
    APO->>GW: Configure routes and policies
    COP->>IDO: Register roles and permissions
    COP->>EVM: Configure published events
    AGT->>EXO: Intent via MCP tool
    EXO->>EXO: Authorise scope, tenancy and threshold
    EXO->>GW: TMF Open API call with scoped identity
    GW->>CMP: Routed request
    CMP-->>GW: Result
    GW-->>EXO: Result
    CMP-)EVM: State change event
    EVM-)EXO: Event to subscriber
    EXO-->>AGT: Outcome with audit reference
Canvas operators wire the component; Exosphere calls it under policy and listens to its events.

ODA aligned, by design

Exos Systems designs Exosphere Agentic to ODA principles: Open APIs first, decoupled engagement, owning blocks write, and events through the Canvas. Where an operator's components hold TM Forum conformance through the Component Conformance Toolkit, Exosphere works with them through the same Open APIs the toolkit tests.

The result is an agentic layer an ODA architect can place on the map in one conversation, and govern with the controls the estate already has.

Exos Systems is a TM Forum member and aligns to ODA. Standards bodies named here describe the context we work in; they are not an endorsement by those bodies.

Take the next step

Start with one loop. There are many more. Exos Systems will walk you through the mapping for the outcome you most need to improve.