After the Agent takes over the task, the first thing to tighten is the work unit.

I have been reading a lot of discussions about Agent recently, and in the end I always come back to the same question: Who should give a piece of work to, how should it be packaged before handing it over, and how will it be accepted after it is returned. Once this problem occurs in a project, the first thing that increases is often not the cost of the model, but the complexity of the work unit. If the task is cut too big, the model will appear “as if it can be done”; the real problems usually lie in rollback, reproduction and acceptance.

The work unit must first be able to be accepted

In the past few days, after stringing together Martin Fowler’s fragmented notes and several discussions at the Thoughtworks Future of Software Development Retreat, the most obvious feeling is that the conversation in the meeting was superficially scattered, but underneath it actually revolved around only one thing - handing over a large piece of work to Agent.

Kief Morris’s finishing is the most straightforward. Different sessions discussed code review, production accidents, team division of labor, and model routing. They seemed to be talking about different things, but the conclusion turned out to be the same: people have been adjusting the size of “unit work”. The bigger the unit is, the easier it will be to hand it over; the bigger the unit is, the harder it will be to accept it after it comes back. It’s not that the model can’t do it, it’s that the subsequent confirmation link cannot hold up first.

This is why harness is mentioned again and again. Context management, computational sensors, property-based testing, formal methods, these things sound like additional tools, but they actually collect work units. Some people control agents.md to less than 200 lines, not to pursue neatness in form, but to force the system to only receive that part of the information that is really useful and can really be checked. The context is too loose, of course the Agent can run; but after running, no one knows which layer of constraints it swallowed.

Self-hosting brings the control surface up

Discussions of self-hosted models also point to the same thing. After tokens become more expensive, compliance requirements become stricter, and data cannot be leaked out, open source models and local models will naturally become more attractive. But once you carry the model yourself, you also have troubles: GPU, inference room, routing, rollback, fine-tuning, and model selection. These are not the model capabilities themselves, but they will determine whether the system is ultimately stable.

Such costs are often underestimated. Many teams initially focused on “whether the model is stronger”, but later discovered that what really consumes time is the stable transfer of work units between multiple models. When to use a large model, when to use a light model, and when to simply use a local model, it depends not on verbal preference, but on a layer of control surface that can be used for diversion and cover-up. Without this layer of things, self-hosting will slip from “taking the initiative” to “taking over the operation and maintenance complexity yourself.”

Simon Willison mentioned letting stronger models choose smaller models to do the work. This idea is also very similar to what the control plane is doing. The model itself doesn’t necessarily know the team’s cost boundaries, but the system does. Treating the model as a broker and using it to allocate tasks is closer to real delivery than blindly pursuing a single model for all-inclusive delivery.

Acceptance and goals cannot be outsourced

Sam Ruby’s “Bring me a Rock” brought another issue to light. Giving the work to the model is equivalent to adding an executor; the responsibility does not disappear. Managers can use LLM for exploration, and they can let it spit out a bunch of candidate solutions first, but the final acceptance criteria still have to fall into human hands. Hidden goals are the most troublesome. Permissions, privacy, destructive actions, and context leakage are often not included in the original requirements.

So conformance tests are often more useful than specifications. Specifications are good at describing “what is required”, and tests are better at exposing “what cannot happen”. This is especially true in Agent systems. The model can make up for the explicit goals very well, but the implicit boundaries need to be verified through harder verification. As long as the acceptance conditions remain in vague descriptions, the more the Agent does, the more the system will look like it is betting on probability.

Therefore, code review, incident handling, and task assignment, which used to be very human-like tasks, are now beginning to take other forms. Managers use the model directly. On the surface, it seems to be improving efficiency, but at the bottom level, they are actually changing a management method: from managing methods to managing goals. If the goal is clearly written, the model will have a chance to work; if the goal is unclear, the model will only amplify the ambiguity for others.

Experience and reading skills are still improving

The interactional expertise and contributory expertise mentioned by Dan Davies are also very relevant to this change. The model can read a lot of materials and make a decent judgment, but for the system to be stable, there still needs to be someone who can read the specifications, see the results, and know what is wrong. The key here is not that people should compete with the model to see who is smarter, but that people should continue to stand in a position that defines the boundaries.

This matter is more straightforward when it comes to software delivery. After Agent takes over, human work will fall less on manual execution and more on task segmentation, boundary definition, acceptance design, and exception handling. Whether tasks can be handed over clearly determines whether the subsequent context management, model routing and tool orchestration are worth doing. If the unit is not clear, no matter how many layers there are, it will only push the problem back.

After reading these fragments in the past few days, what remains in my mind is not a certain model name, nor a new framework, but a simpler judgment: the first thing the Agent system needs to tighten is not the model capability, but the work unit. If the unit is smaller, the acceptance is stricter, and the permissions are tighter, the system will have the opportunity to keep the complexity within a controllable range.