Product Support Triage Agent

Overview

Jira Service Management (JSM) is Atlassian’s IT service management platform, the system where Product Support tickets are submitted, queued, and worked. The PSRD (Product Support Remediation Desk) board is the JSM project that receives them. Every ticket that enters the PSRD queue needs a consistent first-touch classification: is this an Incident, a Problem, or a Service Request? Which request type and PS category does it map to? Does it belong on this board at all? Manual triage produced inconsistent answers, especially on edge cases like aggregator-wide outages versus single-FI failures, or active incidents that also reference a historical pattern.

The Product Support Triage Agent is a Rovo agent that classifies every new ticket the moment it enters the PSRD queue and returns a strict JSON payload that JSM Automation maps into routing and telemetry fields. It does not replace the human triager. It produces suggestions that a PSE confirms, and it removes the cold-start ambiguity from every incoming ticket.

Why this build was different: an agent inside an automation

Most Rovo agents are conversational. A person chats with them, refines a request, and iterates. This agent lives inside a JSM Automation rule, not a chat window, and that shaped every design decision:

• One shot, no follow-ups. The agent receives only the ticket’s summary and description and gets a single turn to classify it. It cannot ask the reporter a clarifying question, so clarificationNeeded and clarificationQuestion exist as outputs for the human triager, not as a back-and-forth with the reporter.
• Headless execution. No human reads the raw response. JSM Automation parses {{agentResponse.asObject.*}} directly into custom fields, which is why the output is strict JSON only: no code blocks, no preamble, no prose. Any wrapping breaks the parse and the rule fails silently.
• All logic lives in the prompt. The agent cannot be reconfigured at runtime, so every classification rule, tiebreaker, fallback mapping, and few-shot example had to be encoded up front. The three-stage framework, the priority-ordered subcategory tables, and the seven tiebreakers exist because the agent has to handle every case in a single pass.
• Trigger and filter design. The automation fires only on the right tickets: it triggers on PSRD queue entry, ignores spectre_alert tickets and Request Type ID 889, then branches on nonPsrd to route non-PSRD work to Needs Review.
• Non-destructive by necessity. The agent runs on every ticket with no human gate before it acts, so v1 writes only to telemetry and reference fields. Production Request Type and PS Category are never overwritten without a triager’s confirmation. An automation-driven agent that silently mutates production fields is a trust and auditability risk.

Building an agent that lives inside an automation is a different engineering problem from building a chat agent. It has to be deterministic, self-contained, parse-safe, and safe to run on every ticket without supervision.

The three-stage decision framework

The agent follows an explicit, ordered framework rather than open-ended judgment:

Stage 1: workType

Classify the ticket as Incident, Problem, or Service Request.

Stage 2: requestType and psCategory

Once workType is set, evaluate a priority-ordered subcategory table and take the first match.

• Stage 2a (Incident): six subcategories evaluated in priority order: Stakeholder Escalation, Linked to Problem, Partner/Aggregator Outage, Institution Connectivity Failure, Data Quality Incident, Client Outage/Degradation.
• Stage 2b (Problem): Aggregator Cleanup/Migration, Performance Trend/Conversion, RCA, or the catch-all Investigate a Problem, with a fallback mapping table for cases where a specific Request Type ID or PS problem category is unavailable.
• Stage 2c (Service Request): Connectivity feature/Configuration, Scrape/New Connectivity Method, Data/Reporting support, Alert/Monitoring configuration, or General Inquiry.

Stage 3: confidence and clarification

Assign High / Medium / Low confidence and a clarification flag based on decision-tree match quality, lexical signal strength, whether tiebreakers were needed, and similarity to the labeled examples. Low confidence always sets clarificationNeeded: "True" and one targeted question about the single unknown that would most change routing.

Tiebreakers: the edge-case rules

Edge cases are where deterministic triage matters most. Seven tiebreaker rules take priority over general signal matching, applied in order:

1. FI-specific vs. aggregator-wide. Default to Institution Connectivity Failure. Upgrade to Partner/Aggregator Outage only when multi-FI impact is explicitly confirmed.
2. Stakeholder escalation overrides technical cause. CSM, AM, or executive origin, or escalation language, always classifies as Stakeholder Escalation.
3. An active issue is an Incident. A ticket opened as an active problem right now is an Incident even if a pattern is mentioned. Create a separate Problem for the pattern.
4. Broken config with active impact is an Incident. If clients are impacted now, it is an Incident. If the config is wrong but not yet causing impact, it is a Service Request.
5. Specific Problem subtype over catch-all. Use Investigate a Problem only when the subtype is unclear at intake.
6. Single-client data defect vs. systemic. One client or FI affected now is an Incident. Multiple clients or FIs from the same underlying defect is a Problem.
7. Non-PSRD detection. Internal Eng/TOPS tasks and documentation requests are not PSRD work. Flag nonPsrd and route to Needs Review.

The output schema

The agent returns one JSON object (no code block, no preamble, no "fields" wrapper) that JSM Automation parses directly:

{
  "workType": "Incident" | "Problem" | "Service Request",
  "requestType": "<value from Stage 2 tables>",
  "psCategory": "<value from approved list>",
  "confidence": "High" | "Medium" | "Low",
  "clarificationNeeded": "True" | "False",
  "clarificationQuestion": "<single concise question, or omit if false>",
  "rationale": "<1-2 sentence plain-English reasoning>",
  "nonPsrd": "True" | "False",
  "routeTo": "PSRD board" | "Internal/TOPS" | "TechOps Docs" | "Needs Review"
}

How automation consumes it

A JSM Automation rule triggers the moment a ticket enters the PSRD queue (ignoring spectre_alert tickets and Request Type ID 889), passes {{issue.summary}} and {{issue.description}} to the agent, and branches on the response:

• If nonPsrd = "True": sets Needs Review, writes confidence, clarification, and rationale, and adds an explanatory comment.
• Otherwise (PSRD work): writes workType, confidence, clarificationNeeded, rationale, nonPsrd, and routeTo into the corresponding (Rovo) telemetry custom fields.

This version is non-destructive: requestType and psCategory suggestions land in telemetry and reference fields, and the production Request Type and PS Category are never overwritten by automation. A human triager reviews and confirms those.

The feedback loop

Every agent output is captured in (Rovo) custom fields for human validation. A separate agentFeedback (Rovo) field lets the triager who sees the ticket note when the agent got it wrong. That feedback goes straight into prompt and logic updates, so accuracy improves with each iteration.