Where do resolution writeups come from?

Your existing practice, lightly formalized: when a notable ticket closes, the resolution summary gets committed as a markdown file. Teams using ticket-system exports automate that drop. The workflow takes it from there.

Can it update an existing article instead of writing a new one?

Yes — point the draft prompt at the existing article in the corpus and the new resolution; the output is a revised article that goes through the same review and approval.

AI Workflows for Knowledge Base Articles

Name: Fleet
Author: Fleet

Every support team has the same backlog: the top twenty tickets of the month have been answered brilliantly — in twenty private threads. The knowledge base that should deflect them gets written 'when things calm down,' which is never. Meanwhile new agents re-derive known answers and customers wait in queue for solved problems.

When KB articles do get written, they're written from memory of the resolution, not the resolution itself — losing the exact error messages and steps that make an article findable and usable.

How it works with an agent fleet

A Fleet workflow drafts KB articles directly from resolved-ticket writeups, reviews them for accuracy and findability, and publishes each one after a support lead's approval.

Step	Kind	What it does
`article`	Document	Runs once per file in `support/resolutions/.md`. “Write a KB article from this resolution writeup: symptom (with exact error text), cause, fix steps. Title it the way a customer would search.” Reads `support/resolutions/.md`, `docs/product/*/.md`.
`accuracy`	Review	“Verify fix steps against current product docs; flag steps that changed since the resolution. Flag titles a customer wouldn't search for.”
`lead-ok`	Approval gate	Pauses the run for a human sign-off; records the approver, timestamp, and note.
`publish`	Publish	Shares the approved document at a link.

You build this once on the dashboard canvas; your self-hosted Fleet worker pulls the definition and runs it against your repository.

The fan-out drafts one article per resolution writeup; the accuracy review catches the classic trap of documenting last month's UI. The lead approves each article — published links exist only past the gate.

The fleet pattern

Resolution writeups → fan-out drafting → accuracy + findability review → support-lead approval → publish. The thread-to-article pipeline the team always meant to build, as configuration.

Guardrails that matter here

Accuracy review compares against current product docs, so articles ship describing the product as it is, not as it was during the ticket
Each article is individually gated — the support lead approves exactly what customers will read
Published artifacts are versioned; superseding an article is a new approved revision, not a silent edit

Who this is for

Support teams with a deflection-worthy ticket pattern and a perpetually deferred KB backlog — especially where resolutions are already written up internally.