To give your AI agent verified answers about your company, put your business facts in one fact layer where a named person verifies each one, then connect the agent to it over MCP or REST and tell it to answer from there. The agent stops piecing answers together from old documents and chat history, and every answer traces back to a fact, a version and the person who verified it.
Why agents get your business wrong
Most agents learn about a company in three ways, and none of them was built to be a source of truth. Prices and policies get pasted into a system prompt, where they stay long after they change. A retrieval pipeline searches your documents and returns whatever matches, including last year's deck. A memory layer recalls what someone said in a past conversation, which is useful context and a poor authority.
The result is an agent that sounds sure of itself and is right most of the time. For the answers that matter, like what something costs, what the refund policy says or what the product does today, most of the time is not good enough. The fix is not a better prompt. It is giving the agent one place where your company's own facts live, each one verified, and teaching it to read from that place first.
Step 1: List the questions your agent must get right
Start with the questions, not the documents. Pull up your support inbox, your sales calls and your agent's own logs, and write down the questions where a wrong answer costs you something. A typical first list covers:
- Prices, plans and what each plan includes
- Refund, cancellation and support policies
- What the product does and does not do today
- Who you serve and who you do not
- Contact routes and hours
Twenty to fifty questions is a good first pass. You are building the spine your agent stands on, not an archive of everything you know.
Step 2: Write each answer as one fact
For each question, write the answer as a short, plain statement that a person could read aloud. One question, one fact. "Refunds are available within 30 days of purchase" is a fact. A twelve-page policy PDF is a document that contains several facts, some of them out of date.
In NOAN, facts are organized in stacks of blocks, with one current fact per block. A pricing stack might hold one block per plan, and a policies stack one block per policy. Keeping one fact per block is what lets the agent ask for exactly the answer it needs and get exactly one back.
Step 3: Have a named person verify each fact
A fact is only as good as the person who stands behind it. Give each area an owner: whoever sets prices verifies the pricing facts, whoever owns support verifies the support policies. In NOAN, every fact carries who verified it and when, so when someone asks where an answer came from, there is a name and a date to point to.
If agents will propose facts too, decide that now. Facts an agent writes over the API can be held for a person to verify before anything reads them. That lets an agent draft the first version of your fact layer from what it finds, while nothing it drafts reaches a customer until someone has checked it.
Step 4: Connect the agent
NOAN serves your facts over a remote MCP server and a REST API, so the agent can reach them however it runs.
- MCP: point any MCP client at
https://mcp.getnoan.com/mcp. It signs in over OAuth, or sends a NOAN API key as a bearer token. The MCP page has the steps for Claude, ChatGPT and Cursor. - REST: call
https://api.getnoan.com/v1with a bearer key. One GET returns the facts in a block as plain JSON:
curl "https://api.getnoan.com/v1/facts?block_slug=<your-block-slug>" \
-H "Authorization: Bearer <NOAN API key>"
The full spec is at api.getnoan.com/openapi.json, and the API page walks through the surface.
Give the agent its own key with only the access it needs. API keys are scoped per resource, read or write, and can be limited to a list of allowed stacks, so a support agent can read your policies without being able to change them.
Step 5: Tell the agent where the truth lives
Connecting the agent gives it the facts. You still have to tell it to use them. Add a short rule to its instructions, along these lines:
Before you state a price, a policy or a product detail, read it from NOAN. If NOAN has no fact for it, say you are not sure and offer to find out. If anything else you know disagrees with NOAN about the business, NOAN wins.
The last sentence matters most. Your agent will still have memory, retrieved documents and its own training. The rule makes clear which source decides when they disagree.
Step 6: Keep it current
A fact layer earns its keep the day something changes. When a price moves, the owner writes the new fact, verifies it, and it becomes the current version. The old version is kept for history but no longer obeyed, and the change reaches everything that reads it at once: every agent, app and page on the same API.
If you have systems that cache facts, such as a website or a search index, NOAN can fire a webhook when a fact changes, so they refresh instead of waiting for someone to notice.
Check it before customers do
Before you turn the agent loose, ask it every question on your Step 1 list and compare its answers with the facts. Then change one fact and ask again. If the agent gives the new answer straight away, the setup works. If it gives the old one, find where the old answer still lives, usually a prompt or a document, and remove it.
For a deeper look at why memory and retrieval cannot do this job on their own, see agent memory vs verified facts and NOAN vs building your own RAG.
Next step
Connect your agent over MCP at https://mcp.getnoan.com/mcp, or over REST at https://api.getnoan.com/v1 using the OpenAPI spec. Or paste this into your agent and let it walk you through setup:
Read https://www.getnoan.com/setup.md and follow it.