Agents
Policies as limits
Why your rules are enforced by what the agent is able to do rather than by instructions it is asked to follow, the six ways a rule becomes a limit, and what is checked rather than removed.
On this page
Every organisation has rules about what can be offered to a customer: pricing structures, approval limits, fees, entitlements, what is never done. In many AI systems those rules are written as instructions in the text the model reads, which means they depend on the model following them. Telonic builds your rules into what the agent is able to do: if your policy limits a meal voucher to AED 75, the agent has no way to issue one for more, however the request is phrased. This is what makes it reasonable to let an agent act for you.
A rule as an instruction, and a rule as a limit
A rule written as an instruction is something the model is asked to follow. It usually does. But a model generates its reply from everything in the conversation, and a persuasive, unusual or cleverly phrased request can lead it to write something the instruction did not allow. If the action it then calls accepts any value, nothing stops it.
A rule built as a limit works differently. The agent chooses from a defined set of actions, and each action accepts only the values your policy permits. A value outside the set is not available to choose. The customer can change how the agent words its reply, but not what it is able to do.
| A rule as an instruction | A rule as a limit | |
|---|---|---|
| Where the rule lives | In the text the model reads | In the actions and values the agent can use |
| What decides the outcome | Whether the model follows the text | Whether the action and value are in the permitted set |
| What rephrasing a request can change | Potentially the outcome | Only the wording of the reply |
| How you check it | By testing many phrasings, without being able to cover them all | By reading the permitted set, and testing it |
| What the record shows | What the model wrote | The action, the value, and the rule that permitted it |
Six ways a rule becomes a limit
During implementation, your team and Telonic go through your rules one by one and decide how each is built into the deployment. Most rules become one or more of the following.
| Mechanism | What it means | Example |
|---|---|---|
| 1. Permitted actions | The agent can take only the actions connected to it. An action that is not connected cannot be taken | The agent can reschedule a viewing, but has no action that cancels a reservation |
| 2. Permitted values | Each action accepts only the values your rules allow | Rebooking only onto flights the passenger's fare permits. Quotes only within your rating rules |
| 3. Actions not exposed | Decisions that belong to your people are not connected to the agent at all | There is no action to approve or decline a claim, or to refund outside policy |
| 4. Approval gates | Actions you mark as sensitive are prepared by the agent and held until a person approves them | A goodwill credit is prepared with the reason and waits for a supervisor |
| 5. Values from your systems | Terms are retrieved from your systems, so the agent cannot construct its own | A payment plan is read from your structures. There is no action that writes a new one |
| 6. Figures from the record | Amounts and dates in a reply are inserted from the system record, not retyped by the model | The instalment amount a buyer hears is the amount in your payment system |
The sixth closes a gap the others leave open. Even when a figure has been retrieved correctly, a model that retypes it into a sentence could alter it. In a Telonic reply, the language model (the AI component that composes the reply) writes the sentence, and the figure itself is inserted from the record.
The technical detail
Each connection to your systems exposes a defined set of actions through an API (the interface one system uses to request information or actions from another). Each action has its own permission, set with your IT team, and its own permitted values. Read access and write access are granted separately. See Permissions.
These limits are enforced in Telonic's software, outside the language model: the model can propose an action, but the action is carried out only if it and its values are in the permitted set. An action outside the set is not carried out, and the conversation follows the escalation rule you have set for that case. Every action, its values and the rule that applied are logged. See Audit trail and decision records.
A limit is applied exactly as it is set. That makes the review of your limits during implementation, and of every later change, as important as the limits themselves. See How changes go live.
What is checked rather than removed
Some rules are about what the agent says rather than what it does. The topics it will not discuss, such as legal or investment advice, are enforced by a check on every turn of the conversation. A question on an out-of-scope topic is declined and routed to a person, including when it is rephrased.
This is a check, not an architectural removal, and we describe it as one. The language model could in principle produce text on any subject, so topic scope is enforced by checking each turn and is tested before every release, with rephrased and indirect versions of the questions you have placed out of scope. See Testing before every release.
Tone and wording are shaped the same way: by the design of each conversation, and by checks after it. Every conversation is scored against your quality standard, and conversations can be checked against compliance rules your team sets, configured during implementation. See Quality review on every conversation and Compliance flagging.
| What the agent does | How it is enforced |
|---|---|
| Takes an action in your systems | Limit: only permitted actions exist |
| Uses a value, such as an amount or a date, in an action | Limit: only permitted values are accepted |
| States a figure from your systems | Limit: the figure is inserted from the record |
| Makes a decision that belongs to your team | Limit: the action is not exposed |
| Discusses a topic | Check on every turn, tested before every release |
| Chooses its tone and wording | Conversation design, reviewed on every conversation |
Where your rules come from
Many of your rules already live in your systems. Fare rules sit in the reservation system, payment structures in the property management system, and rating rules in the policy administration system. Where they do, the agent reads them from there, so the limit stays current when your system changes.
Rules that live in policy documents, such as a voucher limit or a goodwill threshold, are set in your deployment during implementation. Your team can change them afterwards through the controls it holds in the console (the Telonic web application your team uses), and every change is tested before it goes live. See The controls your team holds.
In practice
Rimal Air, an airline, uses a Telonic agent for passengers affected by delays and cancellations.
- A flight to Muscat is cancelled late at night. Tariq, travelling with his wife and daughter, messages the airline.
- The agent finds the booking and reads the fare rules from the reservation system. It offers the two flights the fare permits the next morning. Tariq chooses one and is rebooked.
- Tariq asks for more than a meal voucher. The agent issues three vouchers at the policy limit, the most it can issue.
- He asks for a cash refund of the whole ticket. The fare rules do not permit it, and the agent has no action that could issue one. It tells him so plainly, and hands the request to the duty team with a brief.
- The duty team approves a goodwill credit, a decision that sits with them. The audit record shows each action, the value, and the rule that permitted or prevented it.
What your team controls
- The actions the agent can take in each system, and the values each accepts.
- Which actions wait for a person's approval, and who approves them.
- The topics the agent never discusses.
- What happens when a request falls outside the limits: who receives it, and on which channel.