Wildberries explains how to train AI agents with reflection, interviews and a God-agent

Wildberries & Russ has published a practical guide to working with AI agents in software development. It is not about a new model, but about how to get more predictable results from already available LLMs through better organization of context and processes.

Context in pieces

The article's main point is simple: an agent suffers not only from too little data, but also from too much. If you dump the project description, architecture rules, run commands and the details of a specific task into one prompt, the model starts to lose focus. The author therefore suggests splitting knowledge into small Markdown files and loading them as needed. This approach has already become standard in many AI clients and lets the agent read not "the whole book at once" but only the relevant chapter.

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

• a root project file such as AGENTS.MD or CLAUDE.MD with general rules
• separate files for specialized agents and subagents
• skills with short instructions for specific types of tasks
• commands with prompt templates for repeatable workflows

The author also advises moving task progress into a todo file. This frees the model from having to keep progress "in its head" and lets you return to a long task in a new session without losing state. It is especially useful when work involves many steps, such as covering a module with tests, migrating code, or editing several components in sequence.

How to cut the noise

The second big problem is the context window filling up with housekeeping information. An autonomous agent constantly opens files, runs builds, reads logs and runs tests. Each such operation adds tokens, and when the loop repeats many times, important instructions drown in technical noise. The article gives an example in which a single test run produces about 500 tokens of output: not much on its own, but across a series of autonomous steps it quickly becomes dead weight.

To keep answer quality up, the author proposes several practical measures. First, filter terminal output and pass the model only meaningful errors and signals, without the filler of standard logs. Second, index the project so the agent finds the right files faster and wanders the repository less. Third, periodically compress the session context if the client supports it. There is a caveat, though: excessive compression can discard details that are later needed for a correct solution.

Interview and reflection

One of the most useful techniques in the article is to make the agent clarify the task first and only then write code. The logic is blunt: if the model lacks context, it starts filling it in on its own, and the result easily drifts from what the user actually wanted.

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

So before executing a task, it is better to give the agent a separate skill for a short interview: asking a few questions about requirements, constraints and the expected result. The author stresses that wording is critical here. If you write "ask three questions", the agent will dutifully ask exactly three, even pointless ones. It is better to set a range and a skip condition: for example, two to six questions, and no interview when the context is obvious. A side effect of this mode is that the model's questions sometimes expose gaps in the spec itself.

After the task is done, the author suggests another loop: reflection. The agent is asked what it would do differently if it ran the task again and where exactly it went wrong. The article includes a telling case: the model wrote tests for only one of three methods and simply removed the rest, because its goal was a "passing test". Such post-mortems give rise to the next idea, the God-agent, a separate agent that maintains the whole system. It updates the configs, skills and instructions of other agents based on the reflection, turning one-off mistakes into process improvements.

What this means

The Wildberries piece shows a market shift well: value now lies not only in choosing a model but in how the layer around it is built. The winner is not whoever has the "smartest" agent, but whoever can dose context, keep working memory outside the chat, make the system ask questions and learn from its own failures. For development teams this is no longer theory but a fully practical way to make AI tools more stable and cheaper in daily work.