---
id: "lib-2026-11-06-knowledge-base-at-full-stretch-how-ai-agents"
type: "library"
title: "Knowledge base at full stretch: how AI agents working with QA fill a shared testing memory (База знаний на максималках: как ИИ-агенты с помощью QA сами наполняют общую память тестирования)"
lang: "RU"
org: "VkusVill-TechVill"
source_type: "Practitioner post"
date: "2026-11-06"
week: "2026-W45"
url: "https://nosov.ai/library/lib-2026-11-06-knowledge-base-at-full-stretch-how-ai-agents/"
original_url: "https://habr.com/ru/companies/vkusvill/articles/1104486/"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "TechVill (VkusVill) testing-stack lead describes in detail how QA agents read from and write to a shared RAG knowledge base; concrete design and rules, but the only outcome figures are examples and an unmeasured time claim."
summary_basis: "full-text"
original_minutes: "14"
tags: ["ai technology", "enablement", "qa agents", "rag knowledge base via mcp", "retail it", "agent memory"]
frames: ["tacit-to-explicit"]
---

# Knowledge base at full stretch: how AI agents working with QA fill a shared testing memory (База знаний на максималках: как ИИ-агенты с помощью QA сами наполняют общую память тестирования)

Tier B (Useful, limited): TechVill (VkusVill) testing-stack lead describes in detail how QA agents read from and write to a shared RAG knowledge base; concrete design and rules, but the only outcome figures are examples and an unmeasured time claim.

Summary based on the full text.

## In short

A Habr post (6 November 2026) by Oleg Malyshev, a testing-stack lead at TechVill, the tech arm of Russian grocery chain VkusVill. QA engineers work with agents in Cursor and Claude Code through a shared QA kit, and the kit is now wired to MKP, an internal RAG knowledge-base platform. Before a test plan the agent must search the team's past results and knowledge; after testing it writes the full plan, result, a daily log and any new verified fact back into the base. The aim: the next tester, human or agent, does not repeat a two-hour investigation.

## Key numbers

- 4: knowledge bases per domain: wiki, outputs, daily, artifacts
- 4: mandatory lookups the agent runs before showing a test plan
- 5: tools in the platform's MCP server (list, query, get, upsert, soft delete)
- 10 minutes vs 2 hours: time to work through the empty-shelf checklist versus the original investigation, as claimed
- 2-3 hours: time to connect a new team to the QA kit, without programming

## What it reports

- MKP has a built-in copy of the corporate wiki (read-only, refreshed daily) and any number of team Markdown bases; access through a web UI, REST API and an MCP server, all under the same per-person permissions.
- Search: hybrid dense and sparse retrieval (to keep identifiers such as GetExists or ticket keys), multi-query, reranking, parent-child retrieval; every answer returns sources with scores and a trace ID.
- Each domain (catalogue, search, recommendations, BFF, stock) has four bases: wiki (stable knowledge), outputs (full test plans, results, tracker comments), daily (what was tested, with an index), artifacts (raw curl, SQL, JSON, mocks). A git registry sets who reads and writes what.
- Before testing: exact lookup of a previous plan and result, a semantic search of outputs, the team wiki and the product wiki.
- Rules: secrets replaced by placeholders; logs and raw JSON kept out of search; results stored in full; wiki holds only facts a QA engineer has confirmed; extend existing articles instead of creating new ones; agents never read other domains' bases.
- Example answers took about 24-26 s; one past-results answer listed 12 checks designed, 9 executed, 8 passed, 0 defects.
- Tools emit lifecycle events (workflow start and end, skill used, blocker found, knowledge written) without conversation text or request bodies, to show usage and time per task.
- Catalogue and product card teams run fully on this; others are being connected.

## How they got it

A practitioner description of an internal system with real query examples and screenshots. No before-and-after measurement of test time or defect leakage is given.

## Limits

- The "ten minutes instead of two hours" figure is a single illustrative case, not measured across tasks.
- No data on base quality over time; a deduplicating "librarian" agent is still planned.
- Platform details beyond the QA use are not described.

## Why it matters for companies

Most internal wikis die because nobody writes them. Here the agent writes as a side effect of normal work, under rules that stop the base filling with chat transcripts or unverified conclusions, and with per-team permissions so one team's quirks do not mislead another's agent. The pattern transfers to support, operations or any function where tacit "how we check this" knowledge lives in chats. The open question is upkeep: who prunes the base once it grows.

## Key passages in translation

> знания в базу пишет ИИ-агент, в ходе обычной работы QA.

The AI agent writes knowledge into the base in the course of normal QA work.

> Агент не переносит в базу диалог: он работает как редактор, отбирает из сессии проверенное знание и раскладывает его по документам.

The agent does not copy the dialogue into the base: it works as an editor, selecting verified knowledge from the session and filing it into documents.

> Сначала вывод подтверждает QA, и только потом он попадает в базу.

First a QA engineer confirms the conclusion, and only then does it go into the base.

Original: https://habr.com/ru/companies/vkusvill/articles/1104486/