Pages
Intent, MCP and the AI-native ODA direction
Where TM Forum is heading, and where Exosphere Agentic already stands
The industry is converging on one direction: intent as the contract between business and network, MCP in front of the Open APIs, and systems of record that stay authoritative under human governance. Exosphere Agentic is designed to that direction. 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
Intent: state the outcome, not the steps
TMF921 Intent Management lets an intent owner and an intent handler express, report on and negotiate intents. Each intent's expectations are written in an ontology language and validated against the TM Forum Intent Ontology (TIO). The API carries intents, intent reports, intent specifications and probe intents.
- Intent runs through the product and service APIs too. In v5, TMF622 Product Ordering Management, TMF641 Service Ordering Management, TMF645 Service Qualification and TMF679 Product Offering Qualification carry intent capability, with TMF921 as the dedicated intent API.
- The handler is an agent. TM Forum describes the Intent Management Function as an intelligent agent: it observes its domain, compares what it sees with the intent, acts, and checks again.
- Intent sets goals for fast loops. IG1358 keeps intent handlers out of hard real-time control: they set and adjust the goals of real-time loops and watch whether those loops comply.
- TIO is modular and federated, built on W3C RDF and RDFS, with domain extensions on a common intent model.
TM Forum already uses a formal ontology for intent. The telecom ontology for BSS and OSS brings the same discipline to the commercial entities that intent depends on.
Where BSS meaning enters the intent
The network knows what it can deliver. The business knows what a commitment is worth. Exosphere Agentic connects the two.
- Probe before you commit. A TM Forum Catalyst showed a BSS sales flow discovering the available intents, then sending a TMF921 probe intent to check feasibility before an order was accepted.
- Intent can carry utility. TIO intents may state how valuable an outcome is to the owner, so handlers can optimise and resolve conflicts between intents.
- Utility is commercial meaning. SLA terms, customer segment and commercial exposure live in BSS. The telecom ontology binds them, so a BSS loop can say what an outcome is worth.
- A person approves the commitment. Before a loop creates an intent that carries commercial exposure, Exosphere, the judgment layer inside Exosphere Agentic, routes it to the role with authority.
An intent-driven loop across BSS and network
sequenceDiagram
autonumber
participant OWN as Intent owner · BSS loop
participant IMF as Intent handler · network domain
participant RTL as Real-time control loop
participant NET as Network and inventory
participant HUM as Commercial approver
OWN->>IMF: Discover available intent specifications
OWN->>IMF: TMF921 probe intent, can this SLA be delivered
IMF->>NET: Check capacity and topology
alt Feasible
IMF-->>OWN: Probe report, feasible with expected outcome
OWN->>HUM: Proposed commitment and commercial exposure
HUM-->>OWN: Approved within stated scope
OWN->>IMF: TMF921 create intent with utility
IMF->>RTL: Set loop goals
loop Intent assurance
RTL->>NET: Fast corrective actions
NET-->>IMF: Observations
IMF-->>OWN: Intent report, compliant or degraded
end
else Not feasible
IMF-->>OWN: Probe report, not feasible with reason
endMCP in front of the Open APIs
MCP is the open protocol agents use to call tools. Across the standards bodies, it is arriving as a layer in front of the APIs the industry already agreed.
- IG1445 positions MCP as complementary to TM Forum Open APIs, adding value to them rather than replacing them.
- ODA decision 0016 provides MCP servers for TM Forum Open APIs. One API may have several MCP servers for different domain contexts, such as retail, wholesale, B2B and B2C, discoverable in the API inventory with versioning, governance and lifecycle management.
- The AI-Native ODA Canvas lets agentic components declare the models, agents, tools and APIs they need, adds MCP as an interface type, and audits model interactions through an AI gateway.
- Reference MCP servers wrap Open APIs such as TMF620 in TM Forum's open-source components, as reference examples that teams switch on deliberately.
- IG1454 profiles MCP for telecom: tools wrap existing BSS and OSS APIs, and a governed catalogue admits only authorised servers.
- Mplify, formerly MEF, added MCP server code for its seller-side LSO APIs.
Catalyst experience points the same way: TM Forum Open APIs suit MCP wrappers, and tightly scoped agents outperform general-purpose ones. That is the Exosphere Agentic design: one MCP and tool gateway in front of the operator's Open APIs, capabilities granted per loop, reads and writes separated, and every call attributable. Canvas gateways enforce identity, roles and scopes; Exosphere adds business authority at the moment of action.
Agent to tool to Open API, with policy in the path
flowchart TB
AG["Agent<br/>Microsoft AI platform"]
GW["MCP and tool gateway<br/>grants per loop"]
POL{"Exosphere<br/>policy"}
HUM["Role with authority"]
BLK["Blocked<br/>recorded with reason"]
API["TM Forum Open APIs<br/>TMF622 · TMF641 · TMF921"]
SOR["Systems of record<br/>ODA components"]
AUD["Audit record<br/>intent to record"]
AG -->|"MCP · agent to tool"| GW
GW --> POL
POL -->|"execute"| API
POL -->|"route"| HUM
POL -->|"block"| BLK
HUM -->|"approved"| API
API -->|"deterministic action"| SOR
SOR -->|"confirmed outcome"| AUD
classDef ms stroke:#4A5F7A,stroke-width:2px
classDef exos stroke:#0077B6,stroke-width:2px
classDef std stroke:#005F8A,stroke-width:1px
classDef sor stroke:#7A8DA5,stroke-width:1px
classDef human stroke:#009688,stroke-width:3px
classDef stop stroke:#E68A00,stroke-width:2px
class AG ms
class GW,POL,AUD exos
class API std
class SOR sor
class HUM human
class BLK stopThe AI-native ODA direction, layer by layer
TM Forum's AI Native ODA roadmap sets clear principles: systems of record stay essential and supply deterministic action through Open APIs, including via MCP; agents need shared semantics, not just shared context; AI runs under full human governance; and the aim is business value, not autonomy for its own sake. Its priorities map directly onto the Exosphere Agentic design.
| Roadmap priority | Exosphere Agentic design |
|---|---|
| BSS and OSS ontologies based on SID and eTOM | The telecom ontology for BSS and OSS: SID-aligned entity types, typed relationships, bindings to systems of record |
| Agent-ready Open APIs | The MCP and tool gateway over TM Forum Open APIs |
| Human ability to constrain, correct or stop agents at any autonomy level | Approval as policy (execute, route, block) and autonomy earned per action type |
| Audit trails of agent reasoning and decisions | One record linking intent, actor, authority, API operation and record |
| Sovereign-aware ODA | Deployed into the customer's own Azure tenant |
| ODA as a data product for retrieval and graph | Cited grounding over the published standards |
| Guardrail reference implementations | Fail-closed policy checks and signed, single-use approvals |
Direction of travel
Exploratory and proposed work points further. IG1486 explores formalising SID as a machine-reasoning ontology and a runtime control plane for agents, and proposed AI-Native Canvas decisions describe agents as components with agent-to-agent interfaces. Exosphere Agentic is aligned with TM Forum's direction and follows this work as it matures.
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
See how one of your loops maps to intent, MCP and the Open APIs.