WorkerKitCase study: a support inbox triage worker
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.
Published by WorkerKit. Updated .
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.
For the current installation procedure, app-grant checks and acceptance steps, follow AI workers for support triage. This article explains the operating trade-offs behind that setup. The workload figures below are explicit planning assumptions, not measured customer results.
The job
The kit classifies and prioritizes support threads, prepares reply drafts and files tickets for real issues.
It can be a useful unattended AI worker when the team can answer three practical questions:
- Is there a repeatable decision? The team needs an agreed rubric for urgency and routing, including the cases a person must decide.
- What counts as finished? Reviewed threads need a classification and an appropriate draft or ticket. Unread threads and failed actions must remain visible as unfinished work.
- How will mistakes be found and corrected? Drafts still need review, and a wrong ticket priority can delay an urgent response. Name the person who checks both the message and the board change.
If those answers are unclear, narrow the job before enabling recurring work.
The loadout
The worker kit uses two apps. Their allowed operations define one part of the boundary; the support team's instructions and review define the rest.
| App | Published operations | Why the job needs them |
|---|---|---|
| Read messages and threads, search, apply labels, create reply drafts | Understand the inquiry and prepare a reply; no send or delete operation is granted | |
| Tasks | Read boards, items and comments; create and update items; add comments | File a new issue or attach a report to an existing one |
The kit has no calendar or CRM grant. Its rubric mentions account significance, so provide approved context for that decision or remove reliance on the signal. Do not assume it can look up customer tier from an app it cannot read.
Review the app firewall against the intended inbox and board. Narrowing a needed permission can leave a run partial or refused; check that result instead of treating reduced access as a complete triage run.
The schedule
The published kit imports an enabled support sweep every four hours and also supports on-demand runs. Follow the setup guide to pause that schedule before starting runtime. Begin on demand, inspect the results, then configure and enable a schedule that matches the team's coverage and review capacity. These are possible planning cadences, subject to the account's schedule options:
| Cadence | Scheduled opportunities per day | Trade-off to assess |
|---|---|---|
| Every four hours, all day | 6 | The published cadence; requires a separate urgent-incident route |
| Hourly across a ten-hour workday | 10 | More frequent daytime review, with overnight work waiting |
| Every 15 minutes across a ten-hour workday | 40 | More runs and review demand; check schedule and usage limits |
| Once daily | 1 | Suitable only where the team accepts that review interval |
Confirm the configured schedule and time zone. A cadence does not guarantee a maximum queue age: failed runs, unavailable apps and partial sweeps can all add delay. Keep time-critical reports on the team's existing escalation route.
What it costs
There is no fixed cost per sweep in the catalog. Use actual tool calls and model usage from representative runs. For planning arithmetic only, suppose a completed sweep used 12 app calls:
| Planning cadence | Assumed calls per completed run | Calls if every planned run completes at that usage |
|---|---|---|
| Every four hours, all day | 12 | 6 x 12 = 72 |
| Hourly, ten-hour workday | 12 | 10 x 12 = 120 |
| Every 15 minutes, ten-hour workday | 12 | 40 x 12 = 480 |
Twelve calls is an assumption, not a benchmark or capacity promise. Thread length, ticket searches, writes and retries change usage. Other workers also consume the account's allowance, so choose a plan using measured totals and the current daily, rate and schedule limits on /pricing.
Published WorkerKit plans and prices apply to shared cloud.
Model tokens are billed separately at provider list price with no markup, through the wallet or your own key. Include applicable app and platform charges, review time and correction effort when assessing the cost of an acceptable triage result.
The rules to inspect before leaving it running
Access controls limit what the worker can reach. They do not establish whether its priority assessment or reply is correct. Review the configured boundaries alongside the instructions and actual outputs.
Contact rules can restrict the people and threads available to the job. Configure them for the support scope, then verify which messages the worker can read and draft against. This kit's email grant has no send operation; asking it not to send is not the only boundary.
For built-in apps, supported field restrictions and redaction settings can narrow the data exposed to the model. Check the actual fields and permitted messages. Do not assume every sensitive value in free-text support email is automatically detected and removed.
Task updates deserve a separate check. The instructions prohibit closing tickets, but the granted update operation is broader than changing priority. If a hard boundary is needed, narrow the available operation or redesign that part of the job. Reviewing an email draft does not hold ticket writes for approval.
Reading a run
Every run writes a receipt: what it read, what it did, what it cost, and what it skipped with the reason. Check the actual drafts and board changes too. A receipt is execution evidence, not proof that the business result was right.
The current instructions establish a window from the run clock and an available prior-run checkpoint. Without one, the baseline is the preceding 24 hours, which the worker should report. That is not a complete historical backlog review.
The instructions also limit app reads to 40 calls, including searches, pages, ticket lookups and thread reads. This is an instruction to evaluate, not a hard limit on total run usage: writes and model usage are additional. A partial sweep must name unreviewed scope and failed reads instead of reporting a fully clear queue. Reconcile that scope with the inbox before deciding the intake job is finished.
Receipt history is 1 day on Free, 30 days on Pro, 365 on Team. If you are evaluating the worker over a longer period, choose retention that supports the review and check current limits on /pricing.
Where it should stop
The honest limits, which are also the settings worth getting right on day one.
- Send versus draft. This kit lacks an email-send operation. Keep the rep responsible for checking and sending its reply drafts.
- Abusive or legal-threat threads. The instructions require escalation instead of a draft. Check that the result reaches the responsible person.
- 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
The reasonable objection is that draft review can become a rubber stamp. A reviewer sees plausible text, trusts earlier results and sends without comparing it with the customer's original message.
That risk deserves an operating response. A draft is an opportunity to review, not evidence that meaningful review occurred. Workload and confidence in earlier results can make this easy to overlook.
Three things make it manageable, and none of them is "reviewers should try harder":
- Match volume to review capacity. Limit draft production to work the team can inspect. Keep the remaining queue visible and assign its next action.
- Review escalation behavior. Refund promises and legal positions need a person; legal threats should be escalated without a draft. These instructions need evaluation on representative threads, not an assumption that routing always works.
- Sample deliberately. Review sent replies against their original threads as a separate check on the process. Choose the sample and cadence for the volume and consequences involved; this can expose errors missed in the queue.
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.
Deciding whether to add a second worker
Triage answers "what came in". It does not answer "what did we promise and not deliver", which can be a separate job.
The receiving support team can own follow-through without another worker. Add one only when its inputs, permissions, output and owner are clear. Decide how the second job receives context and who handles missing or contradictory records. Installing two kits does not automatically connect their work.
That is how a useful first worker becomes part of an AI workforce: a defined next job and an explicit handoff, rather than a larger count of installed workers.
FAQ
Does the support worker send replies on its own?
No. Support Inbox Triager prepares reply drafts, and its published email grant has no send operation. A person reviews and sends the reply. Ticket writes occur separately during the authorized run.
What access does the Support Inbox Triager actually need?
The kit reads and searches email, can apply labels and creates reply drafts. It reads the task board and can create or update items and add comments. It has no calendar or CRM grant; provide approved context if the rubric needs information those apps would otherwise supply.
Can I restrict which threads it processes?
Configure the available email and contact rules for the job's scope, then verify which messages it can read and draft against. Also review the selected connected account and supported field restrictions. This kit cannot send email under its published grant.
What plan do I need to run this?
Choose a plan from observed calls per run, the desired cadence, other account usage and the review period. Check schedule options, daily and rate limits, and retention on /pricing. The planning table is not a measured throughput estimate; model usage is billed separately.
How do I know what it did overnight?
Read the run result and receipt, then inspect any drafts and ticket changes. Check the reviewed window, unreviewed scope and failed reads as well as the completed work. A missing run or partial sweep needs follow-up even if the last completed report contained no P1 items.
Can I change my mind about its permissions later?
Yes. Narrow or revoke the worker's grants and inspect the next result for refused or incomplete actions. Pause the worker while investigating if needed. Revoking access or pausing future work does not undo a ticket or draft already written.