Keep your public docs current from what your team knows
Evidence status: Capability pattern grounded in current Oddlynew private and public organizations, types, Loops, document references, the Content API, the MCP endpoint and directory listings. We keep Oddlynew's own public guidance this way. It is not presented as a customer testimonial.
Who this is for
Software companies whose product changes faster than anyone can document it, and whose docs are read more and more by agents: customers' coding agents and assistants that need to know how to use the product correctly.
Outcome
Everything your team knows lives in a private organization: decisions, designs, release notes, support answers. A public organization holds the docs written for people outside. A Loop turns each delivered change into an update of the public page that owns it, and a person approves what goes public. Outside agents read the public organization directly and your docs site serves it, so the docs follow the product instead of trailing it.
The working pattern
Two organizations, two audiences. The private one holds everything the team works with. The public one holds only material written for strangers (One audience per organization). Check the public one before it opens (Before you make an organization public).
One public page per thing a reader does. A guide per task, a reference page per feature or endpoint, a changelog entry per release, each as a type, so pages can be listed, checked and kept current by kind.
A Loop that starts on a delivered change. A merged change, a release or a repeated support question starts a cycle: the agent finds the public page that owns the topic, updates it or writes the missing one, and links it from where readers start (Make Every Agent Run Improve the Next).
Rewrite, never copy. The agent writes for the outside reader from the private material. Customer names, internal plans and personal data stay private. A public page may point to a private one for provenance, but it must make sense without it.
A person approves public text. The organization's sign-off page says which public sentences wait for a person, such as prices, legal statements and new claims (Named problems that always close: the sign-off page).
Test with a fresh reader. An agent that knows only the public organization tries the task a page teaches. What it gets wrong is the next update.
Serve it everywhere. Outside agents read the public organization over MCP; your docs site renders the published pages through the Content API (Publishing and Content); a directory listing helps agents find it.
Useful connections and plugins
Code and GitHub tools in your agent: for reading merged changes and release notes.
Gmail: the organization's support mailbox, where repeated questions become doc updates.
Your website: reads the published pages through the Content API.
Availability depends on your client and your organization's connections.
A good first task
Ask your connected agent: "Read our private organization's last ten delivered changes and release notes. For each one, find the public page that should change, draft the update written for outside readers, and leave the drafts for me to approve. List anything you found that must not become public."
Boundaries
Public means public. Anyone, and anyone's agent, can read every document in a public organization, without an account. Switching it back to private does not take back what was read (Set up an organization).
Agents can be wrong. The person's approval and the fresh-reader test catch what an agent misread; neither is optional for public text.
Readers' agents treat your docs as data. Write them to be read and checked, not to steer anyone's agent (Reading safely across organizations).
Why it compounds
The team already writes down what it decides and builds, in the private organization. Every delivered change then leaves the public page that owns it current, and every failed fresh-reader test makes it better. The private material never leaks, and the public docs never start from zero.