Building an AI-Powered RCA Agent with Claude Code and MCP

It starts the moment an escalated customer ticket hits your queue. You reproduce the issue, dig through Datadog logs, cross-reference the Jira backlog, trace suspect commits in GitHub, write the RC ticket, create a test-case subtask, and document everything across Confluence, TestRail, and LambdaTest. By the time you finish, three hours have passed. The finding is something you half-suspected in the first ten minutes.

At Motive, I ran that ritual for every escalated TSSD ticket. The output was always the same shape: issue summary, reproduction steps, root cause, fix recommendation, and prevention plan. Inputs were scattered across four or five different systems. Figuring out what actually caused the problem took maybe thirty minutes. Everything else, two and a half hours of retrieval, formatting, and ticket creation, was coordination overhead.

That asymmetry is the opportunity. If the structure of the output is fixed and the sources of evidence are predictable, a tool can handle the gathering while you do the thinking. I built an AI agent that runs the mechanical 90% of every RCA in twenty minutes. This post explains how it works and what took the most iteration to get right.

Why RCA Maps Cleanly to an AI Agent

Not every QA task is a good fit for agentic AI. Code review judgment, exploratory testing, deciding whether a feature should exist at all, those still need a person. RCA is different because it has three properties that make it almost purpose-built for an agent.

The first is a fixed output structure. Every RCA your team writes follows the same template: what happened, how to reproduce it, what caused it, how to fix it, and how to prevent recurrence. That consistency means an agent can produce a correctly shaped document without knowing your business context at all. It fills in the template; you verify the content.

The second property is scattered but retrievable inputs. Evidence for a root cause lives in Jira, Slack threads, Confluence runbooks, Datadog dashboards, and GitHub diffs. None of it is secret, none requires creative inference, and all of it is accessible through an API or a CLI. That kind of retrieval is something a tool does faster and more thoroughly than a person, because it does not get bored or miss a search term at 4 PM on a Friday.

The third property is bounded judgment. At some point in the RCA process, someone has to decide what actually caused the problem. That decision requires interpretation and stays with the engineer. But the evidence gathering that precedes it, pulling related incidents, reading blame history, connecting a deployment timestamp to a symptom spike, can be delegated entirely. An agent assembles a timeline of facts and presents it for your review. You bring the judgment.

Compare this to exploratory testing, where the hard part is knowing what to try next. An agent poking a UI without direction produces noise. An agent executing a defined retrieval plan against known systems produces a useful draft. RCA is the second kind of task, and that is why it works. Agentic AI shines on work that is structured but not scripted: you know what success looks like, you know where the raw material lives, and what you want to eliminate is the hours spent finding it.

The Layer That Makes Grounding Possible

A plain language model is a dead end for real RCA work. You paste a ticket description, it generates a plausible-sounding analysis, and that analysis is largely fiction because the model never read the actual logs. Getting a usable RCA means connecting the model to the systems where the evidence lives. That connection is what the Model Context Protocol (MCP) provides.

MCP is a standard for tool use that lets an AI agent call external services as part of its reasoning loop. Instead of asking the agent to analyze text you paste in, you give it the ability to retrieve the source material itself. The difference in output quality is large enough that it changes what the tool is actually useful for.

Here is a concrete comparison. Without MCP, you copy a Jira ticket description and ask the model to suggest root causes. The model has no idea what other tickets exist, no visibility into linked bugs, and no access to past incidents. It makes educated guesses from a paragraph of text. With Atlassian MCP, the agent reads the source ticket, follows links to related issues, searches for past incidents that mention the same service, and returns evidence-backed analysis. Same model, same prompt structure, completely different result.

For the Motive agent, two MCP servers do most of the heavy lifting. Atlassian MCP handles everything Jira-related: reading the TSSD ticket, searching related bugs, and creating the RC ticket and linked test-case subtask with the right issue types, labels, and relationships already filled in. Glean MCP handles cross-system search across Confluence runbooks, Slack threads, and past RCA documents, so the agent can cite what actually happened before instead of inventing plausible history.

The key insight is that MCP converts a question into a workflow. “What caused this error” is unanswerable from context alone. “Read ticket ID-4821, search for related incidents from the last 60 days, and cross-reference the deployment log” is a retrievable set of steps. The agent executes those steps against real data and hands you a draft with citations, not guesses. You can think of it as the difference between asking an assistant to write a report from memory versus asking them to research it first. The second version takes more setup. It produces work you can actually trust.

Three Layers, One Agent

The agent has three distinct layers, and each one does a job the others cannot. Getting the architecture right took more iteration than the prompts did.

