Autonomous Triage for Knowledge Work Queues
Monitor inboxes, forms, chat channels, and ticket queues; filter noise, deduplicate, rank urgency, and route work to the right owner or agent run.
Connect the queues and write the triage playbook
Connect the inboxes and queues the run watches: Slack channels, Gmail inboxes, Zendesk tickets, and Linear issues. Opulent reads these as a single stream of work and decides what to do with each item.
The judgment lives in a playbook, a reusable, named set of steps Opulent follows every run. It defines what counts as noise, how to detect duplicates, how to rank urgency, and the routing rules for each category.
Playbook: !triage-queue For each new item in the stream: 1. Classify: support request, bug report, sales inquiry, internal ask, or noise. 2. Filter: drop spam, auto-replies, and items that match an ignore rule. 3. Dedup: search the last 30 days for the same sender, subject, or issue body. If found, merge or reference the existing item. 4. Rank urgency: customer-facing outage = critical; single-user bug = high; feature request = normal; newsletter = low. 5. Route: assign to a team, a person, or another agent run. 6. Log the decision and the reason to memory.
Start with read-only access and a 'dry run' mode that posts decisions to a private channel before routing for real. This lets you correct the rules before Opulent starts assigning work to teammates.
Arm the trigger: schedule or event-driven
Run triage on a schedule (every 15 minutes for fast-moving queues, hourly for slower ones) or trigger it on new events from Slack, Gmail, Zendesk, or Linear webhooks.
Event-driven triage feels real-time but can be noisy; scheduled triage batches items and makes routing decisions easier to review. Most teams start with scheduled and add event triggers later.
The sharp edge: a rule that routes too aggressively sends wrong items to busy people. A rule that routes too conservatively leaves urgent work in the queue. Tune by reviewing dry-run decisions for a week.
Watch one batch get sorted
Take a Monday morning batch from a shared support inbox: two outage reports, a duplicate billing question, a feature request, and a vendor newsletter.
Opulent flags the outage reports as critical and routes them to the on-call engineer in Slack. It recognizes the billing question as a duplicate of a Zendesk ticket opened Friday and links them instead of creating a new one.
The feature request goes to the product backlog in Linear with a 'needs-prioritization' label. The newsletter is dropped. Every decision is logged with the rule that triggered it.
Batch: 23 new items (08:00-09:00 UTC) Classified: - 2 outage reports -> CRITICAL -> #incidents, on-call engineer - 1 duplicate billing question -> MERGED with ZEND-4127 - 4 bug reports -> HIGH -> Linear board, sorted by component - 3 feature requests -> NORMAL -> backlog, labeled - 13 noise/auto-replies -> DROPPED Routed: 9 items, 0 unassigned, 1 conflict flagged for review.
What exists when the run finishes
A triage run produces a routing log: every item processed, its classification, urgency, assigned owner or agent run, and the rule that made the decision. Duplicates are linked rather than split. Items that could not be classified confidently are flagged for human review.
The memory entries are the proof-of-work: the playbook remembers which routing decisions were correct, which were corrected, and why, so the next run makes better decisions with less manual tuning.
Sharpen the triage loop
When a routing decision is wrong, correct it and write the correction into memory (the notes a run recalls next time): 'items from this sender always go to finance, not support.' After a few corrections, the miss rate drops.
Add owner maps and escalation rules as they become clear: 'if critical and on-call does not acknowledge in 5 minutes, escalate to engineering manager.' These rules belong in the playbook, not in ad-hoc messages.
The natural chain: once triage routes a bug report, hand it to Auto-Triage Bugs via Linear or Debug a Bug Report End-to-End; route customer issues to Customer Health Summaries in Slack for context before the human responds.