Your AI agents will read your figures and your policies: which of them has an official version?

Your metric definitions have an owner. Your policies often only have an upload date. A parity log measures the gap before the agent goes live.

A customer credit agent deciding whether to hold an order reads two things: the customer’s outstanding balance, which is a figure, and the credit policy, which is a document. On 3 November, a data platform vendor announced a service that serves its agents only approved definitions, each with an accountable owner. Its own text lists “which policies to follow” as part of the context agents need. The reversal fits in one line you can repeat in a steering committee: if nothing is written on the policy, your agents will read a figure that has an owner and a policy that only has an upload date.

AI agent context therefore has two halves. The first, data, is getting a discipline every CDO knows: approved definition, owner, change history. The second, documents, is getting more relevant and faster search. Nothing in these announcements declares which of your documents is in force. Yet the policy is what tells the agent what to do with the figure.

The person this article makes uncomfortable is the CDO whom the go-live committee will ask to confirm that the agent’s context is governed. For the outstanding balance, the answer takes one search, if that work has been done on key metrics. For the credit policy, the CDO will look for an owner, an official version, an effective date. On the document itself, there may be none.

Two answers already seem to cover this. The first is the tool already bought: extend the business glossary or ontology to documents, rely on the versioning of the document management system, or count on a more precise search engine. A glossary defines a term. Declaring that a text binds the company from a given date is a different act. A document management system numbers versions: the latest is the last one uploaded, which may be a draft. A more precise engine finds the right document faster, and the wrong one too. The second answer is the in-house process: the policy was approved in committee, then uploaded. The approval exists, in minutes the agent does not read.

This article is for CDOs and agent programme leads preparing 2027 go-lives. If your first agent still reads only data, the argument will apply the day it reads its first policy. In our AI Readiness series, the 28 October article measured readiness as a delay, the time it takes to settle in writing the rules behind one task; this one measures it as a gap, between what you have already done for your figures and what your policies still lack.

The exercise takes an hour: take the three policies your first agent will read and ask them the three questions you already ask of a metric. Details below.

Two November announcements: an official version for definitions, better search for files

The service announced on 3 November is Snowflake’s Business Ontology, with a public preview announced as “soon”¹. Its best form deserves to be described as the vendor writes it. A team defines a term such as “net revenue”, gives it a scope (finance), names an owner, gets it approved and links it to the view that calculates it. According to the vendor, only approved definitions are served to its agents. When an approved definition conflicts with something the system inferred on its own, the agent follows the approved definition.

This is the discipline of a data catalog, carried all the way to the agent. And the vendor itself writes, in its FAQ, that agents need approved references that tell them which definition to trust, which policies to follow and what corporate knowledge to incorporate. The product governs the first of those three. Applying the same standard to policies is our reading; Snowflake does not make it.

Two days later, on 5 November, Box announced Box Context Retrieval, generally available to its Enterprise Advanced customers early next year². Its announcement starts from the right observation: agent context comes from the files, “such as contracts, policies, customer history”. The engine promises more precise, permission-aware retrieval, extended to scanned documents, with new and updated content available to agents in real time.

These three promises answer three real questions: finding, respecting access rights, staying current. They leave open a fourth, which is not what the announcement is about: among the documents found, which one binds the company today? Real time makes it more pressing. Indexing delay, whatever it was, kept a draft out of reach for a while; that buffer is shrinking.

What the credit agent reads, and what changes when the policy is reliable

Back to the task. The customer credit agent receives an order. It reads the customer’s outstanding balance in the data warehouse and the credit policy in a document library. The policy says at what balance an order is held and who may release it.

On the figure side, if your data programme has done its work, the agent reads an approved definition: which balance (overdue, not yet due, net of credit insurance), who is accountable for it, since when. On the document side, the agent reads whichever file search ranked first. It knows its title, its upload date, perhaps its author. It knows neither its status, nor its effective date, nor who answers for it, unless those mentions are written on the document.

At the go-live committee, the head of credit asks: “The threshold the agent applies, where does it come from?” The CDO opens the catalog and shows the definition of the balance, its owner, its approval date. Then the CDO opens the policy, looking for an “in force” mention, an effective date, a named owner, and finds a file, an upload date, and nothing else to show.

What changes when the policy is made reliable comes down to three mentions written on the document: official version, owner, effective date. The agent can then cite a rule and its owner, the way it cites a figure and its owner. Its decision becomes defensible on both sides. And the work is done once per policy, not once per agent: the collections agent that reads the same policy in March inherits the three mentions. That is where the agentic transition speeds up. This gain has not been measured; you check it with the second agent, when the committee’s question finds its answer on the document rather than in a meeting.

What the field shows: 32% divergent duplicates in one base

In a CAC 40 industrial group, 32% of the base turned out to be divergent duplicates, surfaced in 2 weeks and resolved in 6. A divergent duplicate is a document that exists in several copies that no longer say the same thing.

What this measurement establishes: in a real corporate base, 32% of the content existed in divergent copies, and each of those cases called for a decision on which copy to keep. What it does not establish: the effect on an agent, which was not measured, the share of policies among those duplicates, or whether status mentions were present on the documents. It shows that the question of which copy to keep can concern a large part of a base, in one case. Not necessarily in yours.

