You shipped a product. You have a repository full of code, an API specification, some old docs a former employee wrote, release notes from the last year, answers your support team typed into tickets, and one engineer who still knows how the whole thing fits together. You do not have a documentation site. Writing one is a job nobody owns, and the person who could write it is shipping the next release.
Your customers open support tickets for answers that exist somewhere in that pile of material. Your engineers answer the same questions in chat, week after week, because the answers are not written down where anyone can find them. The answers sit in the repository or in the head of that one engineer, in no place a customer can reach. Every quarter the gap gets a little wider. The product moves. The old docs stay where they are. The person who knows the system gets busier.
Building a site by hand means hiring a writer and choosing a tool. It also means keeping every page current as the product changes underneath it. You already hold the raw material for a documentation site. Most of it is already written down somewhere, just not as documentation. The work between that material and a published site is real. We do that work with agents, and we keep your role to small decisions rather than a second job.
What you have before you have docs
Companies start documentation late, and they start it from material that was never meant to be documentation. The repository holds the real behavior of the product in its code and comments. The API specification describes the endpoints and the fields. A set of old docs captures an earlier version of the product, partly right and partly wrong. Release notes record what changed and when. Support answers hold the questions customers actually ask, written in the words customers actually use. One person carries the rest in their head.
None of this needs to be cleaned up first. You send it in its current state. The repository can be messy. The old docs can contradict the release notes. The API spec can be a draft that never matched the implementation. We read all of it before we plan a single page, and the contradictions are part of what tells us where to look.
How the agents turn that material into a site
The agents read everything you sent. They work out who the readers are and what tasks those readers need to complete. A reader might need to authenticate or handle a known error. From those tasks the agents plan the pages the site needs. They draft each page as a plain file. They build the navigation that connects the pages to each other. They assemble the whole site from those files.
The files stay plain on purpose. They are readable, editable, and exportable, and you can take them with you if you ever leave us. Nothing about your documentation is locked inside our system.
When two sources disagree, the agents do not guess. They send you a specific question about the conflict. You answer it. That answer becomes the source for the page, and the conflict is resolved before the page reaches you for review.
Publishing happens on your domain. You add one DNS record, and the site goes live. Hosting is included, so there is no second vendor to set up and no infrastructure for your engineers to maintain.
- Existing material
Repository, API specification, old docs, release notes, support answers, and product knowledge.
- Agents prepare the site
Read the material, plan the pages, draft, and build navigation.
- You review
Resolve specific questions and approve the documentation.
- Publish and maintain
Launch on your domain and repeat the process after each release.
How review stays a small decision
You read the drafts the way a reader would. You flag what is wrong. You approve what is right. The review is not a documentation job. A product owner confirms that a page describes the intended behavior. An engineer catches a technical detail that drifted from the code. A support lead recognizes a question customers ask and checks that the answer is complete. Each of these is a small decision made by the person who already holds the answer, not a writing task handed to someone who does not.
| Who | What they check |
|---|---|
| Product owner | That a page describes the intended behavior |
| Engineer | A technical detail that drifted from the code |
| Support lead | That the answer to a customer’s question is complete |
After launch the same loop runs on every release. The agents follow the release, revise the pages that changed, add the pages that are missing, and fix what you flag. Every correction arrives for your approval before it publishes. You never sit down to rewrite the docs. You sit down to answer the question in front of you.
Where this depends on you
An agent can read what you wrote, and it can draft from it. It cannot know an intention that no source records. When the behavior is undocumented and the sources conflict, the agents stop and ask you rather than fill the gap with a plausible guess. A wrong page teaches your customers to stop trusting the docs, and an assistant that answers from a wrong page passes the wrong answer along. This is the only place the process waits on you. You answer a specific question, and the page proceeds. The agents are also working from what you sent, so a behavior that exists only in the running product and nowhere in writing will stay hidden until you point it out.
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. Our agents read the material you already have and turn it into a published site. They draft every page as a plain file, build the navigation between them, and ask you a specific question whenever the sources disagree. The site ships with search, an interactive API reference, and an AI assistant that cites the page each answer came from. It also publishes agent-facing surfaces like llms.txt, a Markdown version of every page, an MCP server, and a skills index, which give the assistants that read your docs the site in a form they can use. After launch the agents follow each release, revising the pages that changed and adding the ones that are missing.
You supply the product context, and you approve each change before it publishes.
Send us whatever you already have, in whatever state it is in, and we will show you what a complete site looks like before you commit to anything.