The shared understanding a loop runs on
Industry standards provide the common language. Customer context makes it operational.
Telecom does not lack data. It lacks connected understanding. The facts already sit in billing, ordering, product and service systems — but the meaning that links them, which contract governs this charge and which policy permits this action, gets reconstructed by a person, one case at a time. The gap is between knowing what happened and knowing what to do next.
A loop closes that gap for one outcome at a time. Before it can, it has to understand what it is looking at. That understanding arrives in three layers, and every loop inherits all three.
Industry foundation
TM Forum standards give telecom a common language. SID contributes shared information concepts, eTOM contributes process context, ODA contributes the modular architectural framework, and Open APIs provide standards-aligned access to the systems that already run.
Customer operating model
Standards describe the industry, not your business. The foundation is extended with your products, contracts, policies, processes, terminology and system relationships — how this operator actually works, in its own words.
Loop context
Each loop then narrows to what it needs: the relevant entities and relationships, the rules that apply, the evidence it must keep, the authority it holds and the actions it is permitted to take.
This is connected meaning rather than a document search. Retrieval still matters — it is how a loop cites a standard or a contract clause instead of paraphrasing one from memory. But the point is not that a system can find a passage about a tariff; it is that the loop knows which tariff governs this account, which order changed it, and whether the resulting charge is permitted.
flowchart TB
subgraph ENV["Customer-controlled environment"]
direction TB
S["Surface — Microsoft 365 Copilot and Teams, web and care channels, business applications"]
M["Microsoft agent platform — Copilot Studio and Microsoft Foundry"]
X["Exosphere Agentic — telecom ontology, operating context, loop orchestration, governance and authority, MCP and tool gateway"]
R["Systems of record — billing, CRM, ordering, product, service"]
S ==>|"Intent and operational signals"| M
M ==> X
X ==>|"Authorised calls only"| R
R -.->|"Evidence and outcomes"| X
X -.-> M
M -.-> S
end
That middle layer is Microsoft’s, and because the boundary is the question most architects ask first, it is worth naming precisely. Copilot Studio is where agents are authored and published into the surfaces people already use. Microsoft Foundry is the model and agent platform behind them. Microsoft Fabric — often named in the same breath — is an analytics platform, the unified data and reporting estate, so it sits alongside this arrangement rather than in the execution path of a loop; where it matters is measuring the outcome afterwards. Exosphere Agentic replaces none of them. It supplies the telecom meaning and the governed execution between that layer and the systems of record.
What the tool gateway is for
Agents are good at reasoning and poor at restraint. The gateway is the part that decides what an agent is actually allowed to reach, and it is deliberately narrow: a loop is given the specific capabilities it needs and nothing else.
Model Context Protocol is how that catalogue is offered to the agent ecosystem, alongside the Open APIs, events and adapters already in place. It is worth being precise about what the protocol does and does not do: MCP is a way to expose tools and context to an agent host. It carries no opinion about which loop may use which tool, or about who authorised it. Those are decisions the gateway makes, and they are what the following four properties describe.
- Capability is granted per loop, not per platform. A credit-risk loop cannot reach what a quoting loop uses.
- Reads and writes are separated. Retrieving a bill is not the same permission as issuing a credit.
- Systems of record stay authoritative. Exosphere Agentic proposes and records; it does not become the new source of truth.
- Every call is attributable — which loop, under which authority, on whose behalf.
Governed, not merely supervised
A loop that can act needs more than an audit log after the fact. Three rails run underneath every step. High-impact actions stop for a person by default, and further gates can be added anywhere else a customer wants one.
Policy
What is permitted — the operator’s own rules, thresholds and exceptions, applied before an action is offered rather than after it is taken.
Authority
Who or what may act. High-impact steps — disconnection, large credits, write-offs, payment-plan exceptions and invoice holds — stop at an approval gate by design, not by configuration someone has to remember to switch on.
Evidence
Why the action was selected — the facts retrieved, the rule applied and the reason code, kept with the case so the decision can be reviewed later.
Where to start
A loop is chosen by the outcome it improves, not by the technology underneath it. The same pattern applies to protecting revenue, reducing cost to serve and accelerating revenue; the examples published here are a portfolio of possible outcomes rather than a standard catalogue, and which one goes first is a question about your priorities.
Exos Systems is a TM Forum member and aligns to ODA, and operates to ISO/IEC 27001:2022. These describe the context we work in; they are not an endorsement by those bodies.