Case study: putting a support inbox on autopilot
A walkthrough of deploying the Support Inbox Triager kit: the access it needs, the schedule, the safety rules, what it costs and where it should stop.
This is a walkthrough of one real kit from the directory, Support Inbox Triager, taken end to end: what it does, exactly what access it needs, how it is scheduled, what it costs, and the cases where it should hand back to a person.
A note on what this is not. It is an implementation walkthrough, not a customer story. There are no invented companies and no invented hours-saved figures here. Every number is either from /pricing or arithmetic you can check.
The job
The kit's own job sentence: *triages the support inbox, classifies, prioritizes, drafts replies, and files tickets for real issues.*
That is a good candidate for an unattended worker for three reasons, and they are worth naming because they are the test for any job:
- It is repeatable. The same decision is made hundreds of times on structurally similar inputs.
- It has a definition of done. Every message ends up classified, and real issues end up as tickets.
- Its mistakes are recoverable. Drafts wait for a human. A misfiled ticket is a nuisance, not an incident.
A job failing any of those three is not ready to be unattended, whatever the model can do.
The loadout
Two apps, and the access level for each is the whole safety story:
| App | Level | Why that level |
|---|---|---|
| Write | It has to draft replies. Drafting is a write | |
| Tasks | Write | Filing a ticket is a write |
Two things follow immediately. It has no calendar access, because triage does not need to know your schedule, and it has no CRM access, because classifying a support message does not require the customer record. Access it does not hold is access it cannot misuse, which is the entire point of the app firewall.
The level is granted per app at Off, Read or Write, and can be narrowed later with the worker still running on what is left.
The schedule
Support has a working-day rhythm rather than a real-time one, so an hourly schedule fits: the queue is never more than an hour stale, and the worker is not burning runs overnight.
| Option | Runs a day | Verdict |
|---|---|---|
| Every minute | 1,440 | Over every plan's cap, and support is not a seconds-latency job |
| Every 15 minutes | 96 | Defensible for a busy queue, Pro territory |
| Hourly, working day | 10 | The sensible default |
| Once daily | 1 | Too slow: a morning ticket waits until tomorrow |
Schedules run on wall-clock time in your own time zone, so "hourly between 8 and 18" stays correct through daylight saving rather than drifting by an hour twice a year.
What it costs
Assume roughly 12 tool calls per run: list the new threads, read several, draft one or two replies, file a ticket.
| Cadence | Tool calls a day | Plan |
|---|---|---|
| Hourly, 10 hour day | ~120 | Free (500 a day) |
| Every 15 minutes, 10 hour day | ~480 | Free, at the edge |
| Every 15 minutes, all day | ~1,150 | Pro (5,000 a day) |
The hourly version fits inside the Free plan with room for other workers, which is the practical answer to "what does this cost": the plan is $0 and you pay only for model tokens, at the provider's list price with no markup, from the wallet or your own key.
Token cost depends on how much of each thread the worker reads, which is a real variable rather than one this page can honestly pin down for you.
The rules that make it safe to leave running
Access levels decide which apps. Two more layers decide the rest, and all three ship on every plan including Free.
Contact rules decide which people. A support worker should be able to reply to customers who wrote in, and should not be able to email the exec team because a customer mentioned them. Reads are filtered so restricted threads never reach the model, rather than the model being asked to ignore them. That distinction matters: an instruction is a request a model under pressure can talk itself past, and a filter is not.
Redaction decides what must never leave. Support threads carry account numbers and occasionally card details. Redaction strips those before they reach the model, outside anything the worker can negotiate with.
Reading a run
Every run writes a receipt: what it read, what it did, what it cost, and what it skipped with the reason. In the first week that is the thing you actually use, because the question is never "did it run" but "do I agree with how it classified these twelve".
Receipt history is 1 day on Free, 30 days on Pro, 365 on Team. If you are evaluating a worker's judgement over a month, that retention difference is the real reason to be on Pro, more than the tool-call ceiling.
Where it should stop
The honest limits, which are also the settings worth getting right on day one.
- Send versus draft. Drafting is the safe default. A worker that sends autonomously is a different risk decision, and one worth making deliberately after you have read a few weeks of receipts.
- Angry and legal threads. Escalation is a judgement call with reputational consequences. Route these to a person rather than to a draft.
- Anything touching refunds or credentials. Money and access are the two places where a plausible-but-wrong reply is expensive.
- A queue with no patterns. If every ticket is genuinely novel, there is no repeatable job to encode yet.
The reasonable objection
"Drafts are not the safety net you think. Nobody reads a draft carefully by week three. They skim it, see something plausible, and send. You have not kept a human in the loop, you have added a rubber stamp and called it review."
This is the strongest argument against the whole drafting pattern and it is substantially right about human behaviour. Review quality decays with volume and with the reviewer's confidence, and a worker that is usually good actively accelerates that decay: the better it gets, the less carefully anyone reads it.
Three things make it manageable, and none of them is "reviewers should try harder":
- Volume shapes attention. Ten drafts a day get read; a hundred get skimmed. If the queue is large, route a subset to drafts and leave the rest untouched rather than producing more review than anyone can do.
- The routing rules are the real control. Refunds, legal threats and angry threads should never reach a draft at all, because those are exactly the ones a skimmed review will wave through. That is a rule in the instruction, not a hope about the reviewer.
- Sample deliberately. Pick five sent replies a week at random and read them properly against the original thread. That is a different activity from reviewing the queue, and it is the one that actually detects drift.
The residual risk is real: if your team will rubber-stamp, drafting buys less than it appears to, and the correct response may be a narrower worker that only categorises and files, leaving humans to write. That is a legitimate outcome of this walkthrough rather than a failure of it.
Pairing it with a second worker
Triage answers "what came in". It does not answer "what did we promise and not deliver", which is a different job and therefore a different worker.
Follow-Up Tracker reaches email and tasks to track every thread you are waiting on a reply to and drafts a nudge when one goes quiet. Running both is the fleet pattern: two narrow workers rather than one broad one, each with its own key and its own access, either switchable off without touching the other.
Free allows 5 workers, so both fit with three slots spare.
FAQ
Does the support worker send replies on its own?
Drafting is the safe default: it prepares the reply and leaves it for a person. Sending autonomously is a separate decision, and one worth making only after reading a few weeks of receipts to see whether you agree with its judgement.
What access does the Support Inbox Triager actually need?
Write on email so it can draft replies, and Write on tasks so it can file tickets. Nothing else. It has no calendar or CRM access, because classifying a support message does not require either, and access it does not hold cannot be misused.
Can I stop it emailing certain people?
Yes, with contact rules. They filter reads so restricted threads never reach the model, and refuse blocked recipients outright. They ship on every plan including Free, and are enforced by the platform rather than by an instruction in the prompt.
What plan do I need to run this?
Hourly across a working day is about 120 tool calls a day, which fits inside Free's 500 with room for other workers. Every 15 minutes around the clock is Pro territory. Model tokens are billed separately at provider list price with no markup.
How do I know what it did overnight?
Every run leaves a receipt showing what it read, what it did, what it cost and what it skipped. Retention is 1 day on Free, 30 days on Pro and 365 on Team, so the plan choice is partly a question of how far back you need to look.
Can I change my mind about its permissions later?
Yes. Narrow a permission or switch one off at any time and the worker keeps running with whatever is left, recording on the receipt what it could not do. It never quietly regains access you removed.