Approval Is a Policy: The Architecture

Every action an agent proposes against a system of record passes through one enforcement point that the operator configures. That point evaluates the action against the operator's rules and returns one of three outcomes: execute within policy, route to the person whose authority covers it, or block. The same rules apply to actions a person initiates through the same path. Each recommendation cites the clause of the operator's own policy it relies on, and every outcome, refusals included, produces one record linking intent, actor, authority, API operation and record.

In Exosphere Agentic that enforcement point is Exosphere, the judgment layer. No system of record is replaced, and Exosphere Agentic is deployed into the operator's own tenant. The operator encodes the authority its people already hold as rules a machine can evaluate. That answers the question Exos's governance field note puts first: what an agent may do, and under what controls.

A billing credit serves as the worked example throughout. It is one illustration of a pattern every loop follows.

Exosphere Agentic is an overlay, not a rip-and-replace: systems of record keep recording what happened, and Exosphere shapes what happens next. Governance is not a wrapper on top; it is the layer every agent call passes through (Fig. 1).

Sherpa agents, the role-named agents such as Billing Sherpa and Order Sherpa, are built on the Microsoft AI platform, in Copilot Studio or Microsoft Foundry, inside the operator's tenant. They detect, assemble evidence and propose; they never write on their own authority. Access is controlled per principal and per token scope: only Exosphere holds write scopes on the access layer, so no agent write can bypass it, and an outage stops writes rather than passing them through.

Exosphere, the judgment layer, has four components. A shared entity model gives one identity across the TM Forum Open APIs. Intent-to-capability resolution maps a business intent to the operation that fulfils it, grounded in that model, not guessed from a tool description. Orchestration holds sagas, idempotency and durable state, so a multi-step action can be compensated when a later step fails. Policy and lineage evaluates every proposed action and records the chain from intent to record. An event mesh carries signals in flight, not in batch.

The access layer is Azure API Management: the MCP endpoint, Microsoft Entra ID authentication, quotas, tracing and versioning. Exosphere builds on it, not around it. Systems of record are reached through TM Forum Open APIs.

Complement, not compete: the plumbing is Microsoft's; the judgment is ours. In February 2026, Microsoft's telecommunications industry blog described an agentic BSS platform created with Exos Systems to demonstrate agents built in Copilot Studio. This paper describes the policy layer beneath such agents.

Why a toggle or a prompt is not a control

The Microsoft AI platform offers a per-tool approval setting: a tool asks before it runs, or it does not. That is the right primitive for a tool boundary, but by design it cannot see an action's value, the customer's segment, the exposure already committed, or who holds authority for the case. Those are properties of the business, not of the tool.

Instructing the model does not close the gap. Microsoft's documentation for Microsoft Foundry hosted-agent toolboxes notes that the toolbox endpoint does not itself stop a call marked as requiring approval; the agent runtime must pause, show the tool and its arguments, and resume only after approval. A system-prompt instruction to ask is not enforcement. The guidance is scoped to hosted-agent toolboxes; the principle is general: a control has to sit in the path of the call, where it can refuse.

Exosphere separates the rules that decide from the documents that justify.

Rules enforce. The operator writes rules into Exosphere: thresholds set per loop and per commercial exposure, not per model; routing to the approver whose authority covers the case; and hard blocks. Rules are evaluated by Exosphere, not inferred by the agent.

The corpus grounds. The operator's own policy corpus, meaning its credit policy, delegation-of-authority matrix and regulatory obligations, is indexed in Exosphere. Each rule carries the clause it encodes, which the approval card shows when the rule fires; retrieval over the corpus adds the passages that support the recommendation. The audit record keeps both.

For a billing credit, Exosphere resolves the initiating principal, its role and its limit; the action type; the value against its limit; the customer segment; cumulative exposure within the customer contact and over the policy period; any open dispute or bill hold; and any vulnerability flag (Fig. 2). The outcome is execute within policy; route to the approver with authority, who need not be the person in the conversation; or block, with the reason stated. A fact that cannot be resolved is a policy case too; in the illustrative policy below, it goes to a person.

The same rules bind people. A credit that a care rep keys through a screen calling Exosphere is evaluated exactly as one the Billing Sherpa proposes. An agent never gains more latitude than the person it assists, and a person working through Exosphere gets no silent exception. Native BSS screens keep their own entitlements until the operator routes those writes through Exosphere too.

