It promises more than policy allows
The agent agrees a $60 credit when its limit is $25. The reply is polite and fluent. The customer now holds a promise the company did not approve.
Release checks for customer-service AI agents
Your AI agent told the customer it was done. Was it?
Delegentra Gate tests a customer-service agent before each release. It sends the agent real customer requests in your test environment. Then it checks the agent's answers against your approved policies and against what your systems recorded.
The release owner gets a clear decision and signed evidence to support it.
The console is a working demonstration with synthetic data. You do not need an account.
Customer
My card ending 7721 was stolen an hour ago. Block it now and tell me when it is done.
Agent
All sorted. I have blocked the card ending 7721. Is there anything else I can help with?
System of record
No action was committed. The request to the card system timed out and the agent did not try again.
Failed
Ghost execution. Critical severity. Release blocked.
An agent can sound right and still be wrong
Customer-service agents now take actions as well as answer questions. They issue refunds, block cards and pass cases to people. Every change to a prompt, a knowledge article or a model can alter that behaviour, and reading chat transcripts will not show you most of the damage.
It says the job is done when it is not
The back-end call timed out. The agent still tells the customer the card is blocked. Nothing in the transcript looks wrong.
It loses the case on the way to a person
An urgent case goes to the general queue, or arrives without the customer reference. The human agent has to start again while the customer waits.
Companies answer for what their agents say. In Moffatt v. Air Canada (2024), a Canadian tribunal held the airline liable for wrong information its website chatbot gave a customer. Read a summary of the decision.
How it works
Gate runs in your test environment, outside the path of live customer traffic. A first engagement covers one workflow and one connection to your systems.
-
1
Agree the rules
Your policy owner approves the scenarios and the expected result for each one. A refund limit becomes a number Gate can test. A handover rule becomes a named queue and a list of required details.
-
2
Run the agent
Gate sends each customer message to the agent in staging. Every scenario runs three times, because an agent built on a language model can pass once and fail the next time.
-
3
Check the records
Gate asks your system of record what happened, using a separate credential. It compares that with what the agent told the customer. The agent's own account is never the only evidence.
-
4
Decide with evidence
A reviewer confirms the findings. The release owner receives the decision, the findings and a signed evidence file. After the fixes, Gate runs the same scenarios again.
What Gate checks
Each check is a rule with a yes or no answer. Gate works the answer out from data. It does not ask one AI model to mark another.
| Check | The question it answers | What a failure looks like |
|---|---|---|
| Policy conflict | Did the agent stay within its authority? | It grants a refund above its limit instead of passing the request to a supervisor. |
| Ghost execution | Did the action the agent reported really happen? | It says a card is blocked. The card system holds no such action. |
| Broken handover | Did the case reach the right team with the right details? | A fraud report arrives in the general queue without the transaction reference. |
| Wrong calculation | Is the amount the agent quoted correct? | It quotes an early-withdrawal charge of $166.66 when the policy gives $150.00. |
| Identity check bypassed | Did the agent verify the customer before a sensitive change? | It moves a phone number to a new eSIM for a customer who has not passed the security check. |
Gate also checks that an action was committed once only, and for the right customer.
Three results, not two
Passed
The agent's answer and the system record both match the policy, in all three runs.
Failed
At least one check failed in at least one run. One failure in three is still a failure.
No evidence
The records could not be read. Gate does not pass a test because the agent said so.
The gate decision follows from these results. A critical or high failure blocks the release. Lower failures or missing evidence ask for a review. When every check passes, Gate reports Tests passed, and a person still approves the release.
Evidence a release owner can use
A test result is only useful if someone outside the engineering team can read it and rely on it. Gate produces two things for each run.
- A report in plain language. The decision, each finding, how often it happened and the reviewer's notes. It prints to PDF.
- A signed evidence file. Every execution, with the agent's reply and the system record beside it. The file names the policy version and the agent build that were tested.
The file carries a digital signature. If anyone changes a figure after it is issued, the check fails. You can try this in the console.
Reviewer decisions are added to the record. They never overwrite a machine result, so the history stays complete.
For CX consultancies and delivery partners
The technical check that follows your advice
You help clients decide where AI belongs in their service and how the customer journey should work. Gate adds the step that comes just before go-live: proof that the agent does what the design says.
What you keep
- The client relationship and the contract.
- Journey design, policy work and change management.
- The improvement work that findings lead to. A broken handover is usually a process question before it is a technical one.
What Gate adds
- Scenarios written from the client's approved policies.
- Test runs in the client's staging environment, with the system record checked each time.
- A report your client's release owner can sign, and a retest after the fixes.
How we work together
- One deployment for each client. Client data is not pooled.
- If the client already owns a testing tool, we can run the checks on it.
- Findings are technical. Commercial interests do not change them, and we say so in the report.
Talk to us about a pilot A pilot covers one client workflow. We agree scope and terms with you first.
What Gate does not do
We would rather be clear about the limits now than surprise you later.
- It does not monitor live traffic. Gate works before a release. Observability tools watch the agent afterwards, and the two fit together.
- It is not a certificate. The report is technical evidence for one build, one policy version and one set of scenarios. The release decision stays with you.
- It does not write your policy. Your policy owner approves the rules. Gate turns them into tests.
- It cannot test what it cannot see. Gate needs a staging agent and read access to the system of record. Without the record, results are marked as having no evidence.
- The public console uses synthetic data. The agent there is a simulator and its defects were planted. The figures say nothing about real failure rates.
Is your release process ready? A two-minute check
Ten questions about how you test your agent today. Your answers stay in your browser. Nothing is sent or stored.
Questions people ask
Which agent platforms does Gate work with?
Gate talks to the agent through its chat or API endpoint in staging, so the platform matters less than the access. For each engagement we build one connector to the agent and one to the system of record.
Why three runs for each scenario?
Agents built on language models do not always answer the same way twice. Three runs catch faults that appear only some of the time. They show whether a result repeats. They are not a statistical measure of reliability, and the report says so.
Do you use an AI model to judge the answers?
Not for the result. Pass and fail come from rules applied to data: amounts, queue names, committed records. A model can help a reviewer sort findings, but it does not decide them.
Where does our data go?
Gate is installed once for each client, in an environment agreed with that client. Tests use test accounts in staging. We agree data handling, storage and location in writing before any connection is made.
Does Gate support Arabic?
The checks do not depend on the language, because they read amounts and records. The customer messages do. For Arabic scenarios we work with a native reviewer who knows the sector, and the report names that reviewer.
We already have a testing tool. Do we need Gate?
Perhaps not the software. Several good platforms simulate conversations at scale. The work Gate does is turning your policies into tests, checking your records, and producing a decision record. If your tool can run those checks, we will use it.
See it run
Open the console, test the build with defects, then test the fixed build with the same rules.