Your support team has probably answered the same question five times this month, and nobody has written it up yet. Someone on the team fixes the issue, the customer says thanks, and the explanation sinks to the bottom of the inbox. A few weeks on, a different customer asks the identical thing, it gets fixed the identical way, and it sinks again. The answer has been worked out a dozen times. It has never been saved.

So we gave the job to an agent on Machine. Every week it goes through our resolved Plain tickets, looks for questions that recur but have no help article behind them, and writes up the most useful of those gaps based on how we really fixed them. Then it bundles the drafts into a single PR. That's where most of our new help-center content comes from now: the answers our support inbox already had.

The problem

The answers aren't missing. They're buried in hundreds of closed Plain conversations, and no one has the hours to dig them out. Picture a support lead trying to do it by hand. They have to keep track of what the help center already covers, judge whether a question is a pattern or a one-time oddity, and then sit down and write the article from a blank page. So the review hardly ever happens. When it finally does, the pile of undocumented repeat questions is so big that just choosing a starting point turns into a project.

Handing an AI writing tool a vague brief like "make some help articles" isn't the answer either. It doesn't know which topics you've already written up, and it has no idea how your team actually solves the problem. You end up with duplicates of articles you have, or bland text that doesn't match any real fix.

What we built

Once a week, a schedule on Machine wakes up the same long-lived session. That session is a cloud computer (a sandbox) that keeps its own ledger, a running record of past work, so it never starts from zero. On each run it pulls recently resolved Plain threads and sorts them into recurring topics. It checks every topic two ways: against the articles already in the KB repo, and against its own ledger of topics it has drafted before. The winners are questions that keep arriving in real numbers and still have no article. The agent writes each one up using the fixes from those actual tickets and opens one PR on the docs repo. A person has to merge it before anything goes live.

How it works

The pattern

Each week a cron wakes the same long-lived session, which checks its ledger of covered topics, groups closed Plain tickets it can only read, and opens one GitHub pull request of draft articles. It never publishes, and it never merges its own work.

Guardrails

Going from old tickets to drafts carries no risk. Going from a draft to a live help article is a call the agent never gets to make. Every limit we set sits on that boundary:

• Isolation. Each run picks up inside its own sandbox. The session can reach Plain and the KB repo and nothing else, and the pull request is the only thing it sends out.
• Scoped secrets. The Plain key and the GitHub token are stored encrypted in the Secrets Manager and only handed to the agents you grant them to, when the run begins.
• Draft-only. The agent opens a PR from a separate branch and then it's done. The live docs branch is never pushed to, and its own PR is never merged by it. A person reviews and publishes.
• Read-only tickets. Its Plain access can only read. While it digs through tickets for article material, it can't edit, close or answer any of them.
• Everything is code. How it groups tickets, how it writes drafts and what each system lets it do are files in the repo. They're versioned, and any change goes through a reviewed change request, not a switch on a settings page.

The outcome

All those "we answer this constantly but it's not in the docs" questions now turn up as one short PR a week, and every draft can be traced to the actual tickets behind it. The agent's part ends at grouping and drafting. What goes live on the help center is still the support team's decision.