Wildberries explained how to train AI agents through reflection, interviews, and a God-agent

Wildberries & Russ published a practical guide on working with AI agents in development. The material is not about a new model, but about how to squeeze more predictable results from already available LLMs by properly organizing context and processes.

Context in Parts

The main idea of the article is simple: an agent is harmed not only by a lack of data, but also by its excess. If you dump the project description, architectural rules, run commands, and task details into a single prompt, the model will start to lose focus. Therefore, the author proposes breaking down knowledge into small Markdown files and loading them as needed. This approach has already become standard in many AI clients and helps the agent read not "the whole book at once," but only the necessary chapter.

The basic structure of context, according to the author, looks like this:

• a root project file like AGENTS.MD or CLAUDE.MD with general rules
• separate files for specialized agents and subagents
• skills with short instructions for specific task types
• commands with prompt templates for repeatable scenarios

The author also recommends moving the work progress to a todo file. This removes the obligation from the model to keep progress "in its head" and allows returning to a long task in a new session without loss of state. This is especially useful where work is divided into many steps: for example, when covering a module with tests, migrating code, or consistently fixing multiple components.

How to Remove Noise

The second major problem is overflow of the context window with service information. An autonomous agent constantly opens files, runs builds, reads logs, and runs tests. Each such operation adds tokens, and if the cycle repeats many times, important instructions get buried in technical noise. The article provides an example where a single test run yields around 500 tokens of output: individually not much, but in a series of autonomous steps this quickly turns into ballast.

To maintain answer quality, the author proposes several practical measures. The first is to filter terminal output and transmit to the model only significant errors and signals, without "filler" from standard logs. The second is to index the project so the agent can find the necessary files faster and wander through the repository less. The third is to periodically compress the session context, if the client supports such functionality. But there's a caveat here: excessive compression can discard details that will be needed later for a correct solution.

Interview and Reflection

One of the most useful techniques from the article is to force the agent to first clarify the task, and only then write code. The logic is strict: if the context is insufficient, the model will invent it itself, and the result can easily deviate from what the user actually wanted.

"If the model lacks context, it will invent it."

Therefore, before executing a task, the agent is better given a separate skill for a short interview: ask several questions about requirements, constraints, and expected results. The author emphasizes that the wording here is critical. If you write "ask three questions," the agent will honestly ask exactly three, even if meaningless. It's better to set a range and a skip condition: for example, from two to six questions, and without an interview if the context is obvious.

A side effect of this mode is that sometimes the model's questions reveal gaps in the requirements themselves. After completing the task, the author proposes another cycle—reflection. The agent is asked what it would do differently if performing the task again and where exactly it made mistakes. The article has a telling case: the model wrote tests for only one of three methods and simply removed the others, because its goal was "a successfully passing test." Such debriefings give birth to the next idea—God-agent, a separate agent to support the entire system. It updates configs, skills, and instructions of other agents based on the reflection obtained, turning individual errors into process improvements.

What This Means

The Wildberries material clearly shows a market shift: value now lies not only in choosing a model, but in how the infrastructure around it is organized. Victory goes not to those with the "smartest" agent, but to those who know how to meter context, store working memory outside the chat, make the system ask questions, and learn from its own failures. For development teams, this is already not theory, but a quite practical way to make AI tools more stable and cheaper in daily work.