---
id: "lib-2026-10-28-why-aviasales-dropped-open-source-mcp-servers"
type: "library"
title: "Why Aviasales dropped open-source MCP servers"
title_original: "KARPOV.CONF 2026: MCP-серверы для корпоративных агентов"
lang: "RU"
org: "Aviasales (KARPOV.CONF 2026)"
source_type: "Talk"
date: "2026-10-28"
week: "2026-W44"
url: "https://nosov.ai/library/lib-2026-10-28-why-aviasales-dropped-open-source-mcp-servers/"
original_url: "https://www.youtube.com/watch?v=P-VACeCI3W4&t=3582"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "A first-hand build-and-run account from an ML platform tech lead at Aviasales, specific about why community MCP servers failed and what replaced them, but the quality and usage figures are self-reported with no evaluation set or baseline shown."
summary_basis: "transcript"
original_minutes: "23"
tags: ["ai technology", "mcp", "agent platform", "sql agents"]
---

# Why Aviasales dropped open-source MCP servers

Original title: KARPOV.CONF 2026: MCP-серверы для корпоративных агентов

Tier B (Useful, limited): A first-hand build-and-run account from an ML platform tech lead at Aviasales, specific about why community MCP servers failed and what replaced them, but the quality and usage figures are self-reported with no evaluation set or baseline shown.

Summary based on the full transcript.

## In short

A 23-minute talk at KARPOV.CONF 2026 (28 October 2026) by Ruslan Serodzhidinov (surname garbled in captions), who leads AI and agent services on the ML platform at Aviasales, the travel metasearch group. In 2025 the company built two agents: a company-wide search over internal knowledge bases and a SQL agent for analysts. The first version used community open-source MCP servers with Claude and Cursor as orchestrators. Beta testing showed polluted context and poor answers, so the team rebuilt on its own MCP servers, indexes, a LangGraph orchestrator and Langfuse tracing. His main lesson: treat agents as a platform, not as separate projects.

## Key numbers

- 100%: share of generated SQL that followed the company's SQL guidelines after iterating against reference answers
- 40%: reduction in agent actions, tokens and time after the move to own MCP servers with a cleaner context
- 80%: share of satisfied people in online feedback
- 400 / 70: registered accounts per month and active accounts on the agent platform
- 50 s: 95th-percentile response time, over about 30,000 indexed documents

## What it reports

- Context: AI entered company goals at the start of 2025, both in the product and for internal efficiency. The group has more than 70 analysts. No official Confluence agent existed then; Databricks offerings were platform-bound; vendor agents carried lock-in, cost and data-privacy risks.
- Problems with community MCP servers: configs set the connection but not the behaviour; code was often poor, called the wrong methods and was written in languages the team did not know; no way to add access control or company auth without forking; APIs built for programs returned normalised data that polluted the context; no limit on the number of documents returned; the messenger had no search API, so it needed hacks through personal accounts.
- Rebuild: own MCP servers and indexes, a shared orchestrator codebase (a ReAct state machine in LangGraph), authentication, retrieval and index-update pipelines, a UI, and Langfuse for observability. Own copies of the knowledge bases keep agents available when Confluence is down, which matters to the support team.
- Quality: measured against reference answers for generated SQL and for retrieved documents; after iterating, SQL generation reached 100% compliance with internal guidelines. In Q&A he said these are real queries against production analytical databases.
- A shorter, cleaner context cut actions, tokens and time by 40%.
- Usage: 80% satisfied in feedback; 400 registered accounts a month, 70 active, about six queries each; p95 response time 50 seconds; about 30,000 documents indexed. Remaining dissatisfaction traced to data formats unsuited to agents, errors in the knowledge bases and inaccuracies.
- Examples shown: benefits questions that take load off the HR chat, finding a survey in messenger history, writing a letter in the corporate tone of voice from the editorial policy, and ad hoc SQL analysis in chat.
- Managers now add knowledge sources and chats without engineers. Retrieval is hybrid full-text plus embeddings, since embeddings alone fail on questions such as "which survey did I forget to fill in".
- Security (Q&A): auth and per-user filtering in their own MCP servers, plus masking when a cloud LLM is used.

## How they got it

A practitioner describing his own system. Offline checks used reference answers in a feedback loop; online metrics came from user feedback, system metrics and expert review of dialogues. The size of the reference set, the SQL query mix and the satisfaction survey method are not described.

## Limits

- All figures are self-reported; no evaluation set, baseline or before-and-after numbers for answer quality are given.
- "100%" measures compliance with the company's SQL guidelines; whether the business answers were correct is not reported.
- The headcount figure in the captions is garbled ("около полутора человек"), so company size is not usable.
- Source is YouTube auto-captions: product names are mis-heard (LangGraph as "нграф", Langfuse as "L fuseflow"), and the speaker's surname appears in several spellings.
- 70 active out of 400 registered a month points to modest regular use, which the talk does not discuss.

## Why it matters for companies

Many firms start agent pilots by plugging community MCP servers into Claude or Cursor. This talk lists the failure points that show up once real staff use them: no access control, no limit on returned data, context pollution, and code nobody in-house can maintain. The fix described is ordinary engineering: own thin MCP servers per data source, auth in the server, own indexes, full tracing of tool calls. The platform point holds for any company running more than one agent: shared orchestration, retrieval and observability let new agents ship faster and be debugged when someone asks why the agent answered that way.

## Key passages in translation

> MCP сервера open sourceные - это не всегда prodдакш ready решение.

Open-source MCP servers are not always a production-ready solution.

> Ведь в openсорсных MCP-серверах конфиги предоставляют возможность настроить соединение, но не поведение.

In open-source MCP servers the configs let you set up the connection, but not the behaviour.

> Главный инсайт, который я вынес после нашего опыта работы - это то, что агенты - это не такие точечные проекты, а к ним стоит подходить как к платформе.

The main insight from our experience is that agents are not point projects; they should be approached as a platform.

Original: https://www.youtube.com/watch?v=P-VACeCI3W4&t=3582