Your agent produces a plan. Three actions, in order, each of them sensible. You watch the log scroll past. First action, done. Second action, done. Third action, done. The whole plan executed cleanly, and the result is wrong. Nothing in the plan was a mistake when it was written. The problem is that after the second action the situation had changed, and the third action was still sitting there, still looking valid, still waiting its turn. The plan was fine. What was missing was a moment where something was allowed to stop and look again.

The route is computed once, then driven

Think about the navigation app on your phone. Before you pull away it does the expensive work once. It reads the whole map, the traffic, the closures, and produces a route, then hands you a short list of turns. You do not re-derive the route at every junction. You take the next turn, then the one after, and the app stays quiet, because the thinking already happened.

A planned action queue works this way. An analyzing agent looks at the state of the world and produces a structured plan holding several actions. Then a deterministic runner, ordinary code with no model anywhere in it, drains the queue one action at a time. If the agent proposed three moves, the runner can carry out the first two without a single new call to the model. The runner has no opinion about the turns. It takes them.

What makes the app trustworthy is the other half, the word recalculating. Miss an exit, or meet a road that closed after you started, and the turns still on the list are thrown out on the spot and a new route is computed from where you actually are. The queue needs the same reflex. When an important signal changes, when the score the agent was working toward moves after the second action, the runner discards what is left and asks for a fresh plan against the new state. A route that was right for one map is not automatically right for the next one.

Retry rules decide what you leave alone

This is not tidiness. It is where two real costs get separated. Reasoning is expensive and slow; execution is cheap and repetitive. Draining a queue lets you pay for judgment once and reuse it for several steps, while keeping one clear, named place where the judgment gets re-examined. Drain the whole queue no matter what, and you have saved money by acting on a picture of the world that stopped being true two steps ago.

The second cost shows up when a step fails. Failures are not all alike, and an agent left running alone has to tell them apart. A call that times out is transient, so the task stays retryable up to a limit. A task that has been sitting too long expires, and the honest move is to create a new one rather than resume a corpse. Somewhere in between are the permanent failures, where retrying is just burning money on a guaranteed no.

Explicit lifecycle rules say what happens after a transient failure, how long a result stays retrievable, and when a task counts as finished. Without them, whatever calls the agent will invent its own answers, and the usual invention is retrying forever. Those rules are what you check before you decide to leave a run going overnight.

Everything durable lives outside the model call

Here is the part worth carrying away. Every property in this piece, draining the queue in order, discarding it when the world moves, counting retries, honoring an expiry, is a property of code you write. The model contributes one thing, the plan, and then forgets it existed. It has no queue, no notion of a second attempt, no clock. Ask it whether this task is still retryable and it will produce a plausible answer with nothing behind it.

That is why a plan and a queue are not the same object, even when they contain the same actions. A plan is a list of intentions. A queue has positions, a current item, a reason to be abandoned, and a rule for being finished. The states are what let other software, and other people, look at a running agent and know where it stands. It is the same boundary described in The Loop Is the Product, Not the Model, seen from the side of a single task rather than the whole run.

So write the plan, by all means. Then give it states, or admit that you only wrote a list of good intentions.