The first layer is Claude Code, running as the reasoning engine and orchestrator. Claude Code is not a chat interface you paste into. It is an agent harness with tool use, file access, and shell execution built in. I run it with a project-level instruction file that encodes the RCA template, ticket conventions, and definition of done, so every run produces artifacts that match team standards without re-explaining requirements each session. That instruction file version-controls the process: when the RC ticket format changes, I update one file and every future run picks it up automatically.

The second layer is the pair of MCP servers. Atlassian MCP and Glean MCP give the agent read and write access to the systems where the work actually lives. The agent does not operate on copies of data you paste in. It reads the source Jira ticket through the Atlassian connection, runs enterprise search through Glean, and creates the output tickets directly through the same MCP layer, with every field populated from what it actually found. The loop between reading and writing closes inside the agent run.

The third layer is the GitHub CLI. When the root cause involves a code change, knowing “something broke last Tuesday” is not enough. You need to know which PR introduced it, what the diff looked like, and whether the same pattern exists elsewhere. The agent uses gh to pull suspect PRs, read diffs, and run blame queries. Correlating a regression window with merged PRs is exactly the kind of tedious cross-referencing that takes an engineer forty minutes of tab-switching and takes the agent about thirty seconds.

One thing that took the most iteration to get right: the instruction file is where most of the product-specific configuration lives, not the prompt. The MCP servers are generic, the GitHub CLI is generic, and Claude Code is generic. What makes the agent produce Motive-shaped output instead of generic-shaped output is the context in that instruction file. Encoding your templates and conventions there, rather than re-prompting each session, is what turns a one-off experiment into a repeatable process.

What Actually Happens When You Run It

The best way to understand the agent is to follow one ticket through from start to finish. Here is what a typical run looks like.

You give the agent a TSSD ticket ID. That is the entire human input for the first five steps. The agent reads the ticket through Atlassian MCP, pulling the description, reproduction notes, environment details, and any linked tickets the reporter included. It also checks the creation timestamp and severity label, which affect how it frames urgency in the RC document.

From there it goes to Glean. The agent searches for related incidents, runbooks that cover the affected service, and past RCA documents that mention similar symptoms. This step regularly surfaces things I would have missed: a Confluence page someone wrote eight months ago, a Slack thread where an engineer flagged a known edge case, a prior incident with an almost identical error pattern. The search is broader than what any human would run manually, and it takes about ninety seconds.

If the evidence points toward a code change, the agent switches to the GitHub CLI. It queries PRs merged in the window around the symptom onset, reads diffs for anything that touches the relevant service or data path, and checks blame history for the files involved. This step is where the causal timeline takes shape. The agent connects a deployment timestamp, a behavior change, and a specific commit into a sequence that reads like a plausible explanation.

With all that context assembled, the agent drafts the full RC ticket: issue summary, reproduction steps, root cause with citations to everything it read, fix recommendation, and prevention plan. It also creates the test-case subtask linked to the RC ticket, with test ID, priority, and affected area already filled in. Then it generates the three documentation pages, the Confluence SQA doc, the TestRail test case, and the LambdaTest execution record, formatted to match existing standards.

The last step belongs to you. You read the draft, correct anything the agent got wrong, add the judgment calls only you can make, and publish. That review step is not optional. It is the design. The agent produces a reviewed artifact, not a final one, and treating it that way is what makes the speed gain safe to rely on.

In practice the review takes ten to fifteen minutes because the draft is usually 80 to 85 percent right on the first pass. Remaining fixes are mostly specifics the agent could not infer: a stakeholder decision made in a meeting, a known fragility in a service that lives in someone’s head, a fix preference the team settled on in a channel the agent did not search.

What the Results Actually Say

The headline numbers: roughly 90% of RCA effort automated, turnaround down from three hours to twenty minutes, and more than forty engineering hours saved per month across the team. Those are real figures and they deserve some unpacking so you know what is and is not behind them.

The three-hour-to-twenty-minute figure covers the full cycle from ticket assignment to artifacts ready for review. The twenty minutes includes the agent’s retrieval and drafting time plus your review pass. It does not include the original reproduction of the issue, which still happens before the agent runs, or the stakeholder communication that follows publication.

The 90% automation figure means the agent handles 90% of the steps I used to do manually. It reads the sources, structures the analysis, creates the tickets, and generates the documentation. The 10% I still own is judgment: deciding whether the agent’s proposed root cause is actually right, catching cases where a search result is misleading, and adding context the agent could not retrieve because it lives in a meeting or on a whiteboard.

Forty engineering hours per month is approximately right for a team running eight to twelve RCAs per month. If each one used to take three hours and now takes twenty minutes of human attention, the savings compound quickly. The time does not disappear. It moves to the work that actually requires engineering judgment.

