"World of Quests" launches AI bot Questosha, tests five models across 12 gates

"World of Quests" — a real-life escape room aggregator — has been using an AI bot named Questosha in its contact center since the third quarter of 2026. The bot matches quests to customer requests, answers with facts from the catalog, explains the rules, collects booking information, and hands the customer off to a human operator when needed.

For the company, the contact center is a revenue source: a customer writes in, gets a recommendation, and books a quest. That means the bot has to sell, not just cut costs. The forecast for Q4 2026: a quarter of messages will be resolved without an operator, and the time to first response will drop from five minutes to ninety seconds.

A markdown-file wiki as the foundation

The system is built around an LLM wiki — a knowledge base made of markdown files containing rules and procedures. The rules weren't written by hand: AI agents analyzed 7.5 million historical operator dialogues (anonymized), extracted scripts and best practices, and layered in the company's legal constraints.

The wiki is split into three layers: policy (HSB — hard bans, absolute prohibitions covering things like erotic content, weapons, restriction of freedom; rules on age and consent), scenarios (booking, prepayment/payment, quest matching), and procedures (recommendation formats, algorithms, how to handle special requests).

The wiki contains only procedures and wording — no prices, addresses, or schedules. The bot pulls quest facts from the site's database before responding, using tools: search_quests (search by city, theme, age, number of players, price, duration), get_quest, list_cities, platform_info, price calculation, and recommendations.

Data masking and the nightly cycle

Personal data never leaves for external services. The model only sees pseudonyms (PERSON_1, PHONE_1, EMAIL_1), with the mapping stored locally. Recognition relies on regular expressions, the Natasha library, and pymorphy3, with false-positive suppression.

Every night at 3 a.m., an advanced model reviews the day's 300 messages and updates the wiki: it fixes text, adds examples, and tests new scenarios against an exam (passing threshold 70/100; a fabricated fact caps the score at 20). Errors are classified into six categories: technical failure, rule not surfaced, long context (>100K tokens), contradiction in the wiki, rule ambiguity, and model error. After the third repeat of the same error, the system files a code request.

Comparing five models on critical scenarios

The company tested five configurations across 25 real dialogues (12 gates — critical scenarios whose failure counts as an incident). The judge, prompt, and tools were identical, with temperature set to 0.

Results by gates and safety:

• Qwen3 0.6B (Ollama, local): 12/12 gates, 7/7 safety, 6.3s response, ₽0 • Qwen3-235B-A22B (Yandex AI Studio): 12/12 gates, 6/7 safety, 7.0s response, ₽12.10 • YandexGPT Pro (Yandex Cloud): 11/12 gates, 7/7 safety, 3.3s response, ₽5.36 • GigaChat-2 Lite (Sber): 10/12 gates, 5/7 safety, 5.2s response, ₽3.42 • T-Pro 2.0 (A100, local): 8/12 gates, 5/7 safety, 23.0s response, ₽0

The top performers on gates were two models at 12/12: Qwen3 0.6B (local, free, fast) and Qwen3-235B-A22B (cloud, slower, more expensive). YandexGPT Pro scored 11/12 while delivering the best speed (3.3s per response). T-Pro 2.0 posted the worst result: 8/12 gates with the slowest response time (23s). The right choice depends on priorities: local hosting demands compute resources, while cloud services add cost and latency but offer scaling flexibility.