Replacing Manual Jira Ticket Triage with an AI Agent

Every engineering and support team drowns in a version of the same problem: tickets arrive faster than they can be read, let alone triaged. The backlog grows. High-priority issues get buried under noise. The team that should be fixing problems spends an hour each morning just sorting them.

A Jira triage agent processes every incoming ticket the moment it arrives — classifies, prioritizes, assigns, and drafts an initial response — before any human reads it. The team starts from an already-organized board, not a raw queue.

What Triage Actually Involves

Manual triage is a sequence of decisions made for every ticket:

1. Classify — is this a bug, feature request, question, or incident?
2. Assess severity — does this block a user? Affect production? Is it cosmetic?
3. Assign team/component — which team owns this area of the system?
4. Set priority — P1 through P4 based on impact and urgency
5. Link related issues — is this a duplicate? Does it relate to a known bug or epic?
6. Draft initial response — acknowledge the reporter, ask clarifying questions if needed
7. Tag and label — add relevant labels for filtering and reporting

A skilled engineer does this in 2–3 minutes per ticket. At 50 tickets/day, that's 2+ hours of pure categorization work — work that follows predictable rules.

Architecture

┌─────────────────────────────────────────────────────────────────┐
│                     JIRA TRIAGE AGENT                           │
│                                                                 │
│  Trigger: new ticket created (Jira webhook → Kafka)             │
│                                                                 │
│  1. Fetch full ticket context from Jira MCP                     │
│  2. Search for duplicates / related issues                      │
│  3. Classify + prioritize with LLM                              │
│  4. Update Jira fields (type, priority, component, labels)      │
│  5. Link related issues                                         │
│  6. Post initial comment (triage summary + questions)           │
│  7. Notify assigned team via Slack                              │
└──────────┬──────────────────────────────┬────────────────────────┘
           │                              │
    ┌──────▼──────┐               ┌───────▼────────┐
    │  Jira MCP   │               │  Slack MCP     │
    │ (read/write │               │ (notify teams) │
    │  tickets)   │               │                │
    └─────────────┘               └────────────────┘

MCP Configuration

{
  "mcpServers": {
    "jira": {
      "command": "uvx",
      "args": ["mcp-server-atlassian"],
      "env": {
        "JIRA_URL": "${JIRA_URL}",
        "JIRA_EMAIL": "${JIRA_EMAIL}",
        "JIRA_API_TOKEN": "${JIRA_API_TOKEN}"
      }
    },
    "slack": {
      "command": "uvx",
      "args": ["mcp-server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "${SLACK_TOKEN}"
      }
    }
  }
}

Classification Schema

Define the classification schema explicitly so the agent returns parseable, actionable output:

TRIAGE_SCHEMA = {
    "issue_type": ["bug", "feature_request", "question", "incident", "task"],
    "severity": {
        "P1": "Production down, data loss, or security breach — all hands",
        "P2": "Major feature broken, significant user impact — fix this sprint",
        "P3": "Minor issue, workaround exists — schedule in backlog",
        "P4": "Cosmetic or nice-to-have — consider for future release",
    },
    "component": ["auth", "data-pipeline", "api", "frontend", "infrastructure", "billing", "unknown"],
    "requires_clarification": "boolean — does the ticket lack enough info to act on?",
    "clarifying_questions": "list of specific questions if requires_clarification is true",
    "potential_duplicate": "boolean — does this look like an existing known issue?",
    "related_issue_search_query": "JQL query to find potentially related issues",
}

The Triage Prompt

You are a Jira triage agent for an engineering team. Your job is to
analyze incoming tickets and produce a structured triage decision.

Ticket details:
Title: {title}
Description: {description}
Reporter: {reporter}
Project: {project}

Team component ownership:
- auth: login, SSO, permissions, API keys
- data-pipeline: ETL, ingestion, transformations, dbt, Airflow
- api: REST endpoints, webhooks, rate limits
- frontend: UI, dashboards, browser compatibility
- infrastructure: deployment, scaling, monitoring, databases
- billing: subscriptions, invoicing, payment processing

Severity guidelines:
- P1: system down, data loss, security vulnerability, affects >50% of users
- P2: key feature broken, no workaround, affects significant user group
- P3: feature degraded, workaround exists, affects some users
- P4: minor UX issue, cosmetic, enhancement request

Respond with valid JSON only matching this schema:
{
  "issue_type": "bug|feature_request|question|incident|task",
  "severity": "P1|P2|P3|P4",
  "component": "auth|data-pipeline|api|frontend|infrastructure|billing|unknown",
  "requires_clarification": true|false,
  "clarifying_questions": ["question 1", "question 2"],
  "potential_duplicate": true|false,
  "related_issue_jql": "JQL query string",
  "triage_summary": "2-3 sentence explanation of this classification",
  "initial_response": "Draft response to post as a comment on the ticket"
}

Applying the Triage Decision

import anthropic
import json
from jira import JIRA

client = anthropic.Anthropic()
jira = JIRA(server=JIRA_URL, basic_auth=(JIRA_EMAIL, JIRA_API_TOKEN))

def triage_ticket(ticket_key: str) -> dict:
    issue = jira.issue(ticket_key)

    # Get triage decision from LLM
    response = client.messages.create(
        model="claude-haiku-4-5-20251001",    # fast + cheap for classification
        max_tokens=1024,
        messages=[{
            "role": "user",
            "content": TRIAGE_PROMPT.format(
                title=issue.fields.summary,
                description=issue.fields.description or "No description provided",
                reporter=issue.fields.reporter.displayName,
                project=issue.fields.project.name,
            )
        }]
    )

    triage = json.loads(response.content[0].text)

    # Apply updates to Jira
    update_fields = {
        "priority": {"name": triage["severity"]},
        "components": [{"name": triage["component"]}],
        "issuetype": {"name": triage["issue_type"].replace("_", " ").title()},
    }
    issue.update(fields=update_fields)

    # Find and link related issues
    if triage["potential_duplicate"]:
        related = jira.search_issues(triage["related_issue_jql"], maxResults=3)
        for rel in related:
            jira.create_issue_link("Relates", ticket_key, rel.key)

    # Post triage comment
    comment = f"""**🤖 Automated Triage**

**Classification:** {triage['issue_type']} | **Severity:** {triage['severity']} | **Component:** {triage['component']}

{triage['triage_summary']}

---

{triage['initial_response']}

*This triage was performed automatically. The assigned team will review shortly.*"""

    jira.add_comment(ticket_key, comment)

    return triage

What the Team Sees

When an engineer opens Jira in the morning, every overnight ticket already has:

• Correct issue type, priority, and component set
• Related issues linked
• An initial comment explaining the triage reasoning and any clarifying questions
• Their Slack channel pinged if it's a P1 or P2

The morning triage meeting becomes a review of the agent's decisions rather than a categorization session. The team focuses on the ones that need human judgment — ambiguous edge cases, P1s, tickets the agent flagged for clarification — rather than mechanically processing the entire queue.

Escalation guardrail: Any ticket classified as P1 triggers an immediate Slack notification to the on-call channel with the ticket link and triage summary, regardless of the time. The agent doesn't sleep.

Book a strategy session to automate your engineering workflow.