MTS: From RAG to Agents — Analyzing Jira Tickets via MCP and Logs

MTS Web Services lead engineer Ilya Paramoshin published on Habr the third article of a cycle on the development of a RAG assistant for technical support — this time on the transition from document search to a platform with MCP access to logs, databases, and automated Jira ticket analysis.

Three articles in one series

The material continues a series of two earlier publications by the same author on Habr. The first article was devoted to the architecture of a RAG assistant (Retrieval-Augmented Generation — response generation based on retrieved documents) for technical support: indexing Confluence and Jira, hybrid search, response generation with citations, and search quality assessment. The second, recent publication told how MTS Web Services built an AI agent for automatic ticket analysis.

• Author — Ilya Paramoshin, lead engineer at MTS Web Services
• First article in the series — architecture of RAG assistant for technical support (indexing Confluence and Jira, hybrid search, quality assessment)
• Second article — AI agent for automatic ticket analysis
• Third article (discussed here) — MCP, logs and the path of a ticket from creation to comment

Why did RAG need logs and MCP?

After implementing the RAG assistant, engineers at the company began to find needed instructions and regulations more quickly — this is a direct effect of the first version of the system, which Paramoshin notes. Incident investigation, however, required working with logs, databases, and Jira itself, not just text documentation in Confluence. This is why the team decided to expand the system beyond search rather than limiting themselves to knowledge base updates.

How the new platform is organized

MTS Web Services engineers did not rewrite the RAG system from scratch, but developed it as a platform around three tasks.

"We did not rewrite RAG, but began developing it as a platform around three tasks: unified interface, access to operational data, and automated ticket analysis," —

Ilya Paramoshin, lead engineer at MTS Web Services, in an article on Habr.

Search remained the core of the platform, but separate services appeared around it: some for interactive engineer work during investigation, others for background ticket analysis without human involvement. Of the three tasks around which the platform is built, the first is a unified interface through which the engineer accesses both document search and other services. The second is access to operational data: logs, databases, Jira itself, implemented, judging by the article's title, through the MCP protocol (Model Context Protocol) — an open standard that gives AI agents structured access to external data sources instead of a separate integration for each service.

The third task is ticket analysis automation, meaning the transfer of part of the engineer's routine work to background services.

According to the author, the article further discusses the architecture of the solution itself, the reasons why certain components were separated from the RAG system into independent services, and the path of a ticket — from creation to an automatically generated Jira comment. The material is titled "Life After RAG: MCP, Logs and Automatic Jira Ticket Analysis" — the title directly indicates a shift in focus: from pure knowledge base search to working with live operational data.

What this means

The MTS Web Services case shows a typical path for enterprise RAG system development: from a one-off chatbot over documentation — to an infrastructure that combines search, operational data, and automation of routine support ticket operations. Three articles in one series on Habr — from search architecture to AI agent and then to MCP access and logs — capture how requirements for corporate AI assistants change as engineers use them not just for reading documentation, but for incident investigation.

Frequently asked questions

What is MCP and why is it needed?

MCP (Model Context Protocol) is an open standard providing AI agents with structured access to external data sources — logs, databases, and ticketing systems — rather than requiring a separate integration for each service.

Why separate services instead of one unified RAG system?

Separating components allows the platform to optimize each task independently: interactive search for documentation, background analysis of logs, and automated ticket routing — each with its own requirements and SLAs.

How does this differ from other enterprise RAG systems?

Most corporate RAG implementations remain focused on search alone. MTS evolved theirs to include operational data integration and automation — making the platform suitable for incident investigation, not just documentation lookup.