Approval Is a Policy, Not a Boolean

In a recent post, following an earlier field note on governance, I argued that agentic BSS should start with agents that diagnose and recommend, and people who confirm. My reason was simple: “BSS is where mistakes have invoices attached.” A wrong credit changes a customer's bill and the revenue line.

A telecom operator executive pushed back with a sharper point, paraphrased here. Operators insist on a human sign-off for each transaction mainly because legacy BSS cannot catch, contain or reverse its own errors, and a sign-off repeated all day soon stops being a judgement. Yet every care role already has a ceiling: a supervisor may grant more than a rep, and some adjustments no one may make. Encode the limits not yet written down where the system can apply them, and software and staff answer to identical rules.

We ended up in the same place. Approval matters where the stakes are real, and the way to protect it is to stop spending it where they are not. As I put it, “Insight was never the scarce thing in telecom. Capacity was.” Every routine sign-off spends some of it.

As I wrote in that post, “The AI moved the reading. The ‘doing’ didn't move at all.” Agents now read a bill and the account's history faster than an analyst can, but the write path still runs through systems built to record what happened, not to judge what should happen next. The person placed in front of every write sees a stream of near-identical requests, most plainly fine, and approval turns from a control into a queue.

Agent platforms offer a per-tool setting that makes an agent ask before calling a tool. That setting is a boolean. It cannot weigh a credit's value, the customer's segment, cumulative exposure or who holds the authority to decide.

Beneath the agent platforms, Azure API Management handles transport, identity and quotas, and Exosphere builds on it rather than around it. In February 2026, Microsoft's telecommunications industry blog described an agentic BSS platform, created in partnership with Exos Systems, that demonstrates how agents built in Microsoft Copilot Studio can modernise core BSS workflows.

Microsoft Foundry's documentation for hosted-agent toolboxes is explicit: an instruction in the system prompt does not, on its own, enforce approval. The agent runtime has to pause, show the call and resume only once approval arrives. Enforcement lives in the path the call takes. The question is what that path should know.

Every operator already has an approval policy. It lives in credit policies, a delegation-of-authority matrix and regulatory obligations, and much of it is applied from memory. Exosphere makes it executable. The operator authors the rules: thresholds set per loop (an end-to-end task, such as handling a billing query) and per commercial exposure, rather than per AI model; routing to the approver who holds the authority; and hard blocks. Exosphere enforces those rules in the layer every agent call passes through, not in the agent's instructions.

Each proposed action receives one of three outcomes. Execute: it is inside policy and goes ahead without waiting. Route: it needs a decision from a specific role, which need not be the person in the conversation. Block: policy forbids it, and no approval overrides that.

The same rules bind people. A credit keyed by a care rep meets the same check as one proposed by a Billing Sherpa, Exosphere Agentic's billing agent, and the cumulative exposure on an account counts both.

Rules enforce; the corpus grounds. Exosphere also reads the operator's own policy documents, and every recommendation cites the clause it relies on. When an action is routed, the approver sees which paragraph of that policy calls for their decision; when it executes, the audit record keeps the clause.

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). Its application framework describes account adjustments made against a “schedule of authorization policies” (TAM GB929D v26.0, §5.10.3). Exosphere turns that schedule into something enforced at the moment of action.

I put the loop in one line: “Detect, understand, decide, act, confirm. The human sits at decide.” Every loop in Exosphere Agentic runs that sequence, and every Sherpa agent reports in five parts that map onto it: Facts for detect, Assessment for understand, Recommendation for decide, Action for act and Audit for confirm.

Sherpa agents are named for their role: the Billing Sherpa, the Order Sherpa. They detect and understand, turning bills, usage, account history and interactions into evidence a person can judge quickly.

At decide, Exosphere applies the policy. Sitting at decide does not mean deciding every case: people decide once by writing the policy, then in person where it routes a case to them. A routed proposal reaches the approver where they work, for example as an Adaptive Card in Microsoft Teams, posted through Power Automate, or in Sherpa Approvals, the approval console inside Exosphere Agentic. It carries the evidence, the recommendation and the clause relied on. The first decision wins; anyone who opens it later sees it is already decided.

Exosphere is an overlay, not a replacement. At act, it writes to the operator's existing BSS through TM Forum Open APIs, connected per engagement to that operator's stack: TMF678 for the bill, TMF666 for the account, and whichever surfaces the estate exposes for the adjustment itself. As I wrote, “The action lands in the system of record — audited, reversible, attributable.” A reversal is itself a governed action under the same policy. At confirm, Exosphere checks what the system of record actually did (applied, refused or unconfirmed), so a failed write is flagged rather than assumed, and writes one audit entry linking intent, actor, authority, API operation and the resulting record.

For a business customer, an approver needs to know how the relationship really stands. The evidence sits in systems that were never designed to agree: open disputes, payment behaviour, the tone of recent interactions, contract terms. The fix is not consolidation but a telecom-specific map of meanings and relationships, so an agent can retrieve against defined terms rather than guess.

Exosphere's shared entity model is aligned with TM Forum's SID (Information Framework), so a bill, a billing account, an interaction and an agreement mean the same thing to every agent and every rule.

Context also tells policy who should decide. A major decision on a high-value business account is, as I have said before, “a good case for human in the loop”, and policy says which human: the named account owner, who holds commercial context no rule can capture.

The Exos method, which the operator executive proposed in that exchange, is to measure disagreement before any action type executes on its own. Each action type usually starts with a person approving every instance, and every decision is recorded with its reason. When people rarely overrule the recommendation, and the reasons they do are understood, the operator can move that action type a step towards executing within policy, with a sample still reviewed by people. A new pattern of disagreement is the operator's cue to move it back. Nothing promotes itself; the operator makes every move.

TM Forum's Autonomous Networks levels offer a yardstick, by analogy only, since they are defined for network operations (whitepaper Release 1.0, May 2019, §2.2). At L2 people own each decision; at L3 the decision is shared between people and system; at L4 the system decides while people and system still share the intent. Always approving is L2-like, approving above a threshold is L3-like, and executing within policy, with sampling, is L4-like. Throughout, people own the policy and every case it does not anticipate.