None of this is exotic. ERPNext can reserve submission of a transaction above an authorised value, and over-limit credit exceptions, to designated roles; Odoo's approval rules can stop one person approving two steps. TM Forum's process framework already distinguishes adjustments that policy allows the system to make automatically from those that need management authority, and treats the billing policy itself as a managed artefact (eTOM GB921 v25.5, 1.3.10.4.3 and 1.3.1.8.2). TAM GB929D v26.0 §5.10.3 describes account adjustments made against a “schedule of authorization policies”. Agents change only who proposes.

When policy routes an action to a person, the path is fixed (Fig. 3).

1. Propose. A Sherpa agent submits a proposal in the Sherpa envelope, with the cited clause. The envelope maps onto the loop: Facts to detect, Assessment to understand, Recommendation to decide, Action to act and Audit to confirm (the Audit field is completed at confirm). Exosphere issues the approval request as a signed, single-use object with an expiry, so an approval binds to exactly those arguments and cannot be replayed or stretched to cover a changed action.
2. Evaluate. Within policy, the action proceeds to the write. Blocked, it stops, with the reason returned and recorded. Routed, it goes to the approver the policy names.
3. Reach the approver. Power Automate posts an Adaptive Card in Microsoft Teams showing the envelope and the clause; the same request appears in Sherpa Approvals, the in-app console. The decision is attributed to the authenticated principal who made it. An undecided request lapses at expiry; nothing executes on it.
4. First decision wins. Later clicks, in either channel, are told the proposal is already decided. Every decision captures a reason.
5. Re-validate at execution. Before writing, Exosphere re-evaluates policy and re-reads the data the proposal relied on. If a payment has landed, a dispute has opened or the proposal has expired, the approval lapses and the proposal returns for a fresh decision.
6. Write once. Orchestration sends the write through Azure API Management to the bill or account surface the estate exposes through TMF678 Customer Bill Management or TMF666 Account Management. TMF678 defines no adjustment resource, so the exact operation follows the estate. Orchestration holds the proposal id in durable state as the idempotency key and never issues a second write for it; where the system of record accepts a caller-supplied reference, the proposal id travels with the call.
7. Report the real outcome. Applied; refused, with the reason the system of record gave; or unconfirmed, when the call was made but its effect could not be established. An unconfirmed write is read back and reconciled before any retry, and is never shown as success.
8. Write the lineage, described in the next section.

Without a policy layer, an agent action leaves three disconnected logs: the conversation, the gateway call and the BSS record. Nothing stitches them into one causal chain, and the transcript holding the intent expires. For a regulated operator, that is not an audit trail.

Exosphere writes one immutable record per action, linking:

• Intent: what was asked, in which loop, by which person or Sherpa agent.
• Actor and authority: the principal and its token scope, the rule applied, the version of the rules in force and the clause cited.
• Evidence: the facts as evaluated at decision and again at re-validation.
• Decision: approver, channel, time and stated reason.
• API operation: the Open API call, its arguments and its idempotency key.
• Record: what changed in the system of record, and the outcome it returned.

The record is written by the layer the call passes through, so it does not depend on an agent choosing to log, and blocked actions are recorded too. The transcript can expire; the record still says who decided what, under which authority, on what evidence, and why.

Reversal is a governed action, not an undo button. If a step fails mid-flight, orchestration compensates the completed steps under the original approval. Reversing a completed action later is a new governed action: it passes the same policy evaluation, may need its own approval, and links its record to the original. History is extended, never edited.

A policy is only as good as the context behind it, and that context is scattered: open disputes, payment behaviour, contract terms, the tone of recent interactions. Whether a customer is content with the service is not a field in any one system. Assembling that picture is semantic work before it is retrieval work. Rules act on facts resolved from systems of record; softer signals such as tone inform the Assessment and the approver's judgment.

Exosphere's entity model is SID-aligned. GB922 Customer v25.5 supplies the relevant ABEs: Customer Bill, Customer Billing Account, Customer Interaction, Customer Problem, and Customer Billing Inquiry & Dispute, still marked preliminary in that release. PartyCreditProfile carries a credit risk rating and a credit score but no credit limit, and SID has no model of per-role approval limits. SID gives the nouns; the limits that decide who may approve what are operator policy, encoded on top.

The facts arrive through the Open APIs:

• TMF678, whose recommended onHold bill state halts further processing until open issues are resolved: a natural home for a dispute hold;
• TMF666 BillingAccount, carrying creditLimit and PaymentPlan;
• TMF717 Customer360, a read-only consolidated picture of the customer;
• TMF683 Party Interaction, the history behind a sentiment signal;
• agreement terms linked to the products they govern (GB922 Product v26.0).

