Skip to content

Platform · Governance

Humans decide what
the agent may decide.

Oversight is a design decision, made before launch and kept in writing. Roles, permitted actions and the release gate are versioned like code, so every decision an agent takes traces back to a person who allowed it.

  1. Where the boundary sitsRoles, permitted actions, the release gate
  2. Risks and controlsFour risks, and the control that answers it
  3. EvidenceSigned figures, with their scope and period
  4. DocumentsThe governance model, and how to ask
Your perimeter, with the Voicing runtime inside itYour perimeter drawn as a system diagram. Telephony enters through a dock on the left edge and people work through a dock on the right; both join the Voicing runtime, where Voice AI Agents, Real-Time Translation, Knowledge Mesh and Agent Assist run. Under the runtime, the models run on your compute and the observability store keeps transcripts, traces and evaluations. Your systems of record dock on the bottom edge and the runtime reads and writes them by policy. Nothing leaves the perimeter.Your perimeterEgress: noneVoicing runtimeVoice AI AgentsAnswers and completes callsReal-Time TranslationBoth directions, mid-callKnowledge MeshCited answers, your recordsAgent AssistThe same answer, for peopleModelsProprietary LLMsSpeech to textText to speechCPU inferenceObservability storeTranscriptsTraces and tool callsEvaluationsRetention you setTelephonySIP and CCaaSSystems of recordCRM, core, ticketsPeopleHuman agentsRead/writeChange controlScored before releaseOne accepted versionRuns the accepted version onlyWrites by policyPermitted writes onlyA receipt per turnReadable by reviewersA person takes itCalls outside policy
Your perimeter, with the Voicing runtime inside itYour perimeter drawn as a system diagram. Telephony enters through a dock on the left edge and people work through a dock on the right; both join the Voicing runtime, where Voice AI Agents, Real-Time Translation, Knowledge Mesh and Agent Assist run. Under the runtime, the models run on your compute and the observability store keeps transcripts, traces and evaluations. Your systems of record dock on the bottom edge and the runtime reads and writes them by policy. Nothing leaves the perimeter.Your perimeterEgress: noneVoicing runtimeVoice AI AgentsAnswers and completes callsReal-Time TranslationBoth directions, mid-callKnowledge MeshCited answers, your recordsAgent AssistThe same answer, for peopleModelsProprietary LLMsSpeech to textText to speechCPU inferenceObservability storeTranscriptsTraces and tool callsEvaluationsRetention you setTelephonySIP and CCaaSSystems of recordCRM, core, ticketsPeopleHuman agentsRead/write
  1. Change controlScored before release
  2. One accepted versionRuns the accepted version only
  3. Writes by policyPermitted writes only
  4. A receipt per turnReadable by reviewers
  5. A person takes itCalls outside policy
  • Roles and approvals
  • Permitted actions
  • Release gate
Where the boundary sits01 / 05

Three boundaries, set before the first call.

Who may change an agent, what it does without asking, and how a change goes live are settled in writing before launch. Everything outside those lines reaches a person, on the call or in the review queue.

  • Who can change an agent

    Authors draft, approvers publish. No change ships unreviewed.

  • What an agent does alone

    Permitted actions are set per call type. The rest reach a person.

  • How a change goes live

    Scored offline in AI Observability. A person accepts the version.

From draft to production

No version reaches a caller until a person accepts it.

From draft to productionAn author drafts prompts, tools and policies. The draft becomes a candidate version, the candidate is scored against recorded calls in AI Observability, and the scored version reaches the release gate. A named approver stands over the gate and accepts the version, the gate opens, and production runs the accepted version. One route runs back under the line: a version rolls back the same way it shipped.Rolls back the same wayAn authordraftsprompts, tools and policiesA candidateversionversioned like codeScored againstrecorded callsin AI ObservabilityA namedapproveraccepts the versionProduction runsthe accepted versionno change ships unreviewedThe release gate
Risks and controls02 / 05

What could go wrong, and what stops it.

Four risks a review board raises about agents that act for customers, each answered by a control a person operates and, where we have signed it, the figure behind it.

  1. A change ships without review
  2. A regulated call is contained
  3. The model drifts unnoticed
  4. Nobody can explain a decision

RiskA change ships without review

Prompts, tools and policies are versioned, and a person accepts each new version.

How it is enforced

An author proposes a change; an approver with a named role publishes it, and the history keeps both names.

EvidenceVersion history and approval log on request

Evidence03 / 05

Measured in production, stated with scope and period.

Each figure is stated with its scope and its period. The report behind any of them is yours on request.

  • Actions into systems of record

    97%

    Scope
    2,800 calls, schema-strict grading, eight-tool suite
    Period
    2026
  • Answers on in-scope intents

    Under 0.5%

    Scope
    in-scope intents
    Period
    production, 2026
  • Calls finished inside policy

    83%

    Scope
    Telmex deployment
    Period
    2026
  • Independent attestation

    SOC 2 Type 2

    Period
    current

One action, guarded

What happens when an agent wants to act.

One action, guardedThe agent proposes an action into a system of record, and the proposal reaches a policy check set per call type. Inside policy, the action runs through your API, under your role, and leaves the receipt: the turn, the tool, the arguments it passed and the passages it cited. Outside policy, the action is refused, and a person takes it, with the context so far.inside policyoutside policyThe agent proposesan actioninto a system of recordPolicy check,per call typeset before the first callRuns through your API,under your rolepermitted writes onlyThe receipt: turn, tool,arguments, cited passagesreadable by reviewersThe actionis refusedthe rest reach a personA person takes it,with the context so farcalls outside policy
Illustrative
Documents04 / 05

Governance model, in writing.

One document written for the people who approve vendors: roles, permitted actions, the release gate and the receipts, in plain language.

Ask for it with the security package, and read it with your risk team before the architecture review.

Closing05 / 05

Bring one call type. Leave with an architecture.

A runtime disc with a slate top ringed by six pucks, a track running out to a record spool on the left, under a low arch at the front, past a switch on the right, and back to the runtime.
Governance

Humans decide, and the record shows it

A working session with an engineer who has deployed inside a bank’s perimeter. We map your telephony, data boundary and handoff rules, and tell you what we would not automate.