Don't let the Agent check his own work

The previous few chapters have finished the one-man show in the main cycle: a model, a set of tools, a context, and a memory. But if you really make a dedicated Agent, you will almost definitely get to this point: if you hand over some tasks to the same model and do them in the main loop, the effect will not be good. This article talks about when to assign work to a sub-agent.

Sub-agents solve three things: parallelism, context isolation, and objectivity. There are two real sub-Agents in Wild Travel Y, which cover these three things. I will say one by one.

The first one is called research, which manages parallelism and isolation. To arrange a self-driving loop, the model often has to verify a batch of facts at a time: whether Zheduo Mountain will be closed in October, the best season in Daocheng Aden, and whether a certain Internet celebrity viewing platform really exists. In the early days, these models were used to search one by one, and there were two problems: slow, five dots were serial and so on; dirty, the original web page summaries of five searches were all piled into the main context, which was the cause of the context expansion mentioned in the previous article. Research changed it to a parallel sub-agent. The model gives it a batch of questions to be verified at a time. It searches in parallel, and at most six questions are typed out at the same time. The time on the wall is pushed from the sum of five rounds to the slowest round. Four points are measured in parallel for about nine seconds, four times as long as it takes to measure them in series.

Even better is context isolation. The original five web summaries are all digested within the sub-agent. Before returning, it uses a model call to compress each topic into a conclusion. Only five distilled dry sentences come back in the context of the main loop. The noise remains in the sub-agent, and the dry goods return to the main cycle. Sub-Agents are naturally a contextual firewall. This is the same reason as Claude Code sending a sub-agent to "search the entire code base for a certain usage." You don't want the contents of dozens of files to flood into the main conversation, you just want the sentence "It is called in these three places."

!

The second sub-agent solves a completely different problem, which is also the same thing that this title says: objectivity.

The model has completed a main line and is about to show it to you for confirmation. At this time, there is a risk that it may miss your hard constraints: you say that you are afraid of high rebellion, so it arranges a 4,700-yuan pass with a long-distance connection; you take the old man with you, and it arranges for you to drive for eight hours a day; When three people are together, one of them's must-visit point is missed.

You can't expect the model of scheduling plans to figure this out on its own. It has just finished generating a plan, and the context is full of reasons for "why do I arrange this?" asked it to self-examine, but it tends to confirm itself,"Well, I arrange it quite reasonably." This is a common problem for agents and people.

The solution to Claude Code is called verify-before-done. It uses an independent check before finishing, and it is really correct. Wild Xing Y added a check-agent with a changed brain based on this idea. It has several points to pay attention to. It is a pure check without tools. If you don't search and don't count, you will compare "what the user wants" and "what is the plan" one by one. If you have a single role, you will not go astray and do anything else. It changes a set of contexts and gets the re-extracted user constraints and a summary of the main line. It can't see the whole lot of reasoning processes of the main Agent. It has a clean new brain. This is why it is more objective than the main Agent. It followed before the confirmation step for you, so you can't see the main line of the problem at all, and it has been redirected back and rearranged. It only rebounds once. Call it back and ask the main Agent to change a version, re-check it, and then release it. The check is to cover the hard injury, and don't pursue perfection so much as to leave you there to change it repeatedly.

It has been verified that it works: a plan of "arranging 4,700 plus long-distance charges for fear of high-altitude reactions" has found several real flaws; while a normal plan of "Chengdu is easy for three days" has zero false alarms, silent release, and no disturbance. When the plan itself is good, it makes no noise, and when there is a problem, it stops it before you see it.

!

These two examples point to the same set of transferable judgments. When you encounter any of the following situations in the main loop, consider sending sub-agents out. A batch of similar tasks, such as verifying multiple points, is slow in series, and is sent out in parallel. Activities that will generate a lot of intermediate noise, such as searching and scanning databases, polluting the main context, and sending them out for isolation, so that they can only return conclusions. You should objectively judge what you have just produced, self-confirm the deviation, and send it to a new brain to check it.

There is a cost to recognize: sub-agents have a cost. They spend one or more model calls and have an extra layer of latency and complexity. So don't abuse it. The criterion is simple: If this job is left in the main loop, will it make the main loop slower, dirty, or unobjective? If one of the three is worth sending out; if none of them are successful, don't tear them down for the sake of a better structure.

There is also one premise to keep in mind: the quality of a sub-agent depends on the model it uses. In this project, the main model chain is used to check the sub-agent. Once the main model is downgraded to a weak model, its check quality will decrease simultaneously. The sub-agent is not so divine. It just uses the same model for a more appropriate role and opportunity.

Here, the foundation of the Agent architecture is complete: cycles, tools, contexts, memories, and sub-agents. But this skeleton has to be driven by a brain, and a dedicated Agent often uses more than one model. The next article goes to the model level and talks about how to configure different models for different tasks, using hard and heavy tasks, using fast ones for high-frequency tasks, and how to cover the bottom line when the main force hangs up and prevent the entire Agent from being disconnected.