When I stop an AI agent and start a new session
Keeping an agent busy is easy. Deciding that it should stop takes more attention.
A session can keep producing plausible changes after the task has drifted. Another edit may address the symptom left by the previous edit. Another explanation may restate the same assumption with more confidence. The conversation gets longer, but my understanding of the problem does not improve.
I have learned to watch for that distinction. The question is whether the next step will give me useful evidence or simply more activity.
A failed attempt can be progress
I do not want an agent to stop whenever something fails. A failed experiment that rules out a cause is useful. So is a test that reveals a dependency I did not know about.
The warning sign is repetition without learning. If a session keeps changing values around the same unexplained failure, I want it to pause and describe the hypothesis, the observation, and why the next experiment will distinguish between possible causes.
That request often exposes the missing information. Perhaps we are looking at the wrong build. Perhaps a preview is using stale data. Perhaps the apparent rendering problem starts in the input state. More implementation is unlikely to help until we know which situation we are in.
Stop when the assignment changes underneath the work
Sometimes the agent is doing a reasonable job on a problem I no longer want solved in that way.
I might discover that a behavior belongs in a shared system rather than a local patch. I might change the product direction after looking at a capture. Two tasks might turn out to depend on the same contract.
Those are reasons to update the assignment explicitly. Otherwise, the agent can continue optimizing against an old definition of success while I assume it has absorbed the new one.
For a small clarification, a message is enough. For a substantial change of scope, I want a short handoff and a fresh brief. The cost of restarting is easier to justify when the alternative is continuing with contradictory instructions.
Preserve decisions, not the whole conversation
Before ending a useful session, I want the information another session would need:
1
2
3
4
5
6
Objective and current state
Files changed and who owns them
Decisions made, with the reason
Experiments that failed and what they ruled out
Checks already passed and their evidence paths
Open risk and the exact next action
The failed experiments are especially valuable. A replacement session that repeats them can look productive while making no progress at all.
I also want the handoff to distinguish a fact from a hypothesis. “The failure appeared after this change” is an observation. “This change caused the failure” still needs evidence. Flattening the two into a confident summary gives the next agent a bad starting point.
This is a small documentation task with a practical return. It protects the useful work from the temporary nature of the conversation.
Limit work in progress to what I can review
Multiple agents create a temptation to start every worthwhile idea at once. My attention does not expand at the same rate.
If several results are waiting for judgment, another implementation session may only increase the queue. I can use that capacity for a bounded investigation or leave it idle while I review. Unused capacity is sometimes cheaper than another unresolved change.
The same applies to model selection and reasoning effort. A task with a known path and a clear acceptance test does not automatically need the most expensive configuration or another reviewer. Difficult design decisions deserve more attention; routine execution should benefit from the decisions already made.
I have built a usage dashboard because limits and long-running sessions affect how I work. Usage helps explain where resources go. It does not, by itself, tell me which session produced the most value.
Stopping is part of directing
There is no universal number of attempts after which a session becomes wasteful. Some problems deserve sustained exploration. I look for a better signal: are the experiments changing what we know, and is the task still aimed at the right result?
When both are true, I want the agent to keep going. When one fails, I want to intervene early enough that the useful work is still easy to recover.
Running agents well includes deciding what to continue, what to reshape, and what to abandon. The tool supplies persistence. I have to supply the judgment about where that persistence belongs.