Mir Kvestov Launches AI Bot Kvestosh and Tests Five Models Against 12 Gates

Mir Kvestov, an aggregator of real-life quests, has put the Kvestosh bot on the first line of its chat since the third quarter of 2026. Customers write in to pick a game and book it, and now an AI answers them first. The team published an architecture breakdown on Habr. It covers a wiki of markdown files instead of fine-tuning, personal data masking before the model, access to the site catalog via MCP, and a comparison of five models across twelve safety gates.

Knowledge lives in files, not in weights

The team's main decision was not to fine-tune a model but to keep the knowledge base as a wiki of markdown files. This approach has practical consequences. The files are human-readable and versioned, and they can be edited by people other than an ML engineer. The knowledge is not tied to a specific model. If a stronger or cheaper LLM appears, the wiki stays the same. For a project that compares five models at once, this matters a great deal.

Another element of the system is a nightly editing cycle with an exam. Judging by the description, the knowledge base does not just sit still. It is reviewed and extended regularly, and the result is checked with a test. The author left the details of the mechanics for the full article. But the idea is clear: changes to the source of knowledge should be verified the same way changes to code are.

Privacy and catalog freshness

Customers' personal data is masked before a request reaches the model. This is protection at the architecture level, not a request to the LLM to "not disclose too much." A booking chat inevitably collects contact details, so the question of what an external model sees comes first here.

Facts about the product come through a different channel. The site catalog is connected via MCP, so the bot queries it as a tool. The wiki holds rules, tone and typical scenarios; the catalog holds the current games. The split makes sense: schedules and slot availability change faster than any wiki can be updated.

Five models, twelve gates

Before launch, the team compared five models across twelve safety gates. A gate here is essentially a mandatory check: a model that fails it does not make it onto the first line. The announcement does not say which models took part or how they ranked. That data will be the main value of the full version.

What is known from the announcement:

• launch: third quarter of 2026, the bot answers first in the chat;
• knowledge: a wiki of markdown files, no fine-tuning;
• customer data: masked before the model is called;
• integration: the site catalog via MCP;
• maintenance: a nightly editing cycle with an exam;
• model choice: 5 candidates, 12 safety gates.

The second part of the write-up is not about code but about organization. It includes a stakeholder map, the expectations of adjacent teams and five lessons for a team lead. For customer-service deployments, this is often more important than the choice of model, because a bot affects support, product, legal and operators at the same time.

What to take into your own project

The Mir Kvestov approach is easy to carry over. Start with a knowledge base in markdown: it can be versioned and shown to colleagues in support. Connect live data through tools rather than copying it into the prompt. Mask personal data before calling the model. Choose models by safety gates defined in advance, not by the impression a demo makes. And draw the stakeholder map early: by launch, a bot on the first line will have more interested parties than any feature on the site.