How Dust runs Support on Dust

Dust Support evolved from a single @support agent to @Dust, powered by a Support skill. The flow looks like the following.

Trust me, it’s simpler than you think.

When customers reach out, it triggers a ticket that lands in Plain. The Support skill triages it, investigates by querying our APIs with Computer (Plain, Datadog, Stripe, Metronome, Temporal) and reads our internal support knowledge (files in a Pod, which we populate with Dust itself).

Dust can raise anything that needs a team as a GitHub issue or a Slack thread, draft a reply, and update the ticket. A human reviews the draft before it goes out.

Two Support Engineers run it for about a thousand users a week.

The trick is that the Support skill does none of this itself. It nests smaller skills, each with one job: triage the thread, query an API, write in our reply voice, review the draft, create the GitHub issue, start the Slack thread. Nesting is what makes them reusable.

A skill written for Support isn’t trapped in Support: the one that raises a bug to engineering also routes a pricing question to finance. The Customer Success team calls the same skills after a customer call.

When the knowledge changes, we edit a file in the Pod. When we want new behavior, we add a skill. Nothing else moves.

Write down how you handle a ticket today; that’s your master skill. Split the moves you repeat into small skills. Put your knowledge in a Pod. Keep one human review before anything reaches a customer. The hard part isn’t building it; it’s noticing your process was this simple all along.