GoKawiilThe first agent loops we built were barely loops: give the agent a plan, let it work until the tests pass, and return failures. That works when the tests describe the job. It fails when the job is to grow a product capability that we do not understand yet.
The agent keeps moving, but movement is not the problem. The tests only protect what we already know, and the important failures sit outside them. A screen can look complete while it stores nothing. An agent can give the right answer for the wrong reason. A scorer can reward behavior no user wants. More turns make each of those failures cheaper and faster.
In The Convergence Problem I argued that agents can own turns while people own rounds. I did not describe what the agent needs between those boundaries. It needs a harness that does three things. The harness must expose a real failure, locate the missing capability, and preserve the lesson after the session ends. That is a different machine from an agent with a retry prompt.
There are two systems under development
The obvious system is the feature. The less obvious one is the process that decides what the agent should change next. We have to engineer both.
The harness improves the feature without leaking development context into the test DEVELOPMENT HARNESS HUMAN BOUNDARY goal · authority · protected measure LOOP CONTROLLER chooses the next gap DEVELOPMENT AGENT code + expected result REPOSITORY STATE memory between sessions FEATURE UNDER DEVELOPMENT PRODUCT AGENT fresh context PRODUCT SURFACE tools · UI · API STATE + EFFECTS BEHAVIOR DRIVER sends a real request SCORER evidence + gap class protects The harness knows how the feature should work. The product agent receives only what a user would receive.
The development agent changes the feature. The driver approaches the feature through the same surface a user would. The scorer reads what happened. The controller then chooses the next gap from that evidence. Repository state carries the decision into the next session.
An agent product usually puts another agent inside the feature. The two agents must remain separate. The development agent knows the code and the expected result. The product agent gets a fresh conversation and only the tools that the product exposes.
If they share context, the test is worthless. The product agent can succeed with knowledge that a user will never provide. The same harness works without a product agent. The driver can use a browser, API, command, or hardware simulator.
Everything important sits outside the prompt
... continue reading