Dispatcher routes every ticket to its fix.
Tickets arrive from people, from your own systems, from GitHub and from Jira. Dispatcher triages each one against a rubric you can read, and hands the actionable, harmless ones to an agent, with or without a person in the loop.
- Priority
- High
- Type
- Issue
- Danger
- Low
- Source
- spotter · SPT-1042
- Created by Spotter
- Triaged by Jev: high · issue · danger 0.04
- Dispatched to fix-bugs, a Claude Code routine
- The runner reported RUNNING
- The runner reported SUCCEEDED ·
github.com/…/pull/318
Every source, one queue.
However a ticket arrives, it goes through the same steps: created, triaged, and handed off if you allow it. Each credential is shown once and can be revoked on its own.
- By hand
- File a ticket in the console with a title and a description.
- Intake API keys
- One key for each of your systems. A key files tickets into one project and nowhere else, and only its hash is stored.
- Webhook sources
- A signed endpoint for a monitoring tool, a GitHub repository or a Jira project. GitHub and Jira issues are imported once each.
- Trusplex Spotter
- Every finalized issue report from your site becomes a ticket, and its status flows back.
Noise stays out
Put a webhook source in classify mode and Dispatcher asks, for each event, whether it is a real problem a person should look at, as opposed to normal operation, a health check or noise. Only real problems become tickets. The rest are logged as suppressed, so you can check its judgement.
# file a ticket from your own system curl -X POST 'https://console.trusplex.com/hooks/dispatcher/tickets' \ -H 'Authorization: Bearer tpx_…' \ -H 'content-type: application/json' \ -d '{"title":"Checkout fails", "description":"Customers in the EU cannot pay since 09:00."}'
Three questions, one rubric you can read.
Jev scores each ticket for its priority, its type and its danger. The rubric it is given is the same text you read on the Rubric page, so what the model sees and what you review never drift.
Priority
Impact and urgency: who is affected, is it production, is there a workaround?
- Critical: an outage, data loss or an active exploit, with no workaround.
- High: major functionality broken for many users, or in production.
- Medium: part of the product impaired for some users, with a workaround.
- Low: cosmetic issues, edge cases, requests and questions with no urgency.
Type
Decided by what the ticket asks for, not by its tone, length or spelling.
- Issue: something doesn't work as intended, and a change could fix it.
- Feature request: new behaviour, or a change by design.
- Non-technical: a real request a person must handle, such as billing.
- Spam: no genuine request or report at all.
Danger
Tickets here can reach an agent that changes your code, so each one gets an estimate of how likely it is to be malicious: prompt injection, attempts to extract secrets, backdoors, social engineering.
An honest report of a security vulnerability is not malicious.
Low-confidence answers and dangerous tickets are flagged for review. A priority you set by hand is never replaced by triage, only by an explicit re-triage.
Hand the ticket to an agent, and hear back.
A resolution target is where a ticket goes to be fixed. Dispatcher delivers the job through one of your project's connections and holds no credential of its own. The runner reports its progress on a one-time callback URL for that job.
- Claude Code routine
- Fires a routine on the Anthropic subscription that owns it, with the ticket, your instructions and the callback URL. The routine's own saved prompt decides what it may do.
- Claude Code or Codex runner
- Sends the job to a runner endpoint you operate, with the repository, the base branch, your instructions and the tools it may use.
- Webhook
- A signed POST of the ticket to any HTTPS endpoint.
Automatic resolution, off until you say
Turn it on for your organization or for one project, and new tickets go to an agent without waiting for a person. A ticket is handed off only if triage classed it as an issue or a feature request, its danger is below your threshold, and its priority meets the target's minimum.
One timeline for each ticket
Comments, triage, dispatches and the runner's reports, oldest first. A runner's reply shows as an internal comment, hidden from the person who reported the issue. When Dispatcher holds a ticket back, the timeline says why.
Stop triaging by hand.
Create an intake key or a webhook source, and your next ticket arrives already sorted. Pair Dispatcher with Trusplex Spotter and your site's issue reports arrive too.