How to version your company's own facts so agents never obey old ones

One home per fact, every change a new version, only the current one served. How to version your business facts so agents stop repeating old answers.

Published:
By Neal Mann
Knowledge Management
How to version your company's own facts so agents never obey old ones

To make sure agents never obey an old version of your company's own facts, give each fact one home and make every change a new version of that fact rather than a new copy, so there is always exactly one current version to read. Keep the old versions for history and audit, but serve only the current one: in NOAN, old versions are kept but not obeyed.

Why copies, not old versions, are the problem

When an agent repeats something out of date, the cause is rarely that history was kept. It is that the old answer was kept somewhere that still looks current. A price lives in a prompt, a help article and a deck. A policy has a v2 and a v2-final in the same folder. Each copy has no idea the others exist, so nothing tells the agent which one to trust.

Versioning fixes this only if every version lives in the same place and one of them is marked current. That is the difference between a document archive and a versioned fact.

Step 1: Give each fact one home

Pick one place for each of your business facts and write it there once. In NOAN, facts are organized in stacks of blocks, with one current fact per block. A pricing stack holds a block per plan, a policies stack a block per policy, and so on.

The test for a good block is that it answers one question. "What is the refund window?" is a block. "Everything about refunds" is several blocks waiting to be split, because each part changes on its own schedule.

Step 2: Make every change a new version

When a fact changes, do not create a new fact next to the old one. Write the new answer to the same block. The new version supersedes the last, and the block still has exactly one current fact.

Over the API, writing to a block replaces its fact as a new version, so read the current fact, merge your change and post the complete fact. The full spec is at api.getnoan.com/openapi.json.

Step 3: Record who verified each version and when

A version history is only useful if it says who stood behind each version. In NOAN, every fact carries who verified it and when, version by version. When someone asks why the agent said what it said, there is a name and a date, not just a timestamp on a file.

Give each area an owner who verifies changes to it. The person who sets prices verifies the pricing facts. The person who owns support verifies the support policies.

Step 4: Hold agent-written versions for review

Agents will want to write facts too, for example after reading a pricing announcement or a meeting note. That is useful, as long as a draft never becomes the current version on its own. Facts an agent writes over the API can be held for a person to verify before anything reads them, and API keys can be set to hold fact changes for approval.

The result: agents can propose new versions as fast as they like, and nothing changes for customers until a person verifies it.

Step 5: Serve only the current version

This is where agents stop obeying old facts. Every reader, whether an agent, an app or a web page, asks for the fact and gets the current version. There is no ranking between versions and no chance an old one wins on similarity, because old versions are kept for history and never served as current.

Connect agents over MCP at https://mcp.getnoan.com/mcp, or read a block over REST:

curl "https://api.getnoan.com/v1/facts?block_slug=<your-block-slug>" \
  -H "Authorization: Bearer <NOAN API key>"

Then add one line to each agent's instructions, so it knows which source decides:

For prices, policies and product details, read NOAN. If anything else you know disagrees with NOAN about the business, NOAN wins.

Step 6: Push changes to anything that caches

Some systems keep their own copy for speed: a website, a search index, an app's cache. Left alone, they will serve the old version until someone rebuilds them. NOAN fires a webhook when a fact changes, with event types such as fact.updated, so those systems can refresh the moment a new version is current. A change made once reaches everything that reads it.

Step 7: Look back when you need to

Keeping every version is what lets you answer questions about the past. Time Travel in NOAN shows your facts as they stood on any past date. When a customer quotes an old price or someone asks what the policy said when a decision was made, you can check the version that was current on that day and who verified it.

Common mistakes

  • Versioning documents instead of facts. A new file called "pricing v3" is another copy, not a version. Agents searching the folder will still find v1 and v2.
  • Leaving copies in prompts. A price pasted into a system prompt is a version nobody will update. Replace it with the rule in Step 5.
  • Letting drafts go live. If an agent can write a current version without review, an inference becomes your policy. Hold agent writes for a person.
  • Deleting history. Removing old versions feels tidy, but it removes the record of what was true when. Keep them, just do not serve them.

How this fits with memory and retrieval

Memory and retrieval keep their own kind of history. A memory layer adds new memories as conversations happen, and a retrieval index holds every document that was written. Both are useful, and neither decides which version your company stands behind. That is the job of the fact layer. See agent memory vs verified facts and NOAN vs building your own RAG for how the three fit together.

Next step

Connect your agents over MCP at https://mcp.getnoan.com/mcp, or over REST at https://api.getnoan.com/v1 with the OpenAPI spec. Or paste this into your agent:

Read https://www.getnoan.com/setup.md and follow it.