How QA agents build their own knowledge base and cut root-cause analysis from 2 hours to 10 minutes

Imagine a QA engineer spending two hours figuring out why a self-pickup product listing is empty. It turns out not to be a bug. The availability cache is refreshed every few minutes, while an inventory mock was overriding the live proxy because of an incorrect priority. The lesson is learned, but it remains in one person's head or in a chat that no one will find a week later. A month later, another QA engineer spends the same two hours on the same issue. An AI agent has no memory between sessions at all, so it retraces this path every time.

Techville's testing team addressed this with a dedicated platform called MKP, or Multi Knowledge Platform. Below, we examine how it works and what other teams can take from it.

What MKP is and how it searches

MKP is an internal platform with knowledge bases and intelligent search. It supports two types of databases: the built-in evawiki containing corporate documentation, which MKP can only read, and team-owned Markdown databases where documents can be created, updated, deleted, and searched semantically. Users can work through a web interface, a REST API, or an MCP server for agents in Cursor, Claude Code, and Codex. MCP exposes just five tools: list databases, run a semantic query, retrieve a document by number, create or update a document, and perform a soft delete.

Under the hood is RAG, but not its most naive implementation. Hybrid dense/sparse retrieval combines semantic search with keyword search. This is critical for QA: pure vector search tends to lose identifiers such as GetExists, is_pickup, or CMA-14699. The pipeline then applies multi-query expansion, in which a model reformulates the question, reranking, and parent-child retrieval: it searches small fragments but returns the context of the entire section. Every response includes text, sources with scores and snippets, and a trace_id for diagnostics.

The agent writes to the database itself

The central idea is that nobody adds documents manually; otherwise, six months later, the result would be yet another abandoned wiki. Instead, MKP is integrated into the QA kit, a repository containing rules and skills for Cursor and Claude Code. The agent acts as an editor: it selects verified knowledge from the session rather than dumping the entire conversation into the database.

Each domain, such as catalog, search, or recommendations, has four databases:

• wiki — durable knowledge: architecture, environments, mocks, and guidance on how to test correctly;
• outputs — full test plans, results, and comments for Tracker;
• daily — daily entries and an index table of contents;
• artifacts — raw evidence: curl, SQL, JSON, and mocks.

Before presenting a test plan, the agent must run four searches: whether there was a retest for the exact document numbers, what similar cases uncovered in outputs, what the team knows about the service in wiki, and what the product documentation says in eva-wiki. After testing, it records the plan, result, and comment in outputs, the day's activity in daily, and any new durable fact in wiki.

What this delivers in practice

For an empty product listing, a query to catalog-wiki now returns a nine-item checklist in 24 seconds. It covers the availability cache, preorders, mock priority in WireMock, and a 403 response from the search proxy. A QA engineer completes it in ten minutes instead of two hours. No one wrote this checklist as a standalone article: it was assembled from task investigations to which the agent added facts one by one.

For a product-alternatives task, the agent retrieves the results of two previous test runs in advance. A new QA engineer knows which fixtures to prepare, avoids filing a false DEFECT for an unreachable legacy path that a colleague has already labeled QUESTION, and immediately adds a check for old unfiltered code in the environment. By looking at the daily index, the lead can see what the team has done without holding a separate status meeting.

Permissions and discipline

Access is tightly controlled. There are two roles, admin and user, while read and write permissions are granted separately for each database. Every agent gets a separate least-privilege user account, and a technical user can be denied access to the UI. An agent can read its domain's databases and eva-wiki but can write only to its own four databases. The document author is identified by the API key, and the team appears in the metadata. The access registry is stored in git.

Limitations and conclusion

The article does not evaluate the quality of the entries or explain how incorrect knowledge written to the wiki by an agent is filtered out. The reported time savings are internal figures based on individual examples. A new document is also not immediately searchable: it first passes through the processing status.

The practical conclusion for teams working with agents is that they do not need another wiki; they need a "recall, work, record" cycle. The minimum setup is to separate durable knowledge from test-run results, require the agent to search before starting work, give it narrowly scoped permissions, and store sources alongside answers. Then every task makes the next one cheaper.