One thing the numbers do not capture: the quality improvement. An agent that searches Glean finds five times as many related incidents as I would have searched for manually, because it does not get tired or satisfied after two results. RCAs it produces are more thoroughly cited and more consistently structured than ones I wrote under time pressure on a busy afternoon. That thoroughness catches recurrence patterns a manually-written RCA would have missed.

The Ten Percent That Stays With You

For all the efficiency gain, the agent has a clear ceiling. Understanding it is what keeps you from trusting it in the wrong direction.

The agent cannot evaluate whether its root cause is correct. It can find a plausible explanation grounded in the evidence it retrieved, and that explanation is often right. But it has no way to know when it is wrong. If the real cause is a race condition that only surfaces under specific load, and no past incident described it in terms the Glean search would match, the agent’s analysis will be coherent and wrong. The engineer reading the draft is the check on that failure mode.

The agent also cannot interpret implicit knowledge. Your team carries context that does not exist in any indexed document: the architectural decision made in a retro, the known fragility of a particular service that everyone just knows, the stakeholder preference that lives in a Slack DM. When a root cause involves that kind of context, the agent’s draft will be technically plausible but organizationally off. Fixing it in review takes thirty seconds once you recognize it, but you have to recognize it.

A subtler limit is retrieval scope. The agent searches the systems it is connected to. If the evidence lives in a Datadog dashboard or a team’s private Notion space that Glean does not index, the agent does not find it. The draft will not mention what it could not reach, and that silence can look like confidence. Knowing which systems your MCP connections cover, and which they do not, is part of operating the tool responsibly.

These limits are not arguments against building the agent. They are arguments for the review step. The agent’s job is to eliminate the mechanical ninety percent so the engineer can spend focused attention on the analytical ten. That division is more useful than having the engineer split their attention across all one hundred percent while tired and under time pressure. Treat the draft like a PR from a competent junior engineer: read it, trust the retrievals because you can check them, and bring your own judgment to the interpretation.

What You Need to Start

The setup is simpler than the architecture diagram suggests. You do not need to write a custom agent framework or build MCP servers from scratch. The infrastructure exists, and most of the configuration lives in one text file.

Start with Claude Code. It runs as a CLI and handles the orchestration layer, tool use, and reasoning without any additional code on your part. Install it, set your ANTHROPIC_API_KEY, and create a project-level CLAUDE.md file in the directory where you plan to run RCAs. That file is where everything product-specific lives: your RC ticket template, the Jira project keys the agent should use, the Confluence space where SQA docs go, and the definition of done for a complete RCA. Write it once and the agent reads it on every run.

Next, configure your MCP connections. Atlassian MCP and Glean MCP both have Claude Code integrations. For Atlassian, you need a personal access token and the base URL of your Jira and Confluence instances. For Glean, you need an API key scoped to the data sources you want the agent to search. Test each connection with a simple read query before you run a full RCA.

For the GitHub layer, install the gh CLI and authenticate it to your organization. Claude Code can call shell commands directly, so no additional configuration is needed beyond adding a note in your CLAUDE.md about which repositories are relevant for your incident types.

Two things make the biggest difference to output quality, based on the iteration I went through. First, put your actual RC ticket template in the instruction file, not a description of what a good RC ticket looks like. The more literal and structural the template, the less the agent has to interpret. Second, list the systems the agent should not consult, not just the ones it should. Without a negative list, the agent may search broadly and waste time on sources that are not relevant to your incident types.

The first real RCA you run will take longer than twenty minutes because you will spend time reading the draft carefully and adjusting the instruction file to match your team’s standards. After three or four runs, the output will reliably match your conventions, and the review step will shrink to the judgment calls that are actually yours to make.

What This Changes About the Job

Agentic QA is not a replacement for quality thinking. It is a reassignment of where quality thinking goes. Before this agent existed, I spent three hours per RCA and most of that time was retrieval and formatting. I was a human search engine with a Confluence account. The agent is a better search engine and it never gets tired of filling in the same template.

The output has not changed. It still has the same sections, the same structure, and the same engineer’s name on it. What changed is how the thirty minutes of actual analysis sits inside the three-hour block. Before, it was buried under coordination work. Now it is the whole job.

If your team runs RCAs on a regular cadence, the productivity math is straightforward. Three hours down to twenty minutes of human attention, across ten tickets a month, is close to two and a half full days returned to the team. You can put those days toward automation coverage, toward proactive incident prevention, or toward the exploratory work that a person actually has to do.

The build cost was a few days of iteration. Ongoing maintenance is occasional updates to the instruction file when the ticket format changes. The risk is a miscategorized root cause you catch in review, which is the same risk you had before, just surfaced faster and more visibly.

Start with one ticket. Run the agent, read the draft the way you would read a junior engineer’s first attempt, and correct what it got wrong. By the fifth ticket, the review will feel less like correction and more like sign-off. That shift is when you know the tool has earned its place in the workflow.