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.
- Change controlScored before release
- One accepted versionRuns the accepted version only
- Writes by policyPermitted writes only
- A receipt per turnReadable by reviewers
- A person takes itCalls outside policy
- Roles and approvals
- Permitted actions
- Release gate
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.
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.
- A change ships without review
- A regulated call is contained
- The model drifts unnoticed
- 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
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
RiskA regulated call is contained
Handoff is set by policy per call type, and an agent finishes only what it may.
How it is enforced
Your policy names the call types an agent may complete; every other type reaches a person with the context so far.
EvidenceHandoff policy template on request
RiskThe model drifts unnoticed
Every candidate version is scored against recorded calls before a person accepts it.
How it is enforced
Traces from production are replayed against the candidate in AI Observability, and the report reaches the approver.
EvidenceRegression report sample on request
RiskNobody can explain a decision
Every turn leaves an action receipt and the cited context the agent answered from.
How it is enforced
The receipt names the turn, the tool it called, the arguments it passed and the passages it cited, for your reviewers.
EvidenceUnder 0.5% hallucination rate
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.
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.
Bring one call type. Leave with an architecture.

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.