Your knowledge base should write itself.

Last Tuesday somebody on your team wrote a good answer. Three sentences, ten minutes to get right, delivered to exactly one person. It is still sitting in that thread. Next month the same question arrives from someone else, and whoever picks it up will either go digging for that thread or write the answer again from scratch. Most support teams pay for the same answer four or five times before anyone thinks to write it down.

Why does the same question keep arriving?

Because the answer was delivered, not recorded. A support reply is addressed to one person and filed in one conversation, so the knowledge inside it never becomes searchable for the next person who needs it. Every repeat after the first is a documentation gap being paid for in staff time, one thread at a time.

The reason nobody fixes it is that writing it down is a separate act of work, done at the worst possible moment. The thread is closed, the customer is happy, the next one is waiting. Documentation loses that competition every single day, and it loses it to something entirely reasonable.

Can AI turn support tickets into knowledge base articles?

Yes, and three vendors do it in production. Zendesk's Knowledge Builder groups historical tickets into intents and drafts an article for each high-volume one. Intercom surfaces content recommendations from conversations Fin had to escalate. Munin files one candidate per resolved handover into an admin-only inbox. All three keep a human between the draft and the customer, which is the only part that isn't optional.

What Munin does the moment a human answers

The trigger is precise, and it matters that it is. When a self-service agent can't answer from the knowledge base, it calls conv_request_handover — it stops and asks for a person rather than generating something plausible. A human answers. The handover clears, and handoverResolvedAt is stamped on the conversation.

That stamp is the signal. It marks the exact set of conversations where a question outran the knowledge base and a person closed the gap by hand — which is precisely the population a knowledge base article should be written from. Not all tickets. Not the popular ones. The ones that proved the documentation was missing.

Munin runs the curation pass in two modes off that signal. A sidecar fires on every conversation.handover_resolved event, so the candidate exists within seconds of the reply going out. A weekly batch sweep re-reads the last seven days as a safety net, in case the sidecar was down. Both run the same five steps.

• 01Check what was already judged. kb_list_curation_decisions returns one row per past decision, with the dismissal reason. Those source conversations are dropped before drafting starts — an operator's no doesn't expire.
• 02Find the gaps. conv_list_conversations with handover: "resolved" and a since window. The server applies the filter, so the rows that come back are already the eligible set.
• 03Read the pair. conv_get_conversation returns the full messages[] array. The end-user question, the agent's handover, then the last cluster of human replies — that cluster is the canonical answer.
• 04Check it isn't already covered. kb_search on the question's gist. If a document scoped to the self_service audience already answers it, the gap was discoverability, not coverage, and no candidate gets filed.
• 05File the draft. kb_propose_curation_candidate writes a 100–300 word FAQ-shaped draft into the kb-curation-inbox space, tagged curation and candidate, audience admin only.

{
  "name": "kb_propose_curation_candidate",
  "arguments": {
    "subject": "Weekend opening hours",
    "draftBody": "We're open **10–16 on Saturdays** and 12–16 on Sundays. The downtown branch keeps weekday hours every day.",
    "sourceConversationId": "ccv_…",
    "proposedTargetSpaceSlug": "support-faq"
  }
}

Why doesn't the draft go straight to customers?

Because an audience is a field, not a hope. The candidate is created with audience admin, in a space end-user agents cannot read. Your customers keep getting handed to a human for that question until somebody promotes the draft — which is the correct failure mode, because the alternative is publishing an unread LLM draft to the people paying you.

Promotion is kb_publish_curation_candidate: it moves the document into the target space, drops the candidate tags, and sets the audiences — defaulting to ['admin', 'self_service'] so the self-service agent finds it next time. Rejection is kb_dismiss_curation_candidate with a reason, which deletes the draft and records the decision so no later pass can quietly refile the same conversation.

What does the pass refuse to write down?

Four things, and the discipline is most of the value. A knowledge base fills with noise faster than it fills with knowledge, and once it does, every agent reading from it gets worse.

One-word answers. "Yes." "Sure." There is no article in there.

Customer-specific state. Your account is locked because we flagged a chargeback last week is true about one person and belongs nowhere near a document your whole customer base can search. Names, emails, account numbers and internal ticket references get stripped at drafting time.

Anything already covered. That's step 04. A duplicate document is worse than no document, because hybrid retrieval — full text plus embeddings — now has two candidates to disagree about.

Operational status. "We're down for maintenance until 3pm" is a status page, not knowledge.

One more, at the boundary: if both halves of the pair came from agents — the self-service agent and an admin agent talking to each other — nothing gets filed. No human confirmed that answer, so there is nothing to promote.

How is this different from Zendesk Knowledge Builder or Intercom's recommendations?

The three products solve the same problem from three different ends, and the differences are real rather than marketing.

