Every price change is a release: a checklist for keeping your AI agent right

A feature isn’t finished until the support agent can answer questions about it. The same goes for everything smaller: the new delivery fee, the third branch, the Christmas cut-off, the product you stopped stocking. Each one is a release, because a customer will ask about it within the day, and the agent will answer from whatever your documentation said last.

For a grounded agent this cuts both ways. Anchorcan’t invent a price it hasn’t read, which is the point of it — but it will quote the old price for as long as the old price is the one in your content, and it will quote it with a source attached. A stale document is the one way a grounded agent gives a wrong answer. So the job isn’t to make the agent smarter. It’s to make updating the content part of making the change.

Make agent readiness part of the change, not a follow-up

The failure is familiar: the new fee is decided on Monday, the website is updated on Wednesday, someone remembers the help center the following week, and in between the agent has answered forty delivery questions with the old number. Nobody lied. The process just had the documentation last.

Move it first. When a change is agreed, the question “what will the agent say about this?” gets asked in the same conversation, and the answer is a document — drafted before the change goes live, published the hour it does. In a small team that’s one person’s habit, not a process document. It’s still the whole game.

Step 1: Write the new fact the way a customer asks it

The agent answers from your words, so write the words a customer will need. Three rules cover most of it.

• Be literal.“Delivery to Kumasi is GHS 25 and takes 2–3 working days” beats “our delivery network now covers the Ashanti Region”. The agent can’t infer what you meant. It can only quote what you wrote.
• One fact per document where you can.A snippet called “Delivery zones and fees” that lists every zone is easier to keep right than a fee buried in a paragraph about packaging.
• Name the change from the customer’s side.Nobody asks “has the fulfilment policy been updated?” They ask “why is delivery more than last time?” A sentence that answers that — “Delivery fees changed on 1 October” — saves a handoff.

In Anchor, a hand-written document is a snippet: Knowledge → New document, a markdown editor, and a Draft/Published switch. Write it as a draft while the change is being decided. Drafts aren’t live to the agent, so nothing leaks early.

Step 2: Retire what the new fact contradicts

A new document doesn’t cancel an old one. If the help center still says GHS 15 on one page and your new snippet says GHS 25, the agent has two sources and you’ve handed it a coin to flip. Before you publish, look for the old value in your knowledge base — the number, the zone name, the product — and deal with every hit.

• Same fact, older page:update it or delete it. Don’t leave it “for reference”.
• A website page you edit outside the dashboard: change the page, then use Re-crawl on that source so the index catches up. The document shows Pending until it does, then Indexed.
• Two documents that disagree in tone but not fact: pick one to be canonical and retire the other. Duplicates are the quiet cause of inconsistent answers.

Categories help here. A “Delivery” category with six documents in it is a place to look. The same six documents scattered across a hundred is an archaeology project.

Step 3: Test it before a customer does

Publish, then ask. The Playground’s Live chat tab is the agent exactly as a customer gets it. Ask the question three ways — “how much is delivery to Kumasi”, “do you deliver to Kumasi”, “Kumasi delivery fee” — and check that the answer is the new number and the source is the new document.

Then save the question. The Tests tab keeps a question with the answer you expect, and the Runs tab re-checks the saved tests. That’s the difference between a change you verified once and a change that stays verified: the next time anyone touches the delivery documents, the old tests run again and the regression shows up in a list instead of in a customer’s chat.

Set the after-launch check before you leave. Give it a week, then open Analytics → Worklists → Failure modes and look for “Wrong or outdated answer” and “Missing knowledge” against the phrasing customers actually used. If the change landed cleanly, the new topic isn’t there.

Put the calendar changes on the calendar

Half of what changes in a small business changes on a schedule: public holidays, seasonal pricing, the delivery cut-off before Christmas, the January stock clear-out. Those don’t need to be discovered. Put the documentation step on the same calendar entry as the change itself — “publish the holiday hours snippet; retire last year’s” — and the agent is ready before the first customer asks.

The checklist

1. Decide the change and, in the same conversation, decide what the agent will say.
2. Draft the new document in the customer’s words, one fact per document, dated.
3. Find the old value; update, retire, or re-crawl every hit.
4. Publish, then ask the question three ways in the Playground.
5. Save it as a test so it re-runs on every future change.
6. A week later, check Failure modes for the new topic.

Where Anchor fits

Every surface above ships today: snippets with a Draft/Published switch, Re-crawl on website sources, Pending/Indexed status per document, categories, and a Playground with Live chat, Tests, Runs, and a Coverage tab that lists the questions the agent couldn’t answer from a cited document. Start with your next change. The free trial (30 days, 300 credits, no card) is long enough to run this routine on it twice.

Common questions