Autonomous JIRA Triage: What an MCP Agent Actually Does
Most engineering managers I talk to have the same recurring meeting on Monday morning. It is not on the calendar. It is the thirty to sixty minutes they spend triaging the…
Most engineering managers I talk to have the same recurring meeting on Monday morning. It is not on the calendar. It is the thirty to sixty minutes they spend triaging the weekend's JIRA inbox — reading new tickets, asking the reporter for missing detail, pointing the right engineer at the right problem, closing the duplicates, and politely deflecting the things that should be a Slack DM.
This is the loop where agents start to make sense. Not the kind of agent that "augments" the manager. The kind that reads the inbox before the manager does, drafts a reply for each ticket, and waits for a one-click approve.
We built this in KavrynOS. It has been running on our own backlog for six weeks. Here is what an MCP autonomous agent actually does — and the specific design decisions that determine whether it becomes useful or becomes the next thing to triage.
The Loop, Without The Manager
The MCP agent in KavrynOS runs continuously in the background. The configuration is intentionally narrow:
- A JQL filter — the slice of JIRA the agent should watch.
- A response team list — the JIRA usernames whose presence on a ticket should make the agent skip it.
- A polling interval.
When a new or updated ticket matches the filter, the agent fetches the ticket, runs it through the product knowledge base — a living KB file generated by Claude Code across our actual repos and database schemas — and drafts a contextual reply.
The draft does not post automatically. It lands in an approval queue.
A human reads the draft. Edits if needed. Clicks Approve & Post — or rejects. The post goes to JIRA as a real comment from a service account, with an audit log entry pointing to the original prompt and the model output.
That is the entire loop. There is nothing magical. The honesty about what the loop is — and what it is not — is what makes it usable.
What The Agent Does Well
After six weeks across our own backlog plus three customer engagements, here is what the agent reliably handles without human edit:
Asking for missing reproduction steps. Roughly a third of inbound tickets do not include enough detail to act on. The agent's draft says, in the team's tone, "could you share the org ID, browser, and the exact URL where this happens?" Polite, scoped, fast.
Pointing at the right repo. The KB knows which repo handles which surface. The agent's draft says "this looks like it lives in the billing-service codebase, ticket assigned." It is right about 95% of the time on tickets that touch a single domain.
Surfacing duplicates. The agent searches the KB and the recent ticket history. When a ticket is a duplicate of something filed in the last quarter, the draft links to the older ticket and proposes closing this one as duplicate. Catching duplicates manually is the most thankless part of triage.
Linking to known docs. "We documented this in CLAUDE.md for the audit-log repo, here is the section on retention windows." The KavrynOS Repo Scanner generates these docs automatically; the agent just retrieves them.
These are not deep technical responses. They are the first thirty seconds of triage that a manager would otherwise spend on every single ticket. Removing them from the manager's plate is the entire value.
What The Agent Does Badly (And Why That Is Fine)
The agent is bad at things you would expect it to be bad at, and we have not tried to disguise this.
Cross-team political reads. When a ticket is filed by a customer success manager who is escalating because they are panicking about a renewal, the agent does not read the panic. The draft says "we will investigate." The manager rewrites it.
Edge cases that touch tribal knowledge. "This is the third time we have seen this — last time it was a flaky DNS issue." The agent does not know that. It is not in the KB. The manager edits the draft to include the context.
Anything that requires saying no. When a ticket is asking for something that we are not going to build, the agent's draft hedges. The manager rewrites it to say no. This is a feature: we do not want the agent posting "no" without human review.
The right framing is that the agent does the obvious 60–70% and the manager does the actual judgment-call 30–40%. That ratio shrinks triage from forty minutes to ten.
The Approval Queue Is The Whole Thing
I want to be specific about why the approval queue matters more than any individual capability of the agent.
Most "autonomous agent" demos show the agent acting directly on the world. Posting comments. Closing tickets. Sending emails. The demo looks impressive. The pilot eventually breaks because the agent confidently does something wrong, the team trusts it less, and the project quietly winds down.
The approval queue inverts this. The agent does the cognitive work. The human keeps the final action. The agent never embarrasses the team in front of a customer because the agent never speaks until a human has read what it wants to say.
This is not a limitation we are trying to remove. It is a design choice. We have an auto-approve toggle for low-stakes ticket types — duplicate-detection drafts, missing-info requests — and even those are disabled by default. The cost of an agent embarrassment in front of a customer is much higher than the cost of the human staying in the loop.
The MCP Part Matters
A note for engineers reading this who care about how the integration is built. The agent uses the Model Context Protocol as the layer between Claude and the JIRA/Bitbucket/database tooling. We did not invent a custom orchestration framework. We did not glue together five SaaS APIs with brittle webhooks.
This matters for two reasons.
First, the surface is portable. If you want to swap the JIRA integration for Linear, you replace the MCP server, not the agent logic. The agent does not care which ticket system is on the other side, as long as the MCP server speaks the contract.
Second, the same agent loop works for ticket triage, code review queue management, on-call summaries, weekly status drafts, and anything else where the work is "look at a stream, draft a response, hand it to a human." We have already shipped versions of the same loop for two of those.
The Configuration Tax Is Real
I will not pretend setup is free. The first run of an autonomous agent against a real JIRA project takes about two hours of work:
- Writing a JQL filter that captures the right slice without capturing everything.
- Defining the response team list so the agent does not draft on top of teammates.
- Tuning the system prompt — editable from the Prompts Manager — so the drafts sound like your team and not like a press release.
- Watching the first ten or twenty drafts and rejecting bad ones to feed the iteration.
After that, the agent is mostly maintenance-free. We have not edited the prompt for our internal triage agent in three weeks. It just works.
When It Is Worth Doing
Autonomous JIRA triage is worth doing when three things are true:
Your inbox is high-volume — at least twenty new tickets a week. Most of those tickets follow patterns that a careful team member would handle in a few obvious ways. The cost of a slow first response is real — customer churn, internal frustration, missed SLA.
If you are filing eight tickets a quarter and a single engineer reads all of them in a leisurely way, you do not need an agent. You need a calendar.
If the triage queue is slowly poisoning your team's mornings, this is the agent worth building.