The parity log: three policies, three questions, one hour

The exercise borrows from what the CDO already does for metrics.

What it produces. A parity log: a three-row table, one row per policy, with four columns. Official version (reference and version, as written on the document). Owner (a named role). Effective date (written on the document). Associated metric (the one the agent reads alongside, with its already known owner).

Where it lives. The agent’s source sheet, in the go-live file kept by the programme team. The log is three rows added to a document that already exists.

When it is written. When the agent’s list of sources is drawn up, before the go-live review.

The sample. The three policies that the agent’s task description cites or assumes. If the agent reads fewer than three, all of them. The list is built with the project team, from the agent’s instructions.

A completed row. “Customer credit policy, ref. FIN-CR-04, version 3 shown in the footer; owner: head of credit; effective date: not written; associated metric: overdue customer balance, owner: management control, approved definition.”

How to read it. All three mentions are written on the document: the agent may apply the policy within its granted scope. One mention is missing: the agent cites the policy and its date, and a human confirms before any action that relies on the rule. The policy owner writes the missing mention; it is a responsibility added to the existing role of process owner.

How it can fail. If the three mentions exist for all three policies, you will have spent an hour and gained something to show the committee. If they are missing, you will have found the gap before the agent did. The dated log remains a record that can be produced later: if an agent decision is challenged, it shows what was known at go-live. Writing it down is still better than not knowing; its legal weight is a matter for your legal department.

Its budget. The 2027 agent programme, under source preparation. No new budget line.

Audit, clean, monitor

The parity log covers three policies. The estate an agent programme opens may hold hundreds. That is the job of a distinct category, the Document Knowledge Platform (DKP): Govern, governing the document estate (ownership, authority, lifecycle); Clean, detecting and handling anomalies, duplicates, obsolescence and competing versions; Activate, opening the corpus to AI systems only once the first two steps hold. A DKP replaces neither a data catalog, nor a business ontology, nor a search engine, nor an agent platform. It runs before them, on the documents they consume.

Audit. Count, in the libraries the agent will read, the documents with no identifiable applicable version, the competing versions and the obsolete texts. To link a policy to an agent’s task, the tool proposes candidate documents; the team confirms. Only document content is read, within a contractually fixed ingestion scope approved by the business Document Owner and the CISO or DPO, without usage logs or conversations, and with no reuse for model training.

Clean. Route each case to the process owner, who decides. Business experts keep the decision.

Monitor. A revised policy changes version, owner or effective date. The log is updated at the same moment; otherwise the March agent will read the November version with November’s mentions.

Parity cannot be declared for the whole estate at once. It is earned policy by policy, starting with those the first agent will read. The CDO will then be able to answer the committee for the credit policy as for the outstanding balance.

Frequently Asked Questions

Our agents already have an approved business glossary. Doesn’t that cover policies?

A glossary defines what a term means. It does not declare that a document binds the company from a given date. Both are needed: the term “outstanding balance” must be defined, and the policy that sets the threshold must be designated as the official version.

Isn’t a better search engine enough to give the agent the right document?

It delivers the most relevant document for the question faster. If two versions of the policy are relevant, it serves one. Designating the official version remains a human decision, written on the document, which the engine then reads.

Who should write a policy’s official version and effective date?

Its owner, meaning the owner of the process it governs: the credit department for a credit policy, procurement for a purchasing policy. The agent programme team keeps the log; it does not decide the status.

What does the agent do until the mentions are written?

It cites the policy and its upload date, and a human confirms before any action that relies on the rule. This interim rule is lifted policy by policy, as the mentions are written.

Does a DKP platform read the content of our internal policies?

Yes, within a contractually fixed ingestion scope approved by the business Document Owner and the CISO or DPO. Only document content is read, without usage logs or conversations, and nothing is reused to train models.

Notes

¹ Snowflake, blog post “Business Ontology Governs Business Concepts and Metrics for AI and Analytics”, 3 November 2026: Business Ontology “(public preview soon)”; “Only approved definitions are served to AI agents”; agents need “approved references that tell them which definition to trust, which policies to follow and what corporate knowledge to incorporate”. Snowflake is listed among K-AI’s technology partners. ² Box, Business Wire press release of 5 November 2026, “Box Partners With NVIDIA to Deliver the Trusted Content Layer for Enterprise AI”: agent context from files “such as contracts, policies, customer history”; permission-aware retrieval; new and updated content available “in real time”; general availability for Enterprise Advanced “early next year”. The vendor’s quantified gains are not repeated here.

Sources

Where to Go From Here

K-AI Corpus Diagnostic — 10 business days on your document estate, full report of the 20 most critical anomalies, money-back guarantee if no meaningful anomaly is found. A one-hour conversation starts from your parity log: it locates the libraries where your policies have no written official version, owner or effective date, and clarifies where to start. Reach the K-AI team: contact@k-ai.ai. The scope of every diagnostic is validated jointly by the business Document Owner and the CISO/DPO, never by IT alone.

K-AI already works with CMA CGM, Veolia, PwC, BNP Paribas, TotalEnergies and CEVA Logistics. Partners: AWS, Snowflake, Microsoft, Wavestone, Devoteam.