You ship a release that changes how the product behaves, and the guides and examples written for the old behavior may now be outdated. A model can draft a page from the changelog, but with writing assistance alone you still have to identify which docs the change affects and initiate each future update.
What are self-driving docs
Self-driving docs are documentation that AI agents write, publish, and maintain as your product changes. You provide product context, direction, and approval.
Existing materials and the first site
Most software companies already have the raw material for documentation spread across several places. There is a code repository, an API specification, an older set of help pages, and release notes. There are internal notes a team has written for itself. There is the walkthrough an engineer gives when a new teammate joins. It is the context an agent needs to build a documentation site.
A SaturnDocs agent reads those sources. It proposes initial guides and a site that renders them. A person with product judgment reviews the proposal. The proposal may be missing a constraint the agent could not infer from the sources, or it may describe a behavior that is being deprecated. The customer corrects the proposal, the agent revises, and once the customer approves, the agent publishes the site. The initial writing, the part people picture, moves from raw product context to a reviewed site through the same preparation and approval that will govern every later update.
The authentication change as a worked example
Consider a change to how your API authenticates requests. This is a hypothetical example. The product moves from workspace API keys, sent in an X-API-Key request header, to scoped access tokens, sent in an Authorization: Bearer request header. A token is a credential the caller presents to prove access, and the header is the line of the request that carries it. In the example, the old API key continues to work through September 30.
The agent follows the release. It reads the current text on the pages a reader uses for this part of the product. The authentication overview, the token-creation guide, the API quickstart, and a migration guide are among them. Against each page it proposes revisions. The quickstart currently tells a reader to put the workspace API key in the X-API-Key header. The proposed revision shows the scoped access token in the Authorization: Bearer header. The migration guide records the September 30 date for old key support, which the product context supplies.
A reviewer reads the proposals and asks for a correction. The correction is an explicit instruction to test the integration using the new token before retiring the old API key. The agent revises the migration guide. The revised draft goes back for review, and once the customer approves it, the agent publishes it.
The same change then produces reader questions. A reader asks when the old API key stops working. The answer exists, because the migration guidance was published with the September 30 date. A documentation assistant, separate from the authoring agent that prepared the update, answers the question with a citation to the published page, so the reader can check the source for themselves. The question also becomes an input. A repeated question can expose guidance that is unclear. The agent proposes a revision to the page that clarifies the point readers raised. A person reviews and approves it before it publishes.
What the customer controls
The person with product judgment controls what the docs say and whether they publish. The division between agent preparation and customer approval holds for intended behavior, for missing context, and for the act of publication itself. When the product behavior is unclear or the sources conflict, the agent does not guess. It asks the customer, and the customer’s product judgment sets the answer. A guessed product behavior published as documentation would lead a reader to build against behavior that does not hold. Asking before publishing is how the platform keeps the docs accurate.
The published output reaches two kinds of reader. People get a searchable documentation site with guides and an interactive API reference. Agents get machine-readable access through the same content source the browser pages render, served through a Model Context Protocol server. The published documentation assistant provides answers that carry citations to the published pages, so a person can verify what it reports. An external agent accesses the same underlying content. One source feeds both readers, and later revisions to that source inform both.
The content stays in plain files the customer owns. The customer can read them, edit them, and export them.
What SaturnDocs does
SaturnDocs is the agent-first documentation platform for products that need to be found, trusted, recommended, and successfully used by AI agents. Self-driving maintenance is one part of that platform. SaturnDocs agents follow releases and changelogs, prepare proposed changes, and publish after you approve. They handle initial writing, ongoing maintenance, and corrections that come from customer feedback and reader questions. You provide product context and direction, and you approve every change before it publishes. If you have existing documentation or a repository, we can talk about the initial site and the updates that follow each release.