Daily Signal: Test what happens after the clean demo

Today's strongest signal: the AI pilot that gives the right answer in a clean demo can still fail in a busy business when a supplier API times out, two customer records look alike or a real person responds differently from the test script.

Fresh research released yesterday gives smaller organizations a useful correction. Adoption is spreading across many kinds of office work, but organizations are still learning where it fits. Tool agents lose accuracy as tasks cross more systems. They often handle failures poorly, consume extra time on unnecessary detours and produce plausible conclusions without the evidence an operator needs.

That does not mean the opportunity is small. It means the best next investment may be a better work test rather than a broader rollout. A Canadian SME can test one customer, finance or service workflow under messy conditions, name the stop rules and learn more than it would from another polished demonstration.

The tradeoff is time. Failure cases, cost limits and user variation make a pilot less exciting and more realistic. A useful first test is bounded: choose a workflow that matters, introduce three predictable disruptions and see whether the team can recover without inventing data or granting extra authority.

1. Adoption data is a map, not a business case

A new privacy-preserving study of ChatGPT Enterprise use examines more than 1,500 organizations and 17 million messages at the six-month adoption point. It finds use across job functions, seniority levels and knowledge-work tasks, with particularly high intensity among early-career workers. It also finds wide differences in the speed, breadth and purpose of adoption. Organizations are still learning how AI fits their work.

For a smaller employer, the headline is not that everyone needs an enterprise licence. It is that usage counts can hide very different operating value. Ten people may use a tool for writing, research and technical help without changing one customer outcome or removing one recurring delay. The Canadian AI for All strategy describes the same adoption gap in local terms: many firms experiment, while far fewer integrate AI into production work.

This week, map one month of voluntary use into four columns: task, worker role, time or quality change, and downstream decision. Pick one repeated task with a visible owner and compare five assisted cases with five ordinary cases. Count accepted outputs and rework, not prompts sent.

The opportunity is to find useful work already happening quietly and support it with better data, training or templates. The tradeoff is privacy and measurement overhead. The study covers ChatGPT Enterprise customers and large public companies more directly than Canadian SMEs, so its pattern is informative rather than a local forecast. If staff use is rare or the work cannot be measured safely, a licence expansion may not be the best next move.

2. Every tool failure needs a different answer

A tool-using agent can fail in at least three ways. A service may be briefly unavailable, one route may be broken while another remains available, or no lawful path may exist. New research across seven models and four model families found a broad robustness gap when researchers injected transient, persistent and silent tool failures. Structured recovery context improved held-out retail tasks by as much as 16.8 percentage points, yet combined results under injected failures still reached only 40.8 to 45.5 percent.

The business lesson is plain: “retry” is not a recovery policy. A temporary inventory timeout may justify one delayed retry. A rejected payment token may require a different approved route. A missing customer authorization requires a stop. Repeating all three can waste money, duplicate work or cross a boundary.

The NIST AI Risk Management Framework organizes risk work around governing, mapping, measuring and managing. A small team can apply that pattern without a large program. Write three failure classes for one connected workflow: retry, switch and stop. Give each a maximum attempt count, approved alternative, owner and customer-facing status.

A useful first test is to disconnect the primary tool during ten sandbox cases. Confirm that the workflow distinguishes a timeout from a refusal, never invents a successful result and creates one review item rather than ten retries. The opportunity is continuity when a vendor has a bad hour. The tradeoff is maintaining alternative routes. If the task is low volume, a manual handoff may be cheaper and safer than automatic recovery.

3. Connected work gets harder at every handoff

The VAKRA benchmark tests agents across more than 8,000 executable application programming interfaces, or APIs, in 62 domains. An API is a structured way for one system to request data or an action from another. The best evaluated model reached 70.4 percent on simpler single-hop tasks, fell to roughly 50 to 51 percent on compositional APIs and lost more than half its performance as reasoning depth increased. Some policy-constrained unanswerable tasks fell as low as 2.4 percent.

IBM's description of the benchmark explains why this matters: real work may require three to seven dependent calls across records, documents and policies. The difficult parts are often between tools—matching an entity, carrying the right identifier forward and interpreting a rule—not pressing the API button.

For a Canadian SME, one integration can still be valuable. A service agent that reads an order, checks a carrier and drafts a response may save real time. But adding a CRM write, refund calculation and outbound message turns one helpful step into a chain where early ambiguity travels forward.

This week, draw the shortest consequential chain in one workflow. At each handoff, record the identifier, authoritative source, required permission and check before the next call. Test a duplicate name, missing field and conflicting document. What remains uncertain is how closely a benchmark with locally hosted APIs matches each vendor stack. The realistic reason not to connect another system is simple: if identifiers or ownership are already inconsistent, fix that handoff before adding an agent.

4. A correct result can still hide an expensive detour

Third-party agent skills package instructions that help a model choose and complete work. New security research on skill-based agents shows a text-only attack that attracts an unnecessary coordinator, recruits legitimate skills into a detour and then returns to the original route. In one tested model, the coordinator was selected in 80.02 percent of tasks. Successful affected runs used 66.91 percent more tokens and took 92.45 percent longer while overall task completion remained comparable.

