Documentation that keeps up with the product
Wilow has one document that says what the product does: a product knowledge base, one section per user-facing feature. Everything written about the product is supposed to start there. The rule inside the company is that a durable document never restates a volatile fact — a price, a tier, what a feature does — and points at the knowledge base instead.
A document like that is only true on the day someone writes it. The product kept shipping: between 4 June and 29 October 2026 the knowledge base was edited on dates spread right across the period. Keeping it true is not a writing job, it is a noticing job — knowing that a change nobody announced made the third paragraph of a section wrong — and the evidence for what shipped is scattered across the code, the tracker, the recorded meetings and the chat.
So the document had the usual fate. The parts nobody revisited went on describing a product that had moved, and the only way to find out which parts those were was to read everything that had happened since.
An agent that reads the sources in a fixed order, every night, and edits only the sections that changed. Each run goes through the same steps.
The whole knowledge base, in full, before anything else is read or written.
From the code itself, not from a summary of it. That is what decides whether a thing exists.
What each change was meant to do, which is not always what the code says it does.
Everything since the last run: recorded meetings, finished work sessions, the team channel. This is where the why lives.
A section nothing touched comes out of the run exactly as it went in.
Who the section is for, how the claim was verified, the date, and whether the feature is live.
Two sources that disagree are recorded as an open conflict in the section, not resolved by a guess.
The document goes to the team wiki, every edit goes in a dated changelog, and the run writes its own digest.
The sources are the approval. A change the rules cover, the agent writes up itself; anything that turns on a judgement nobody has made is written down as an open question instead.
The document still describes the product, and no person has to keep it up. Each night the agent reads what shipped that day, rewrites the sections that change made wrong, and publishes. There is a run record for every night from 11 October up to 30 October 2026, and a dated changelog entry for each night that actually changed something — a night when nothing shipped leaves the document alone and says so.
Yes, and this one does it each night on a live product. It reads the whole document first, then what shipped, then the tickets, meetings and messages behind it, rewrites only the sections that change made wrong, and publishes. There is a run record for every night from 11 October up to 30 October 2026.
From the code, first. What shipped is read out of the shipped log rather than out of a summary, and the tickets, recorded meetings and team chat are then read for what the change was meant to do and why. A closed ticket on its own is the weakest kind of evidence and licenses nothing.
Every claim carries how it was verified, and the tier decides what the claim may be used for. A new positive claim on a page that sells needs someone to have seen the working thing. Where two sources disagree, the section records the conflict instead of picking a side.
Only to answer the questions the agent writes down. It never deletes a section, never resolves a conflict on its own, and marks a removed feature as retired with the date, so what is left for a person is deciding the things only a person can decide.
This is the agent behind AI product documentation. The agent most businesses start with is the AI receptionist, and how we work and what it costs is on one plain page.
Tell us what you'd like us to build.
Free Consultation