Where an AI assistant can be trusted, and where it cannot yet
OutpaceCRM has an assistant that answers questions about contacts, campaigns and what to do next, and can make small changes when asked. Before Outpace relied on it, and before offering it to anyone else, one plain question had to be answered: where can this assistant be trusted, and where can it not?
Outpace tested every kind of question and task the assistant is meant to handle, 53 in all, three times each, against facts that were checked first. The result was not a tidy success story. Of the 54 checks that matter, 44 passed and 10 failed, and the failures stayed on the record. The tests also showed something a pass mark would have hidden: some answers were factually right but poor to receive, because they spoke in the system’s language or buried the useful part in a wall of text. That finding now has an owner and a next step.
What the business gained: decision confidence. Outpace knows which jobs the assistant can be given today, which need work first, what each answer costs to produce, and what to fix next. That is a stronger basis for investing in AI features than a demo or a headline score. Accepting the result meant the evidence was complete enough to decide from. It did not mean every check passed or that the assistant was ready for customers.
By Outpace. Product direction, evaluation and engineering for OutpaceCRM, Outpace’s own product. August 2026.
At a glance
- Producer
- Outpace
- Beneficiary
- Anyone deciding whether to rely on the assistant now, and CRM users as the fixes land
- Setting
- The OutpaceCRM assistant, tested on development data, never on live customer records
- Scale
- 53 kinds of question and task, 165 test runs
- Accepted result
- 44 of 54 checks passed, 10 failed, one observed without a pass mark
01Context
Where they started
The assistant already covered a lot of ground: direct questions about the CRM’s records, follow-up questions in a conversation, help on a contact’s own page, questions about timing and priorities, a view of campaigns, small controlled changes, and the limits of what each user is allowed to see.
The risk was not simply a wrong answer. An assistant that sounds confident can be treated as dependable before anyone has checked it across the whole of what it does. Each answer also costs money to produce, some set off work in the background, and some change data. Nobody had the whole picture.
At the end of August the evidence was real but partial. Of the 53 kinds of task, 24 had been checked automatically. The rest, including conversations with several turns and tasks that change records, still needed a person watching. That was enough to trust particular behaviours, and not enough to decide about the assistant as a whole.
02Challenge
What was in the way
The test had to compare unlike things without flattening them. A fixed lookup, an answer the assistant reasons its way to, a conversation that builds on earlier turns, a job finishing in the background, a refusal because of permissions, and a change that has to be undone afterwards all need different evidence. A pass could not simply mean that readable text appeared.
Every test run cost real money in model calls. Anything that changed data had to be put back afterwards. The facts the assistant was checked against had to be current. The live product could be checked for health but never used as a test bed. And the final judgement of whether an answer was good to receive needed a person, not a script.
03Objectives
What good looked like
- 01
Test every one of the 53 kinds of question and task, in the settings and user roles each one needs.
- 02
Run each three times against facts checked beforehand.
- 03
Count the cost of every model call, including the ones behind the scenes, rather than treating an unrecorded cost as free.
- 04
Confirm that background work finished, and that anything changed during a test was put back.
- 05
Keep the live product out of the tests.
- 06
Have a person score a chosen set of answers for how useful they are, and accept the result only after that review.
- 07
Keep the failures visible, and turn what they show into decisions with an owner.
04Approach
The decisions that mattered
Outpace started from the list of everything the assistant is meant to do and treated that list as the boundary of quality. First, every item on it was made testable by a script. Then every test was required to bring back the same evidence: the facts it was checked against, how long it took, what it cost in model calls, whether background work finished, and proof that any change was undone.
The method kept apart two things that are easily confused: whether the assistant did the right thing, and whether its answer was good to receive. Scripts settled the first, repeatably. A person settled the second, reviewing a prepared set of answers as the product’s owner and asking one question of each: would a customer find this useful?
The closing decision then lined up three things that had drifted apart: the tested state of the assistant, the product’s plan, and the method Outpace’s next AI product would use. The product kept its own test data and setup. The method was written down so it could be used again.
05Business value
What changed
Before24 of 53 kinds had been checked
What changedAll 53 kinds checked, 55 checks in all
What it does not proveCoverage is not the same as passing
BeforeOne partial run
What changedThree runs of every check, 165 in all, against facts checked first and with a person’s scoring
What it does not proveThree runs show repeatability now, not stability over months
BeforeNo result for the assistant as a whole
What changed44 of the 54 checks that matter passed; 10 failed; one was observed without a pass mark
What it does not proveA development result, not a production score, a customer outcome or a return on investment
BeforeCosts and effects not fully counted
What changedEvery accepted check records its model calls, whether background work finished, and that changes were put back
What it does not proveDoes not predict the cost of everyday use
BeforeRight answers that were poor to receive had not been named as a problem
What changedA named owner now holds the job of plain, scannable answers with no system language
What it does not proveThe fix is designed, not yet built or re-tested
BeforeThe evidence existed only inside the CRM
What changedOutpace’s next AI product adopted the same test-everything-first method
What it does not proveEach product still needs its own evidence
The immediate business benefit is decision confidence. Outpace can see where the assistant is dependable, where it is not, what each answer costs, and which weakness to fix next. That is a stronger basis for investment than a demo, a single score without evidence, or a list of shipped AI features.
06The lasting idea
A right answer is not the same as a good answer.
The tests found replies that were factually correct and still cost trust, because they spoke in the system’s language, buried the useful part, or presented an incomplete view as a complete one.
For a business, that is the difference between an assistant people rely on and one they double-check. Three patterns from the tests, with the standard the assistant is now held to. The “after” lines are the target, not yet what the product says.
Say the result, not the mechanics
- Before: “His current job title is Operations Manager. These were record-detail changes.”
- After: “The contact’s job title is now Operations Manager.”
Shape a long answer so it can be acted on
- Before: a run-on list of eleven names, ending “there are more matches than shown, so this list is partial”.
- After: “More than 50 contacts haven’t been contacted in 90 days. Here are the first five,” followed by a short table.
Say what cannot be confirmed
- Before: “Replies aren’t tracked automatically; check the campaign’s Activity tab for any responses.”
- After: “I can’t confirm whether anyone replied, because reply tracking isn’t available yet. The Activity tab shows recorded activity, but not every reply.”
The useful result first, in plain language, in the right shape. That is what earns trust.
07Transfer
If this sounds like you
What carries forward is the order of work: list everything the assistant is meant to do, make each item testable, check the facts first, run each test more than once, count what every stage costs, confirm background work and clean-up, then add human judgement before accepting a result. It suits any AI product whose quality cannot be reduced to one number.
Each product should keep its own test data, permissions, answer keys and definition of a good answer. A shared method can standardise the shape of the evidence and the discipline of acceptance. It should not pretend that different products share one runtime or one idea of quality.
From test evidence to everyday measurement
The tests established what has to be measured. Industry conventions for observing AI systems, such as OpenTelemetry’s for generative AI (opens in a new tab), would give a common vocabulary for measuring it continuously: one request traced through its model and tool calls, with consistent cost, timing and error details, comparable across providers and tools.
OutpaceCRM has not built that yet. It is a future option, not a condition of this result. Any prompt or answer content it captured would need to be opt-in, filtered and redacted, because it can contain customer data.
Have something worth making?
Let’s find the useful next move, whether you are at the first sketch or the part that keeps getting stuck.
Let’s talk it through ↗