At a Glance
A global semiconductor equipment manufacturer keeps production machines running through a high volume of troubleshooting and maintenance work. That work lives in Jira. The company runs its issue tracking, ticket history, and day-to-day engineering coordination on the platform, and has no intention of moving off it.
The problem was never the tracker. It was everything the tracker could not do on its own: when a machine threw a fault, an engineer still had to manually reconstruct what had gone wrong, dig through scattered work instructions and past tickets, and reason toward a fix. The company asked ThirdAI Automation for something specific — bring AI-driven Root Cause Analysis directly into the Jira they already use, without asking anyone to learn a new tool.
Key takeaways
03- 01A bespoke Jira plugin posts Root Cause Analysis as a comment on the ticket itself — no new app to open, no context-switch.
- 02RCA is paired with an interactive AskAI agent, so engineers can interrogate the data conversationally and choose the output format.
- 03In a side-by-side evaluation, the manufacturer's engineers overwhelmingly preferred ThirdAI over Atlassian's native Jira agent, Rovo.
The Challenge
On a semiconductor line, a single marginal reading can stop a machine, and the fix is rarely obvious. In one representative ticket, a borderline sensor reading looked like a hardware fault; the mechanical team suspected something was left open. The real resolution was recalibration, not a hardware change. Getting there took time and experience, and the path to the answer was not written anywhere obvious.
That pattern repeated across the operation. Troubleshooting a single issue could take hours to days, and the risk was not just slowness but missed information: the one work instruction, the one prior ticket, or the one log detail that would have pointed straight to the fix. The company framed the core constraint plainly — engineers will not adopt a separate platform that adds a learning curve and pulls them out of their existing workflow. Any solution had to meet them inside Jira.
The goal was never to replace Jira. It was to make Jira answer the question every engineer was already asking: what actually fixes this?
How It Worked Before ThirdAI
Before ThirdAI, diagnosis was manual and memory bound. When a fault came in, an engineer began by gathering context before they could even start reasoning about the cause — pulling logs, exporting scope-trace data to CSV to plot and inspect, and hunting for the relevant work instruction.
That hunting was the bottleneck. Machine build documentation was organized in tidy folders, but the day-to-day troubleshooting knowledge that actually resolved tickets — step-by-step work instructions, often exported from slide decks or spreadsheets into inconsistent PDFs — was scattered across many locations. When an issue recurred, the hard part was finding either the earlier Jira ticket that had solved it or the work instruction tied to it. Engineers partially compensated by manually linking documents into tickets, but nothing surfaced similar tickets or the right instruction automatically. Institutional knowledge existed; it just was not reachable at the moment it was needed.
- Manual reconstruction — reconstruct the problem from logs and marginal readings with no guided starting point.
- Documentation sprawl — search scattered, inconsistently formatted work instructions and past tickets by hand.
- Slow time to resolution — hours to days per issue, with a real chance of missing the detail that mattered.
How ThirdAI Made a Difference
ThirdAI Automation built a bespoke Jira plugin rather than another standalone platform. It operates on top of Jira, inside the interface engineers already know. When a ticket comes in, the plugin generates a Root Cause Analysis and posts its findings as a comment on the ticket itself — analysis, likely causes, similar past tickets, and suggested actions, all where the work already happens. There is no new application to open and no new interface to learn, which was the adoption barrier the company cared most about.
Integrate on top of Jira, not beside it. Post the analysis as a comment, in the UI engineers already use — no new platform, no context-switch.
Crucially, the plugin pairs RCA with AskAI rather than delivering root-cause output alone. Engineers can interrogate the available data conversationally, follow up on the analysis, and even choose the format the output comes back in. The agents are fluid: users drive them, and the responses adapt to how each engineer wants to work.
Under the hood, ThirdAI focused on the quality and reliability of the analysis itself. The team ran a structured program of RCA improvements — excluding leaked resolutions so the model reasons rather than parrots, retrieving similar tickets and relevant work instructions for context, and reasoning about expected behavior so operator or setup issues are not misread as software defects. The change that helped most was disciplined preservation of concrete evidence: keeping exact parts, versions, modules, modes, and procedures intact instead of genericizing them, so recommendations stay specific enough to act on. The system also handles both structured and visual data, reading messy CSV scope-trace exports and applying vision analysis to plots and screenshots where a pattern is easier to see than to parse.
To validate the approach, the manufacturer put ThirdAI head-to-head against Atlassian's own Jira agent, Rovo. A custom evaluation platform let its users compare the two agents' responses side by side on real RCA tasks — identical tickets, identical inputs, judged on whether the answer was correct and actually actionable.
The Impact After ThirdAI
In the side-by-side evaluation, the company's employees — the engineers who do the troubleshooting — overwhelmingly preferred the ThirdAI plugin over Rovo. Against the platform vendor's own native agent, ThirdAI won on the work that matters most: finding the real root cause and returning something an engineer could act on immediately.
Beyond the head-to-head result, the change showed up in how work gets done. Root cause analysis now starts the moment a ticket is created, instead of after an engineer has spent time assembling context by hand. Similar past tickets and relevant work instructions surface automatically, so hard-won institutional knowledge is reachable at the point of need. And because everything lives inside Jira as a comment, adoption came without the friction of a new tool — the outcome the company insisted on from the start.
- Preferred over Rovo — the manufacturer's engineers chose ThirdAI over Jira's native Rovo agent in direct, side-by-side comparison.
- Faster to first insight — RCA is generated on ticket creation, cutting the manual context-gathering that used to precede diagnosis.
- Fluid, not fixed — interactive AskAI with engineer-selectable output formats, adapting to how each user works.
- Zero-friction adoption — delivered inside Jira, so engineers gained the capability without leaving their workflow.
The Outcome
For the manufacturer, the result was not a new system to maintain but a sharper version of the one they already trusted. Jira stayed the system of record; ThirdAI made it capable of explaining faults, not just tracking them. Troubleshooting knowledge that used to live in scattered files and individual memory is now surfaced automatically, in context, the moment an engineer needs it — and when measured against the platform's own AI agent, ThirdAI is the one its engineers reach for.
