Safety in a utility contact centre is specific: don't invent answers, don't act without verifying who is calling, don't quietly get worse over time, and make every conversation reviewable afterwards. Here is how Grace is built to do that.
“Safe AI” is a vague phrase, so it is worth being concrete about what it has to mean when an agent is answering a utility’s phone.
It means the agent does not invent an answer when it does not know one. It means nothing consequential happens to an account before the caller is verified. It means one organisation’s data is unreachable from another’s. And it means that if someone asks six months later why a particular answer was given, there is a record.
Here is how each of those is built.
Fine-tuned for function calling and instruction following
Grace runs on models fine-tuned specifically for calling functions correctly and following instructions precisely, rather than for open-ended conversation.
That focus is what reduces hallucination in practice. An agent asked for a balance should call the balance function and read out what comes back — not produce a plausible-sounding number. Training against that specific behaviour is more effective than instructing a general-purpose model to be careful.
Guardrails and adversarial testing
Grace stays inside the scope she was configured for, and we test that deliberately. Prompt-injection and jailbreak attempts are part of our own testing, so the failure modes get found by us rather than discovered live.
Off-scope requests route to a person rather than being attempted. Declining to answer is the correct outcome far more often than it is treated as one.
A review agent over every conversation
Conversations are assessed automatically after the fact and flagged when something looks wrong — a bad answer, a missed escalation, a caller getting frustrated.
This matters because the failure mode of a deployed agent is not a dramatic collapse; it is a slow accumulation of slightly wrong answers nobody is watching. Flagged conversations go to a human, corrections are recorded, and those corrections feed back into the configuration.
Working inside your systems, not beside them
Grace reads from and writes to your CIS and billing platform directly, and holds no shadow copy of your customer data.
That is a safety property as much as a functional one: there is one source of truth, the answer a caller gets matches what a CSR sees on screen, and there is no second database to secure, synchronise or explain to an auditor.
Tenant isolation
Data is filtered at the tenant level, so one organisation’s information is not reachable from another’s. That isolation is enforced by the platform rather than left to configuration, which is what allows organisations to meet their security requirements without giving anything up functionally.
Deployment is cloud-agnostic, so this fits the infrastructure and data-residency constraints a utility already operates under.
Verification is enforced, not requested
Sensitive actions — a payment arrangement, a change to an account, anything that alters a customer’s record — are locked behind verification, and the lock is held in state that the conversation cannot talk its way past. A caller cannot persuade Grace that they were verified earlier, because whether they were is not something the conversation decides.
This is the mechanism we would point a security reviewer at first, because account takeover through a customer service channel is a real attack rather than a theoretical one, and “the agent was instructed to verify people” is not a control.
Continuous review
Automated review, manual review and success metrics all feed the same loop: find where the agent got it wrong, correct it explicitly, verify the correction held.
The intent is an agent that measurably improves against your own calls over time, with each change traceable to the conversation that prompted it.
The short version
Safety here is not one feature. It is the fine-tuning, the guardrails, the review agent, working inside your systems, tenant isolation, enforced verification, and a review loop that closes.
If your security team wants to go through any of these properly, that is a conversation we are always happy to have — it is usually the most productive meeting in a deployment.