Diagnose first, then pull the right lever. Most agent failures come from a missing or outdated source, an unclear brief, a tool too broad, or a case that should have gone to a person. Each has a fix that leaves the model's weights untouched. Make the change, re-test on your own cases including the failures, and release through change control.
Why not retrain the model?
Because the problem is rarely the model's general ability. An agent that gives a wrong answer about a customer's entitlement usually lacked the right policy, read an old version, or was asked to judge something it should have handed over. Retraining would not fix any of those, and it would make the agent harder to test, slower to change, and harder to explain.
Retraining also hides the fix. A changed source or brief can be read, reviewed and reversed. A change to weights cannot be inspected the same way. Whether fine-tuning ever makes sense is a separate question, covered in should you fine-tune a model for your AI agent.
Which lever fixes which failure?
| Failure pattern | Likely cause | Lever |
|---|---|---|
| Wrong fact, confidently stated | Missing or outdated source | Add or update the source |
| Right source, wrong reading | Ambiguous wording in the source or brief | Clarify the brief; add a worked example |
| Acts on cases it should hand over | Hand-over trigger missing | Add the trigger; tighten bounds |
| Hands over cases it could handle | Trigger too broad | Narrow the trigger, after testing |
| Does the right thing in the wrong system | Tool too broad | Narrow or split the tool |
| Inconsistent tone or format | Brief lacks examples | Add examples to the brief |
| Fails on a new kind of case | Case type never tested | Add cases to the test set, then fix |
| Wide, unexplained decline in quality | Model update or input change | Re-test; compare versions; consider a different model |
The last row is the one place the model itself is in question. Providers update models, and behaviour can shift; model drift explains what to watch. Even then, the response is to re-test and, if needed, switch to a model that passes, not to retrain.
What are the steps, and who does each?
- Agent operations lead: collect and group failures. From feedback, rejections, edits and samples. Evidence: grouped failure list.
- Agent operations lead and subject expert: diagnose. For each group, trace a few cases through the record: what did the agent read, what did it conclude, where did it go wrong? Evidence: diagnosis note per group.
- Process owner: choose the lever. Source, brief, tool, bound or trigger. Evidence: the change request.
- Platform team: make the change in test. Evidence: the changed version.
- Agent operations lead: compare versions. Run old and new on the same cases, including the failures. Evidence: comparison results.
- Process owner and risk: approve. Evidence: the change control record.
- Team lead: watch after release. Evidence: the next weeks' feedback on that group.
What does this look like in practice?
Take a payroll bureau's query agent, which answers employees' questions about pay and leave. Feedback shows it giving wrong holiday entitlement answers to part-time staff.
The operations lead traces five cases. The agent was reading the full-time entitlement table correctly and then not adjusting for hours, because the pro-rata policy lived in a separate document nobody had registered as a source. The fix is to register that document. The new version is compared with the old on the original test set plus forty part-time cases. It gets the part-time cases right and changes nothing else. The change is approved and released, and the next month's feedback on entitlement questions is clean.
Nothing about the model changed. The cost of the fix was a few hours of diagnosis, which is typical: the expensive part of running agents is the operating work around them, as argued in the cost of an agent is not the model bill.
Which controls make improvement safe?
- Every change goes through change control, however small.
- Failures join the test set, so fixed problems cannot quietly return.
- Version comparison on the same cases before release.
- One lever at a time where possible, so you know what worked.
Where Pryme fits
Pryme works this way by design: we never update model weights for a customer. Improvement means changing the agent's brief, sources, bounds and certification, and Attest re-tests the agent on your own cases before the change takes effect. More in deploying an AI agent: train, shadow, certify, widen.
Questions people ask
How do we know whether the problem is the model?
If failures cluster around specific cases, sources or rules, it is almost certainly not the model. If quality drops broadly after a model update, compare versions on your test set.
Can the agent improve itself from feedback?
It should not change its own brief or sources. Feedback is evidence for a change that people approve and test.
How often should agents be improved?
Continuously, in small reviewed changes. A monthly cycle of diagnosis and release suits most teams.