Give every source an owner, a version, an effective date and a review date, and read it from where it is maintained, not from a copy. When the owner publishes a new version, re-test the capabilities that rely on it before the agent uses it. Flag sources past their review date, and watch for answers that cite a superseded version.
Why do sources go stale?
Because copies do. Most stale sources begin as a sensible shortcut: someone exports the fee schedule, saves the procedure as a file, or pastes the policy into the agent's knowledge base. The original is then updated and the copy is not. Nobody notices until a customer is quoted the old fee.
The second cause is ownership. A source with no named owner has nobody whose job it is to say "this changed". The third is timing: a new version may be published before it takes effect, and an agent that switches early is as wrong as one that switches late.
How does each kind of source go stale?
| Source type | How it goes stale | Control |
|---|---|---|
| Policies and procedures | Updated in the policy library; old copy remains in the agent's store | Read from the library; version and effective date on every read |
| Product terms and fee schedules | New version published ahead of its effective date | Effective dating: the agent applies the version in force on the relevant date |
| Rate tables and limits | Changed by a business decision, sometimes informally | Owner approval for every change; no informal edits |
| Regulatory texts and guidance | Updated by the regulator | Named owner in compliance monitors and registers changes |
| Customer and account data | Changes constantly | Read live from the system of record with a timestamp |
| Templates and letters | Edited by teams without telling anyone | Template library with owners and change history |
Customer data is different from documents. It should never be copied into the agent's sources; it should be read live, with the time of the read recorded.
What are the practical steps?
- Register every source. Name, owner, location, version, effective date, review date.
- Read from the system of record. Point the agent at the policy library, the product database, the core system. Remove copies.
- Apply effective dates. The agent uses the version in force on the date that matters for the case, not simply the newest.
- Link changes to testing. When a new version is registered, the capabilities that rely on it are re-tested before it goes live for the agent.
- Flag overdue reviews. Sources past their review date are listed weekly for their owners.
- Watch citations. If the agent cites a superseded version, treat it as a defect.
- Retire withdrawn sources. Removing a source is a change too, recorded and tested.
Making sources visible to reviewers helps catch staleness early; see whether an AI agent should show its sources.
What does this look like in practice?
Take a retail bank changing its overdraft fees. The new fee schedule is approved and published six weeks before it takes effect. The schedule's owner registers the new version with its effective date.
Registration triggers re-testing of the agent's fee-related capabilities against cases dated both before and after the change. One problem appears: for a customer asking about a charge from last month, the agent quoted the new fee. Its brief said "use the current schedule". The brief is changed to "use the schedule in force on the date of the transaction", re-tested, and released before the effective date.
On the day the fees change, the agent answers questions about older charges with the old schedule and newer charges with the new one, and cites the version each time.
Who should own source upkeep?
The person who owns the content, not the agent team. The fee schedule's owner owns the fee schedule, whether a person or an agent reads it. The agent operations lead owns the register and the review routine.
This work takes time, and it is easy to under-resource. Agents free up staff time; some of it should go to keeping sources current, which is worth deciding before the time is absorbed elsewhere; see deciding what to do with the time agents free up.
Where Pryme fits
In Pryme, every fact reaches the agent through the Pryme Context Protocol with its origin and provenance class. A policy read from the policy library itself can be sealed; a copy in a shared folder cannot. Sources are one of the five bounds checked at the moment of action, and a change to them prompts a new Attest run, where the stable gate checks that the same question still gets the same answer. More in deploying an AI agent: train, shadow, certify, widen.
Questions people ask
How often should sources be reviewed?
At least as often as the content itself is reviewed under your policy framework, and whenever the owner changes it.
Can the agent tell us when a source is out of date?
It can flag conflicts between sources, or sources past their review date. It cannot know a policy changed if nobody registered the change.
What about sources from outside, like regulator guidance?
Assign a named owner who monitors them and registers changes. The agent should never fetch them from the web on its own.