More Information

Propose, approve, execute, and the audit record

How a recommendation becomes a change in the system of record, with nothing assumed and everything recorded.

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. Governed action is how a Sherpa agent's recommendation becomes a change in the system of record. It is proposed without touching data, approved by the person with authority, executed once, and recorded from intent to outcome.

Updated 11 October 2026

Three steps, three separate permissions

Propose. Propose tools never change data. The agent reads facts through read-only queries and gets back a signed proposal, a governance checklist and a list of anything it could not find.
Approve. Where policy routes, the approver sees the evidence and the cited clause on an Adaptive Card in Microsoft Teams or in Sherpa Approvals. The decision produces a signed, single-use, expiring approval bound to that proposal and its data. What is approved is exactly what is executed.
Execute. Exosphere, the judgment layer inside Exosphere Agentic, re-reads the record. If the facts have drifted, it aborts as stale. If not, it makes one governed call through TM Forum Open APIs, via Azure API Management, once per proposal id, and reports the real outcome.

Capability is granted per loop. Reads and writes are separate permissions, systems of record stay authoritative, and every call is attributable. The blast radius of a new loop is knowable before it runs.

Propose, approve, execute

sequenceDiagram
    autonumber
    participant AG as Billing Sherpa
    participant EX as Exosphere
    participant SOR as System of record
    participant AP as Approver - Teams or Sherpa Approvals
    participant REC as Audit record
    AG->>EX: Sweep for candidates
    EX-->>AG: Accounts to run the loop on
    AG->>EX: Read facts
    EX->>SOR: Read-only query
    SOR-->>EX: Facts
    EX-->>AG: Facts and missing-data list
    AG->>EX: Propose action
    EX-->>AG: Signed proposal and policy checklist
    EX->>AP: Approval card with evidence and cited clause
    Note over EX,AP: Human gate where policy routes
    alt Approved
        AP-->>EX: Approve with reason
        EX->>EX: Issue single-use, expiring approval
        EX->>SOR: Re-read facts
        alt Facts unchanged
            EX->>SOR: Governed write via TM Forum Open APIs, once per proposal id
            SOR-->>EX: Applied, refused or unconfirmed
        else Facts drifted
            EX->>EX: Abort as stale
        end
    else Rejected
        AP-->>EX: Reject with reason, nothing executed
    end
    EX->>REC: Intent, evidence, checks, decision, outcome

Proposals never write; an approval is single-use and bound to the data it saw; execution re-reads before it acts.

Checks run before anyone is asked

Policy checks run when the proposal is built, not after the approver has said yes. An approver never sees an action that should not have been offered.

A billing credit, as an illustration, is offered for approval only when every check passes:

the amount is positive
the amount is within the credit authority
the amount does not exceed the invoice
the charge is still unpaid
the classification is eligible for a credit
the invoice has not already been credited
the credit matches the whole invoice or one line
a case and a follow-up task exist

Customer guardrails such as hardship, vulnerability, strategic accounts and consent work the same way. Unknown means refused. Missing data is stated, never filled in.

One record from intent to outcome

Field	What it holds
Intent	The outcome requested, and who or what initiated it
Actor and authority	The role and limit, the rule and rules version applied, and the policy clause cited
Evidence	The facts retrieved, the data that was missing, and the sources cited
Decision	Execute, route or block, plus the approver and reason where a person decided
API operation	The TM Forum Open API call and its idempotency key
Record	The real outcome (applied, refused or unconfirmed) and the record it changed

Written by the layer the call passes through. Blocked actions are recorded too. The transcript can expire, and the record still says who decided what.
Reversal is a governed action, not an undo button. History is extended, never edited.
A case record a risk team can read. Facts, missing data, assessment, recommendation, action, authority and audit, each drawn only from what the run actually wrote.

The audit lineage

classDiagram
    direction LR
    class Intent {
        requested outcome
        initiating principal
    }
    class Evidence {
        facts retrieved
        missing data
        sources cited
    }
    class Authority {
        role and limit
        rule and version
        cited clause
    }
    class Decision {
        execute route or block
        approver and reason
    }
    class Operation {
        TM Forum Open API call
        idempotency key
    }
    class Outcome {
        applied refused or unconfirmed
        record reference
    }
    Intent --> Evidence : grounded by
    Evidence --> Decision : informs
    Authority --> Decision : bounds
    Decision --> Operation : permits
    Operation --> Outcome : produces

One lineage links intent, evidence, authority, decision, operation and outcome for every action, including blocked ones.

Seen end to end on a synthetic account

Demonstrations run on synthetic accounts; any figures shown illustrate the mechanism and are not a performance claim.

A suspected bill-shock credit, run through the whole loop:

Detect. An invoice jumped well past its usual level.
Understand. One new line accounted for the whole change. No usage records supported it, and the missing data was stated rather than filled in. The case was classified as a goodwill credit for suspected bill shock, not a billing error.
Decide. Every governance check passed before the credit was offered. A person with authority approved it with a single-use approval.
Act. The credit was executed exactly once. The stale-record guard was in force, so a changed invoice would have been refused.
Confirm. On the next invoice the charge was not repeated, and the case was cleared.

Restraint, on the same run. A bigger jump on another account was explained by an expected new charge. The loop left it alone and recorded why. Restraint is part of governance: a loop that credits every spike costs money.

Every claim traces to a record.

Built once, reused by every loop

The governance core does not change per loop. The envelope, the approval, the approval card and the audit record were reused unchanged when another loop was added. Each new loop brings its own facts, checks and actions.
Backend-neutral by design. TM Forum Open APIs are the contract. One connector is chosen at deployment against the operator's own stack, and systems of record stay authoritative.
Design principles. Open APIs as the contract, exactly-once execution, fail closed, declared capabilities, and build on what already works.
A conformance bar. A standards registry maps each loop's operations to TM Forum Open APIs, SID entities, ODA components and eTOM processes. A loop counts as done only when it meets that bar.

Every loop follows the same governed pattern, which is what makes the first one worth starting and the next one cheap to add. The right loop to start with is the one attached to the outcome you most need to improve. Start with one loop. There are many more.

Take the next step

See the loop run on synthetic accounts, or walk through the ontology with Exos Systems.