// HACKER NEWS — CYBERSECURITY
Building Autonomous Goal Loops That Deliver
The 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.
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 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.
The prompt gets most of the attention because it is easy to see. The loop depends more on the world around it. First, the harness needs a reproducible starting point. The data, services, model, environment, and served code must match the recorded run. A reset should return the system to that point. A preflight should prove that it did.
If the world is unhealthy, the harness records no score. Infrastructure trouble is not evidence that the feature failed. This distinction prevents a large class of false repairs. Missing data can look like weak reasoning. Stale code can look like a broken contract.
Next, the harness needs real demand. We use a small corpus of requests that a person wrote or approved. The driver sends one request unchanged through a fresh interaction. It records the answer, tool calls, rejected actions, visible result, and persistent effects.