You ship software every week, and people have questions about it. Developers are integrating your API. Support engineers are closing tickets. AI assistants are reading your documentation on a customer’s behalf and answering questions from it. A docs assistant can serve all of them at once. It can also hand back a confident sentence that is wrong. A wrong answer to an integration question costs a developer an afternoon and costs you a support ticket. What separates a useful answer from a wrong one is the source the assistant is allowed to read from.
An assistant earns trust when it answers only from the pages you published and shows the page for each answer. Readers can check the source. When the pages lack an answer, the assistant says so instead of guessing, and that gap becomes work that fills in.
Why the source boundary matters
An assistant that draws on general knowledge will answer questions about your product using facts from other products or from older versions of your own. Configuration fields change between releases. Auth steps change. A sentence that was correct last release may be wrong this release. General knowledge cannot track that, because it has no link back to your current pages.
We set a source boundary. The assistant answers from the published pages only. It does not consult its training data for product facts. If a detail changes on the page, the assistant follows the page on the next question. A reader can predict what kind of answer they will get, because the answer comes from a fixed, reviewable set of documents.
The boundary is what makes the citation meaningful. Each answer lists the pages it used, with links. The reader can open them. The citation is the evidence that the answer came from the published docs, and it is the path back to the full context around the answer.
How the boundary and citations work
Here is an exchange with the assistant on the docs site.
Request: How do I rotate an API key?
Response:
Create a replacement key and configure your application to use it. Once the
application is running on the new key, revoke the old key.
Citations:
- Rotate an API key: /security/rotate-api-key/
- Revoke an API key: /security/revoke-api-key/
Two pages supported the answer. The reader can open either link and read the prerequisites, the warnings, and the exceptions that did not fit in a short reply.
Answers often span more than one page. A setup guide plus an API reference entry can combine into one answer. Both pages appear in the citations. The reader sees that the assistant pulled from a guide and from a reference, and can read either one.
The citation is what makes the answer checkable. If a reader doubts a step, they follow the link and read the page. The page is the durable answer. It has room for everything the short reply left out, and it has a stable address that people and agents can cite later. The page can carry prerequisites that a short reply omits, and those prerequisites are often what makes an answer safe to act on.
When the docs do not have the answer
Ask the assistant something the published pages do not cover. The assistant says the published documentation does not cover the question. It gives no citations. It does not guess.
That refusal is the boundary doing its job. A reader learns that a “no” from the assistant means the docs are missing something, not that the assistant is unreliable on this topic. The no is consistent and predictable across questions.
The unanswered question becomes work. The agents draft the missing page. When they need context they cannot infer from the existing docs, they ask the customer for it. The customer reviews the draft. On approval, the page publishes. The next time someone asks, the assistant answers from the new page and cites it.
- A reader asks
The assistant looks in the published documentation.
- An answer exists
Return an answer with citations to its source pages.
- An answer is missing
Explain the gap. The agents draft a page for your approval.
- The next answer
After approval, the assistant can cite the published page.
A gap closes because it was visible. General-knowledge assistants hide gaps by filling them with plausible text. A bounded assistant makes a gap legible, and a legible gap is something you can decide to fix.
The limits of a bounded assistant
A bounded assistant will not synthesize a novel answer from first principles. If a reader needs a conceptual explanation that no page provides, the assistant will say the docs do not cover it until someone writes that page. That is slower than an assistant that improvises, and it puts more demand on the people who maintain the docs.
The boundary also depends on the pages being current. If a release ships and the docs lag behind it, the assistant will answer from stale pages with full confidence, because the pages are its whole world. This is why the agents update the docs after every product release. The boundary is only as good as the pages behind it, and keeping those pages current is the work the platform is built around.
What SaturnDocs does
SaturnDocs is a documentation platform built for the AI agents that now read your docs, and for the people who still do. The agents write, publish, and maintain the documentation site. They run an assistant that answers from the published pages and cites them, and when a question has no answer in the docs, they draft the missing page and ask for your context where they need it. Every site includes search, an interactive API reference, the assistant, hosting, and agent-facing surfaces such as llms.txt and an MCP server. The agents update the docs after every product release. You supply product context and approve each change before it publishes.
Send us a question your readers ask, and we will show you the page the assistant would cite for it.