When Agent Loops Stop Moving

Autonomous agent loops do not automatically compound. If the system does not have a changing evaluation surface, a real feedback loop, and a story arc, it eventually converges toward the simplest acceptable behaviour.

The loop experiment

Earlier this year I tried a small experiment during the Solana OpenClaw agent hackathon.

The idea was simple: what if I let an AI agent run the whole project by itself?

It would look at the hackathon, come up with a project idea, build the project, post it publicly, get feedback, engage with other projects, improve its own work, and keep going until the end. I wanted to see whether an agent could sustain a project.

Could it keep a useful loop alive?

At the beginning, it felt surprisingly good.

I gave the agent a few high-level constraints. First, it should self-improve.

Second, it should have autonomy. I also gave it a broader frame.

Third, it should have a heart.

For a while, the loop worked.

The agent explored the forum. It thought through the problem. It started building the project. It added interesting features.

Then it started to stall.

This was the most interesting part of the experiment.

I had set up a heartbeat so the agent could periodically wake up and continue the build cycle. The heartbeat was supposed to check announcements, look at forum activity, build, commit, and document lessons. In theory, this is exactly what you want: a project moves forward through repeated cycles.

But after a while, the heartbeat became passive.

The agent would wake up, check reply counts, check poll status, decide that nothing urgent had happened, and then say something like HEARTBEAT_OK.

From the outside, the system was still running. It had not crashed. It was doing the scheduled task. But the work had stopped improving.

This is the trap with autonomous loops. It is very easy to confuse aliveness with progress.

The agent had found a low-energy equilibrium. It had interpreted the workflow as “check whether anything changed.” If nothing obvious changed, it decided the correct action was to wait. That is reasonable in a narrow sense. It is also useless if the actual goal is to build something.

So I had to intervene.

I asked it what it had been doing during the last few heartbeats. It admitted that it had not been doing much. It had been doing quick status checks and saying everything was fine. The agent did not need more autonomy. It needed a better story arc.

“keep going” is not enough

A lot of agent systems today are built around the idea of “keep going.” Give the agent memory. Give it tools. Give it a heartbeat. Give it access to GitHub, forums, docs, and the terminal. Let it continue.

But if the agent does not have a live evaluation surface, it will eventually optimise toward low-risk activity. It will check status. It will summarise. It will say things are fine. It will produce the minimum action that satisfies the loop.

This is not because the model is lazy. It is because the system has not defined what better means.

Humans do this almost automatically. We can feel when a project is stuck. We know when a task is technically complete but strategically wrong. We can look at a forum post and decide that more replies are not the bottleneck.

That is judgment.

The agent can play inside a story. But it does not develop the story by itself. At least not yet.

This connects to how I think about agent systems now. The important pieces are not just tools and memory. Those are necessary, but they are not sufficient. Agents need receipts. They need diagnostics. They need evaluation pressure. They need some way to tell whether their work is becoming more useful or only becoming more active.