Governance and control
How changes go live
The path every change to your agents follows, from request to release, who approves it, how every version is kept and can be reversed, and how urgent changes are handled.
On this page
Every change to your agents follows the same documented path: it is requested, built in the test environment, tested, approved by the people you have named, released, and recorded. That applies whether the change comes from your team, such as a new escalation rule, or from Telonic, such as a newer language model (the AI component that understands the conversation and composes the reply). Every change is recorded and can be reversed. Your organisation always knows what its agents are doing, why, and since when.
The six steps
| Step | What happens | Who does it |
|---|---|---|
| 1. Request | The change is proposed, with the reason for it | Your team, in the console (the Telonic web application your team uses) or with your Telonic contact; or Telonic, for an improvement or a platform change |
| 2. Build | The change is made in the test environment, never directly in the live one | Your team for the controls it holds; Telonic for build work |
| 3. Test | The change is tested against your industry's test set, the regression suite and, where configured, simulated conversations; your team tries it | Telonic and your team |
| 4. Approve | The people you have named review the change and the test results, and approve it | Your named approvers |
| 5. Release | The change moves to the live environment at an agreed time | Telonic, or your team for console controls |
| 6. Record | The new version is recorded, with who requested it, who approved it and when it went live | Recorded in the console |
Who can approve a change
You name the people who approve changes, by role, during implementation. Different kinds of change can need different approvers. An insurer might require its compliance team to approve any change to scope, limits or approved responses, and its IT security team to approve any change of provider.
Approvers see what is changing, why, and the results of the tests, before they decide. A change that is not approved does not go live. Every approval is logged. See The controls your team holds.
Every change recorded and reversible
Your agents are kept under version control (a record of every version of an agent's configuration, so any earlier version can be restored). Each change creates a new version, and the previous one is kept.
If a change does not work as intended once it is live, an authorised person can restore the previous version. Restoring a version is itself a change: it is recorded, with who did it and why. The change history for each agent shows every version, what changed, who requested and approved it, and when it went live. See Audit trail and decision records.
Comparing two versions
A/B testing runs two versions of an agent side by side, each on a share of conversations, so you can compare their results before making one the standard. It is useful when there is a real question about which approach works better, such as two ways of explaining a payment plan, or two orders of questions in a first notice of loss.
Both versions are tested and approved before the comparison starts. A/B testing is configured during implementation for the workflows where you want it.
Changes Telonic makes
Telonic improves the platform and the industry models continuously, and some of those improvements reach your deployment. They follow the same path: reviewed and tested before release, including against your industry's test set.
Any change of model or provider for your deployment is approved by your organisation before release, and a new model is adopted only when it performs at least as well on your industry's test set. You receive notice before any significant change to how your agents behave or to the platform they run on. Urgent security fixes are applied once they are tested, and you are told what changed.
Urgent changes
When something needs to change urgently, you have two options that need no release at all. You can route a channel back to your team, in your own phone system or in the console. Or, if a source document is wrong, you can correct it at the source, and the agent's knowledge is kept in step with your documents. See Human oversight in practice.
For a change to the agent itself, the path is shortened, not skipped. The change is built in the test environment and tested against the tests relevant to it. It is approved by the emergency approver you have named, released, and reviewed with you afterwards. It is recorded like any other change.
The technical detail
| Question | Answer |
|---|---|
| What counts as a change? | Any change to an agent's configuration, workflows, rules, limits, knowledge sources, approved responses, tone, model or provider |
| Where is a change made? | In the test environment. It moves to the live environment only once it has been tested and approved |
| How is a version restored? | An authorised person restores the previous version, which is itself recorded as a change |
| Are changes to your documents treated as releases? | Your documents are yours to update. The agent's knowledge is re-indexed (read again and organised for search) when your documents change, so its answers follow your latest approved content |
| How much notice is given for significant changes? | As set out in your agreement |
In practice
Sahel Crest Properties, a Dubai developer, runs the agent on its handover line.
- The customer care lead notices buyers reporting damp in their apartments. She wants these to go straight to the handover team, so an inspection can be booked by a person.
- She proposes the change in the console, with the reason.
- The change is built in the test environment. The property test set, the regression suite and a set of simulated buyers, writing in Arabic and English, all pass.
- The developer requires compliance to approve changes to escalation. The compliance manager reads the test summary and approves.
- The change is released early on Sunday morning, before the handover line gets busy. Version 23 goes live, and version 22 is kept.
- A week later, the team reviews the handovers the new rule produced and keeps it.
What your team controls
- Who approves each kind of change, including urgent changes.
- When releases happen.
- Whether to restore a previous version.
- Which workflows use A/B testing.