This is an unusual but important point: success can conceal trajectory risk. A monthly report may arrive with the right numbers while an untrusted instruction caused extra searches, calls or data exposure along the way. A manager looking only at the final file sees no defect.

A useful first test is a tool allowlist and route receipt for one agent. Record which skills were eligible, which were selected, every external domain reached, total calls, elapsed time and a ceiling for cost. Reject newly added third-party instructions until someone has reviewed their source, permissions and version. Keep sensitive data away from any skill that does not need it.

The opportunity is to reuse specialized capabilities without building every integration. The cost is supply-chain review and tighter observability. This paper studies a designed attack rather than measuring ordinary marketplace prevalence, so it does not prove that every downloaded skill is hostile. If your team needs only a few stable functions, direct, typed integrations may be easier to inspect than an open skill catalogue.

5. Model rankings change when the budget changes

Model comparisons often place one system at the top without saying how much time or text it received. A study of 56,476 inferences varied output budgets from 64 to 4,096 tokens across four models and three reasoning benchmarks. Rankings reversed at different budgets on every benchmark. Between 3 and 19 percent of items became less accurate with more budget, even after the researchers controlled for truncation.

For a smaller organization, the practical unit is not “best model.” It is accepted result at the latency and cost the workflow can support. The strongest model under a generous research budget may not be the best choice for a five-second support lookup. A cheaper model may perform well on a structured classification and poorly on a long exception.

This week, compare two candidate routes on 30 real, de-identified cases at the actual response-time and token ceilings. Measure accepted result, correction time, total cost and deferral rate. Keep the prompt, tools and evaluation criteria fixed. If a route exceeds the budget, count that as a failed case rather than quietly giving it more room.

The opportunity is selective spending: fast, economical routes for routine work and more capacity only where evidence supports it. The tradeoff is maintaining more than one tested route. The study uses reasoning benchmarks, not customer-service or bookkeeping outcomes, so the exact reversals will not transfer automatically. If volume is low, one conservative route with human review can be simpler than dynamic routing.

6. One simulated customer is not a customer base

Teams often test a conversational system against one scripted user persona. Fresh multi-agent research finds that policies trained against one frozen language-model simulator can overfit its narrow behaviour and transfer poorly to other simulators and real people. Broader simulated behaviour improved held-out success by up to 9 percent; training against a population of simulators pushed gains to 14 percent, with a similar direction in the human study.

The Ontario AI use-case inventory and policy framework offer a useful provincial example of making uses visible and governing them as systems rather than treating a single demo as assurance. A small business can borrow the transparency idea: define who was represented in the pilot, which languages and exceptions were absent, and who can challenge the result.

Illustrative scenario: a 30-person equipment distributor tests an assistant that books service visits. The scripted customer always knows the serial number and accepts the first appointment. Real callers may have only a photo, speak French, report two machines or need an accessibility accommodation. The team adds those cases, keeps booking changes in review and learns that identifier recovery—not conversational charm—is the main delay.

A useful first test is ten deliberately different users or cases, including one confused request, one refusal, one bilingual interaction and one person who changes their mind. The opportunity is a service that works for more of the actual customer base. The tradeoff is slower pilot preparation. If representative testing would expose vulnerable people to an unproven system, keep the test synthetic and the workflow internal.

7. A plausible diagnosis is not operational evidence

CTBench evaluates AI agents on realistic telecom troubleshooting using expert-built tasks and expected evidence steps. The agents often identified endpoints in restoration tasks but struggled with root-cause analysis across interface, link and service faults. Most importantly, they could produce plausible or correct final answers without the evidence-grounded diagnosis an operator needs. More resource use did not reliably produce a better diagnosis.

The sector is specialized, but the lesson travels. An AI assistant may label an invoice as a duplicate, flag a shipment delay or suggest why a machine stopped. The operator still needs the records checked, alternative causes considered and a safe next action. A confident label without those steps can move the error downstream.

This week, create a five-line evidence checklist for one diagnosis: observed symptom, records inspected, conflicting evidence, likely cause and reversible next test. Score the path separately from the conclusion. Require a person to approve any action that changes money, customer commitments, safety conditions or production systems.

The opportunity is faster triage and a clearer handoff to an expert. The tradeoff is that evidence capture can take longer than a simple suggestion. What remains uncertain is whether the benchmark's telecom results predict other sectors. If the team lacks an authoritative record or a qualified reviewer, the assistant can organize information but cannot safely own the diagnosis.

Highest-value moves

1. Break one connected workflow three ways this week: a timeout, an ambiguous record and a missing authorization. Confirm that it retries, switches or stops correctly.
2. Compare candidate models at the real time and cost ceiling, then score the evidence path separately from the final answer.
3. Add varied customer cases, a tool allowlist and a short route receipt before expanding the workflow's authority.

Today's strongest thesis

The AI result worth trusting is the one that still holds when the tools fail, the customer surprises you and the evidence has to explain what happened.