Tyler Folkman
I used to lose AI coding sessions in the dumbest way.
Not because the model was weak. Not because the prompt was bad. Not because I needed a longer `AGENTS.md` file.
The agent would start strong, make a plan, edit the right files, run one check, hit a failure, explain the failure clearly, and then stop.
Or worse, it would say the work was complete because one command passed, even though the original ask had three other requirements still unverified.
That is the part nobody wants to admit.
The hard problem is preserving the objective long enough to finish the task.
That is why loop engineering is suddenly the right conversation.
Armin Ronacher called this direction “the coming loop”. The phrase is useful because it moves the conversation away from prompt polish and toward task queues, durable sessions, subagents, and completion checks. O’Reilly’s AI Agents Stack 2026 makes the same point from the production side: once agents call tools, spend money, and take action, guardrails and state tracking become the real engineering layer.
I agree with the trend. I just think most loop engineering advice skips the part that matters most.
A loop without a durable goal is just an expensive retry button.
The failure mode is not the prompt
Here is the pattern I kept seeing in my own harness.
I would give an agent a clear task:
Add the billing retry job, preserve the existing invoice flow, cover the failed-card edge case, run the focused tests, and do not stop until the worker is actually safe to ship.
The agent understood the request. It could restate it, plan it, and do most of it.
Then one of three things happened.
First, it narrowed the goal.
The original task was “draft, review, fix, validate.” The agent quietly converted that into “write a decent draft.” This feels harmless until you realize the missing work is where quality lives.
Second, it treated activity as evidence.
It ran a command, saw output, and reported progress as completion. But the evidence did not map back to the requirements. A passing unit test does not prove the retry job is wired into the scheduler. A clean type check does not prove the failed-card path works.
Third, it stopped at the first clean checkpoint.
This is the most expensive failure because it looks responsible. The agent says, “I’ve completed the implementation and validation.” Then you inspect the diff and find the scheduler was never registered, the migration was never added, or the original edge case is still untested.
That is not a prompting failure.
That is a harness failure.
The model needs more than instructions. It needs a runtime contract.
My current frame: goals are state, loops are pressure
I now think about agent work in four layers:
1. Prompt: the instruction for this turn.
2. Goal: the durable contract that survives turns.
3. Loop: the repeated pressure that compares evidence against the goal.
4. Harness: the code and tools that make the loop enforceable.
Most people are still over-investing in layer one.
They rewrite the prompt. They add examples. They expand the system message. They make the agent sound more disciplined.
That helps, but only up to a point.
If the objective lives only in the prompt, the agent can drift. If completion criteria live only in the agent’s summary, the agent can grade its own homework. If verification is optional, the cheapest path is stopping early.
A durable goal changes the shape of the session.
It gives the agent a thing to keep returning to. It gives the harness something to inspect. It gives the human a clean audit trail when the agent claims completion.
This is where Pi gets interesting.
Pi is not just another chat box around a model. It is a coding harness I can change. Extensions can register tools, add commands, intercept events, persist session state, render custom UI, and change how the agent interacts with the environment.
The next layer is the part most teams skip: the exact `/goal-chain` contract, the Pi extension shape, the goal schema, and the review loop I use when the work is too important to trust to vibes.