• Zendesk Knowledge BuilderBackfill at volume. It reads historical tickets, groups them into intents, and drafts an article for each high-volume one, so a help centre can exist where there wasn't one. Generally available to customers with the Knowledge product; the generative editing features in Knowledge require the Advanced AI add-on. AI agent usage is billed per automated resolution, funded by a resolution allowance, with the rate quoted by sales rather than published.
• Intercom content recommendationsGap detection on what you already publish. Fin surfaces suggested new articles and snippets from conversations it had to escalate, and flags duplicates and contradictions in existing content. Intercom suggests a weekly review pass. Fin itself is billed at $0.99 per resolution on top of at least one seat.
• Munin curation passEvent-shaped, one conversation at a time. A resolved handover produces one candidate within seconds, in an admin-only space, drafted by whichever model you point at the tools. The procedure is markdown you can read and edit before you trust it, and the whole platform is MIT-licensed.

Which one should you use?

If you already run Zendesk and you are sitting on two years of tickets you would like turned into a help centre by Friday, use Knowledge Builder. Bulk historical backfill grouped by intent volume is exactly the job it was built for, and Munin's pass is shaped differently: it is event-driven, one resolved handover at a time, and it starts producing from the day you switch it on rather than from your archive. If your team wants a decade-deep editorial and reporting suite around knowledge, Zendesk and Intercom both have one.

Pick Munin when the constraint is somewhere else — and for a lot of teams it is.

The answer and the customer record are in the same database. A curated document, the conversation it came from, and the contact who asked all live in one Postgres schema with one contacts table, so the pass reads a thread and writes a document without an integration in between. Nothing syncs, because nothing is apart.

The pass runs wherever you already work. It is MCP tools and a markdown procedure, not a feature inside a UI you have to log into — so it runs from Claude Code, Cursor, ChatGPT, the OpenAI Agents SDK, or a runner you wrote yourself, against the same 204 tools and the same audit log. Same catalogue, whoever is calling.

You can read the procedure before you trust it. The curation skill is one of 47 bundled markdown skills. It tells the agent what to skip, how long a draft should be, and that it must never auto-promote. When it's wrong for your team, you edit the markdown and the behaviour changes on the next run — no ticket, no roadmap.

And the pricing meter isn't attached to the outcome. Munin Cloud Free is €0 a month with 5,000 MCP calls, 250 contacts, and 100 MB of storage — enough to run this pass on a real desk. Self-hosting is docker compose up under an MIT licence with no enterprise/ directory holding the useful half. The AI cost is what your model provider charges you, not a per-resolution fee to us. That is the same argument I made about per-seat and per-resolution meters generally, applied to the one feature where the meter would bite hardest.

What does it look like after a month?

A short queue and a knowledge base that grew without anyone scheduling time to write it. Ten or twelve candidates a month is normal for a small desk. Most are two paragraphs, most are right, and working through them takes a coffee's worth of attention: read, tighten a sentence, promote or dismiss with a reason.

The thing you actually notice is second-order. Handover volume on the questions you have already answered once starts falling, because the self-service agent can now cite a document instead of fetching a human. The pass is, in effect, a feedback loop that pays down the exact debt it discovers — and it is the same shape as keeping the CRM current from conversations you were already having. Read the thread you already have. Write the record nobody had time for. Stop before the irreversible bit and ask.

What is left on your desk is the judgment: is this general enough to publish, is it phrased the way a customer would search for it, does it contradict something we already say.

Frequently asked questions

Can AI write knowledge base articles from my support tickets? Yes. Munin drafts one FAQ-style document per resolved handover — a question the agent couldn't answer and a human then answered — and files it for review. Zendesk's Knowledge Builder does the same job in bulk from ticket history, and Intercom recommends content from conversations Fin escalated. In all three, a person publishes.

Will an AI-written help article go live without anyone reading it? No. In Munin the candidate is created with audience admin in a space end-user agents cannot read, and only kb_publish_curation_candidate moves it into a customer-facing space with self_service audience. There is no confidence threshold that skips the human.

What happens if someone edits the draft while it's waiting for review? The publish refuses. kb_publish_curation_candidate takes ifVersion — the version the reviewer read — and fails with kb_version_conflict if the text moved, so nothing reaches customers that a person didn't approve in its current form.

Can I import the help centre I already have? Yes. kb_import bulk-loads existing articles from CSV or JSON, and there are skills for chunking long documents so hybrid retrieval performs well. Curation then adds to that base from live conversations rather than starting from zero.

Which AI model does the drafting? Any of them. The pass is a markdown procedure plus MCP tools, so it runs on Claude, ChatGPT, Gemini, Codex, or a model you host yourself — and the model you choose is a config line, not a migration.

What does it cost to run? Munin Cloud Free is €0 per month and includes 5,000 MCP calls, which covers a small desk's curation comfortably. Self-hosting under MIT is free of licence cost. Your only variable expense is what your model provider charges for the drafting.

The curation procedure is markdown you can read before you trust it — it's in the docs, and Munin Cloud is free to run a pass on.

An answer that lives in one thread isn't knowledge. It's a favour you did once.