Context also changes who decides. A high-value decision on a major business customer routes, by policy, to the named account owner, who knows things about the relationship that no data surface records. Exos's ontology briefing, available on request, sets out its approach to the SID mapping.

Policy fixes where the line sits today; it should not stay there. Exosphere sets autonomy per action type, not per agent or per model, on four rungs defined by what reaches a person (Fig. 4): always approve (every instance); approve above a threshold (instances above it); execute within policy with sampled review (none before execution, a sample afterwards, so measurement continues); and autonomous within policy (only exceptions), with people accountable for the rulebook and whatever it did not foresee.

Movement is driven by evidence captured at decision time: how often approvers disagree with the recommendation for that action type, and why. A low rate argues for promotion only when decisions carry understood reasons and agree with independent sampled review, because reflex approvals also produce a low rate. A rising rate, a new kind of reason, a policy change or an incident means demotion, by several rungs if warranted. At the top rung no one approves, so reversals, complaints, incidents and sampled-review findings drive demotion. Each move is itself a policy change, made by a named owner and recorded.

This is Exos's method, not established industry practice. It is also the approach a telecom operator executive has argued for: capture in rules the authority staff already exercise, allow the agent to proceed unaided where the evidence supports it, keep a person on everything else, and shift that boundary as the pattern of disagreement becomes clear.

For a maturity statement rather than a capability claim, Exos's ontology briefing takes TM Forum's Autonomous Networks levels (IG1218, with the IG1252 evaluation methodology) as the yardstick. Here they serve by analogy only, since they are defined for network operations (Autonomous Networks whitepaper, Release 1.0, May 2019, §2.2; IG1252, as described in IG1216 v1.3.0). The analogy works best at task level: IG1224 v13.0.0 describes autonomy per task. Decision is shared at L3 and owned by the system from L4, while intent is still shared at L4. So always approve sits near L2, approve above a threshold near L3, and the upper rungs near L4. Because the operator keeps the rules, the ladder stops short of L5.

Exosphere is TM Forum native. Fig. 5 and the annex map the billing-credit illustration onto the frameworks as they stand; other loops map to their own processes and Open APIs.

Process. In eTOM GB921 v25.5, 1.3.10.4.3 Authorize Customer Bill Invoice Adjustment sits within 1.3.10.4 Manage Customer Bill Inquiry, and its child 1.3.10.4.3.3 Determine Automated Bill Adjustment decides whether an adjustment can be automated under the policies managed in 1.3.1.8.2 Manage Customer Billing Policy. Estates documented against v22.0 know 1.3.10.4.3 and 1.3.10.4.3.3 as 1.3.11.3 and 1.3.11.3.3.

Applications. Alongside §5.10.3 (adjustments made against authorisation policy), TAM GB929D v26.0 §5.10.2 tracks open disputes to closure and enters an agreed dispute adjustment pending research and approval.

APIs. A billing credit lands on whichever bill or account surface the estate exposes through TMF678 or TMF666; TMF621, TMF656 and TMF724 carry assurance-driven actions. The Open API directory has no dispute, adjustment, approval or promise-to-pay API. The nearest constructs are TMF666 PaymentPlan, TMF728 Dunning Case, TMF696 Risk Management and TMF678 onHold. For a business task that needs a person, TMF701 Process Management comes closest (v4.1 is its latest non-preview release); Exosphere's own approval path is the Teams card and Sherpa Approvals.

Canvas. ODA Canvas Decision Log 0017 defers standard agent implementations and places agents alongside systems of record, with humans checking agent output and steering the loops. The AI Native Canvas design exposes components over MCP, deploys agents as ODA components and audits model interactions through an AI Gateway, but human approval of individual business actions is not yet standardised; a proposed Canvas decision on Interaction Gateway policy enforcement, aligned with GB1087, is still open. Exosphere provides that layer, delivered against each operator's own stack.

Guidance. IG1335 GenAI Checklist v1.2.0 advises, without requiring it, that high-risk applications can warrant a human in the loop. Routing by policy is a proportionate way to act on that advice.

Fig. 6 shows where each stage's work happens. The table maps each stage to its envelope field and TM Forum artefacts for the billing-credit illustration; other loops map to their own eTOM processes and Open APIs. The mapping is Exos's alignment, since TM Forum defines no approval stage.