A coding agent finishes a chunk of work, writes a summary, and stops. Nothing is broken, because a chat model ends its turn and the next move belongs to whoever sits in the user's seat. So you type "looks good, now the tests," and an hour later you type it again.
Most of those messages carry no judgment. They say where the job stands, what comes next, and what done means for the piece in hand, and a program that is running the job already holds all three. In one public run of Favur, the harness (the program that runs a team of agents) behind Favur Evals, the agents' conversations hold 607 messages in the user's seat, and the harness wrote every one of them from the recorded state of the run.
One of them reads like this, word for word.
Stop re-reading files and re-running commands you have already run. You already have what you need.
You have typed that sentence at an agent, late in the day. The harness sent it because a counter reached fifteen. Twenty-one agents received that message during the run, and for seventeen of them it was the only warning. All twenty-one then closed the step they were stuck in and moved on.
What you type all day
Open a long session with your agent and read only your own messages, and they sort into two piles.
The small pile holds decisions that needed a person, such as a change of scope or a choice between two designs. The large pile is bookkeeping. "Continue." "That part is finished, move to the parser." "Run the linter before you call it done." "You still have two failing tests."
Every line in the large pile restates something a program can read off its own records. The task list knows what is finished, the test runner knows what is failing, and the workflow knows which step comes next and what that step has to produce.
The large pile also has a tone. Late in a session the bookkeeping turns short, and "you already checked that" is still bookkeeping. It reports a fact about the session, that the agent has spent a long time in one place, and a program can count that too.
The system prompt forgets
The obvious home for that bookkeeping is the system prompt, and two things go wrong there.
A system prompt that carries state is rebuilt for every request. When the agent moves from step three to step four, the text about step three is replaced, so the model can see where it is and has no record of how it got there.
A prompt that changes every turn also defeats prefix caching. A prefix cache matches text from the top down and stops at the first difference, so state near the top of the prompt throws away nearly everything below it.
A user message has neither problem. It is appended and it stays, so a run of them reads as a journal of how the job moved. The system prompt is then free to hold only what is fixed for the whole task, such as the agent's role, its standards and an outline of its workflow, and it rarely changes during a conversation.
Four moments to speak
A generated reply sent at the wrong moment is noise. Our harness writes one, which we call a progress report, at four moments.
- The model answered in plain text and called no tool. This is the stop-and-wait case from the top of this page.
- The agent crossed a joint in its own work, meaning it started or finished one unit of it.
- An agent it delegated to came back with a result.
- Something outside the conversation has news for it, such as a score change from the agent that supervises the others, a stall notice, or a note from a person.
The harness stays quiet after an ordinary tool call. A file read or a shell command returns its result and nothing else, so the model goes straight from the result to its next action.
What a real one says
This is a progress report from that run, sent to the top-level agent as it entered the fourth step of its workflow. We shortened it and swapped our internal tool and field names for plain words, and the structure and the instructions are as sent.
# Progress Report
## Current Step: 4 - Context Init
Entry criteria: Architecture approved
Exit criteria: Six context documents created
Create the six documents. Read all six back to confirm non-empty.
### How to Advance This Step
When you have completed all exit criteria above, call the
step-completion tool with your evidence.
If you cannot proceed, call it with success set to false instead.
Do not call it speculatively before exit criteria are met.
### Step Requirements
A list of the documents created (required).
Omitting it or passing an empty list will fail validation.
The agent's next message was one line. "All six context documents created and template-valid. Advancing."
The exit criteria arrive when the step begins, so the agent knows what will be checked before it writes anything. The report names the evidence the check will ask for and says an empty answer fails. It also always offers a second door, a way to report "I cannot finish this" that counts as a valid move.
Other sections appear only when they have something to say. A section on errors shows up only while there are errors, and the same holds for open questions and standing instructions.
Some sections belong to one kind of agent. Several of our agents keep fault counters, each one a tally of a specific failure such as a delegation that went wrong, and a counter that reaches its limit tells the agent to hand the problem up where it would otherwise retry. The report prints those counters. A testing agent's report restates the rules of its job, which are that it cannot fix code and that three identical failures mean it escalates. A model deep in a long task can lose track of a rule it read long ago, and a rule printed in the newest message is one it has just read.
The harness loses patience for you
The second door matters most when an agent circles. An agent that keeps re-reading the same files is not stopped and waiting, so none of the first three moments fires. A person watching would step in.
The harness counts instead. After fifteen cycles inside one step without finishing it, the agent receives a notice in three parts. The first states the count and names the step. The second is the pair of sentences quoted at the top of this page, followed by the evidence the step still owes. The third offers the second door again. An agent that truly cannot finish is told to report failure with what it has found so far, and the notice ends on "do NOT keep exploring."
Nothing reads the transcript to decide whether the agent looks lost. The trigger is a count of turns, and the thresholds are plain configuration. A counter cannot tell a lost agent from one that is two turns from done, so the wording has to be safe to send to both. It points at the exit and asks for evidence the agent already holds.
Five cycles later comes a blunter one. It opens by saying the agent is still in the step after twenty cycles, and its next sentence is "Previous warnings were ignored." It demands the step-completion call on the very next turn, and it closes with the consequence, that more exploring "will result in this agent being terminated."
In this run 21 agents received the first notice, once each. Seventeen of them never saw the blunter one. Four did, and two of those received it a second time.
What the agents did next
We went back through the stored conversations and followed each of the 21 agents from its notice to the end of the step.
All 21 closed the step, and the workflow moved on. Four did it on their very next turn. Fourteen were through within three turns, and the slowest took thirteen.
One coding agent had been circling in its final review. Its first turn after the notice filed the completion with the evidence asked for, and its next message read "The workflow is in done state and all gates passed. Completing."
The four that drew the blunter warning finished as well, between six and twelve turns after the first notice. The stored record shows no agent shut down for stalling.
The notices also clustered. Fourteen of the 21 landed in one kind of step, the one where a reviewing agent gathers evidence before it writes a verdict. That step has no natural end, because there is always one more file to open and a careful reviewer keeps opening them. The other seven landed in final reviews, in planning steps and in one implementation step.
Our reading is that the counter mostly caught thoroughness. These agents had what the step asked for, and nothing had told them that enough was enough. The count cannot prove the notice caused the finish, because some of them may have been one turn from done anyway.
Smaller notices, same build
The stall notice has smaller relatives, and they are built the same way.
Twice in this run an agent made the same tool call three times in a row with identical or empty arguments. Each time the harness answered in the user's seat. The message says "Your previous calls were rejected or had no effect," tells the agent to build valid arguments before it tries again, and names where the right ones are listed, which is the current-step section of its own latest report.
Once, a coding agent tried to open a unit of work and the request failed inside the harness. The reply said so, and it allowed that the fault might be the harness's own. It then named what a valid request needs and said which tool the agent should leave alone on its next turn.
Each of these messages states what happened, gives the next action and rules out the wrong one. A model that has just failed tends to try something adjacent, and the adjacent thing is often worse than a plain retry.
The journal has a price
A journal grows, and a long run piles up hundreds of these reports. The old ones describe steps that finished long ago.
So each report is tagged at the moment it is written, and the tag tells the context compressor, the part of the harness that shrinks old conversation when the window fills, how to treat it. A light compression pass leaves the reports alone. A heavy pass, the kind that runs when the window is nearly full, is allowed to fold them. We covered that compressor in an earlier piece on what an agent can forget.
A person can still cut in
Steering stays available, because a note from a person travels the same road as everything else. It arrives at the top of the next report, with the usual outline underneath, so the agent gets the instruction and its bearings in one message.
One run, counted
The run behind these numbers built a small desktop app in TypeScript from a short statement of work. Its public run page records 174 minutes of work and 1,594 model requests.
That run kept 110 agent conversations. They hold 607 messages in the user's seat, and 396 of those are progress reports. Another 67 open a new phase of an agent's work, 36 carry a result back from a delegated agent, and 30 deliver a screenshot an agent asked for. The stall notices and their escalations come to 27. Most of the remainder are the goals each agent started with. A person typed none of them.
We have not run the same job with the reports switched off, so treat 607 as how often the harness spoke, and run your own comparison on one task before you trust the idea.
Favur is closed-source and invite-only, and the run pages on the Favur Evals board are public. You can see how Favur runs its agent team on our site.
Most of what an agent waits to hear is bookkeeping, and the program that keeps the books can say it.
Top comments (0)