We wire agents into your repo, your spec, your releases and your support queue. When something changes, the pages it affects get flagged and drafted — a writer approves, and it ships. Works on docs we wrote, or docs you already have.
Nobody ships broken documentation on purpose. It happens one release at a time — a renamed field here, a redesigned screen there — until the whole thing quietly stops matching the product. The fix isn't discipline. It's having something that watches.
It's in the ticket. It'll get done after the release. It won't. Not because your team is careless, but because nothing in the process forces it.
The first signal that a page is wrong is usually a support ticket, or a developer who gave up. By then it's been wrong for weeks.
Assistants read your pages and repeat them. An out-of-date parameter doesn't just sit there any more — it gets pasted into your user's editor.
Every docs project is fine on launch day. The question is what it looks like after eight releases.
Each one watches a different source and produces the same thing: a specific page, flagged, with a draft attached and a person to approve it. Take all six or start with one.
We diff your OpenAPI spec on every release. A new field, a changed type, a removed endpoint — we know which reference pages it breaks, and the parameter tables and examples get redrafted.
When the UI moves, guides stop matching. We watch merged PRs and releases for changes that touch a documented flow, then flag the steps and screenshots that no longer describe reality.
Every release becomes a changelog entry drafted from the actual commits and PR titles — rewritten into something a customer can read, not a dump of merge messages. Deprecations get a migration note.
An agent reads incoming tickets and asks one question: is this a docs gap? If the same thing arrives three times with no page covering it, you get the theme, the evidence, and a draft article built from how your agents already answer it.
Every published snippet becomes an executable test against your sandbox. When one stops working, your build fails — so a broken example is caught by CI rather than by a developer who assumed your API was down.
A search and answer layer that cites your real documentation instead of guessing, in your product and your help widget. Plus llms.txt and clean structure, so external assistants quote you correctly too.
Automation that publishes unattended is how you end up with confident, well-formatted, wrong documentation at scale. So every loop stops at the same place: a draft, waiting for a person. The agents remove the chore of noticing and drafting. A writer keeps the judgement.
Before automating anything, we check what's currently wrong. You get a list of pages that no longer match your product — which is usually more than anyone expects.
Read access to the sources that tell us something changed: your repo, your spec, your release process, your ticket queue. Nothing writes anywhere yet.
The hard part isn't detecting a change, it's knowing which pages care. We map your documentation to the code, endpoints and flows behind it, then tune the thresholds so you get signal instead of noise.
Drafts arrive as pull requests in your repo, routed to whoever should see them. You decide whether that's your team, ours on retainer, or a split by section.
Live from the next release onward, with a weekly digest of what was caught, drafted and shipped — so the value is visible rather than assumed.
A field gets renamed and the reference stays wrong until someone complains.
The page is flagged and redrafted the day the PR merges.
The changelog is three releases behind, so nobody reads it.
Every release ships with an entry a customer can actually read.
The same ticket arrives for months before anyone writes the article.
It's flagged at the third ticket, with a draft already written.
Keeping docs current means someone remembering to.
It means someone approving a PR that's already waiting.
Updates them. This service keeps existing documentation current — it assumes there's already something worth maintaining. If the docs don't exist yet, start with one of our writing services and we'll wire the automation in at handover.
No. Every loop stops at a draft. Changes arrive as pull requests in your repo and a person approves them — yours or ours, whichever you prefer. Automation that publishes unattended is how you get confident, well-formatted, wrong documentation at scale.
No. This works on whatever you already have. We start with an audit of what's drifted, map your pages to the code and flows behind them, and go from there. Plenty of clients come to us with docs they wrote themselves and just want them to stop rotting.
Read access to the sources that signal a change — repo, spec, releases, and your helpdesk if support automation is in scope — plus a sandbox key if you want samples tested in CI. Write access is limited to opening pull requests against your docs.
That's the tuning stage, and it's the part that actually takes skill. Detecting a change is easy; knowing which pages care is not. We map documentation to the code and flows behind it, set thresholds per source, and agree what to ignore before anything goes live. An alert nobody acts on is worse than no alert.
Yes, and most teams should. Pick whichever loop maps to the thing breaking most often — usually the spec diff for API-first companies, or the ticket loop if support is the pain. Add the rest once you trust the first one.
Show us your docs and your repo. We'll tell you what's already drifted and which loop is worth wiring first.