Policy libraries must be versioned before agents use them

An agent quoting a superseded policy gives the wrong answer with complete confidence and a citation to back it up. Before any agent reads your policy library, every document in it needs a version, an effective date, an owner and a clear status: draft, in force or withdrawn. Without those, the agent has no way to know which rule applies.

Why does an unversioned library mislead an agent?

Most policy libraries were built for people, and people cope with mess. A compliance officer knows that the procedure on the shared drive was replaced last spring, that the PDF attached to an old email is a draft, and that the "final v3 revised" file is the one that counts. They fill gaps with memory and by asking colleagues.

An agent has no memory of the office. It reads what it is given and treats it as true. If the library contains two versions of the complaints procedure, the agent may cite either. If it contains a draft that was never approved, the agent may quote it as policy. If a withdrawn product's terms are still in the folder, the agent will answer questions about them as though the product still exists.

The result is the worst kind of error: grounded, specific and wrong. The agent can point to the paragraph it relied on. The paragraph is real. It just is not the rule.

What does a versioned library need?

Each document should carry, in a form the agent can read reliably:

• A unique identifier that stays the same across versions.
• A version number that changes with every approved revision.
• An effective date, and where relevant an end date.
• A status: draft, approved but not yet in force, in force, or withdrawn.
• An owner: the named person responsible for its content.
• An approver and approval date for the current version.
• Scope: which entities, products, customers or jurisdictions it applies to.

The agent should be connected only to documents marked in force for its purposes, with drafts and withdrawn versions excluded from what it can cite. The practical steps are covered in how to connect an AI agent to your policy library.

Old versions should not be deleted. They should be kept and marked, because some questions are about the past.

What about questions that straddle a change?

This is where versioning earns its keep. A customer complains about a fee charged two months ago. The fee policy changed last month. Which version applies to the complaint?

An agent with access only to the current version will answer under today's rules and get it wrong. An agent with access to a properly versioned library can find the version in force on the date of the charge and cite that one. The same applies to any historical review: a file check, a lookback exercise, a response to an auditor's sample.

This means the agent's request to the library should include a date, and the library should return the version in force at that date. It is a small design choice with a large effect on accuracy.

Who approves a new version?

A person, every time. Agents can help write policy updates: comparing a draft against regulation, suggesting wording, checking consistency with related documents. The approach is set out in how to draft policy updates for approval with an AI agent. But a policy is the firm's statement of how it will behave. Approving one is a decision about what the firm commits to, and it belongs on the list of compliance decisions that must stay with a person.

The approval step also matters for the agent. An agent should never be able to read its own draft as policy. If a drafting agent and an answering agent share the same library, drafts must be invisible to the answering agent until approved and marked in force.

How do you know the agent is using the right version?

Test it. Certification cases should include questions whose correct answer changed with a recent policy revision, and score the agent on whether it used the version in force. Include historical questions where the earlier version should apply. Include a question about a withdrawn product, where the right answer is that it is no longer offered.

These cases are cheap to write and catch an entire class of errors. They also make good drift checks: each new policy version should prompt a handful of new cases.

Testing also supports outcome monitoring. Under the UK's Consumer Duty, firms need to show their communications support good outcomes, and a policy answer based on a superseded version is a poor outcome waiting to happen. The relationship is explored in FCA Consumer Duty good outcomes: testing AI agents against them.

What does versioning cost?

For a firm with a tidy library, very little: metadata on documents that should already have it. For a firm with years of accumulated folders, it can be a real clean-up exercise. That cost is not created by agents; agents expose it. The same mess that misleads an agent also misleads new staff, auditors and occasionally experienced people.

It is still worth doing before the agent goes live rather than after. Every week an agent reads an unversioned library is a week of answers you cannot fully stand behind.

Where Pryme fits

In Pryme, the policy library is treated as a sealed source through the Pryme Context Protocol: each document reaches the agent with its version and effective date, and only versions in force can be cited for current questions. Historical questions can request the version in force on a given date. This fits the approach to AI compliance agents: second line, never the last word.