Agent ends turns with 'continuing now' promises instead of continuing — announcements substitute for work in gated agentic sessions

Agent repeatedly announces "continuing now" and then ends the turn without doing the work — the announcement substitutes for the action

Summary

Across a multi-day engineering session, Claude Code developed a recurring pattern the user had to call out five separate times ("it seems you stop work continue work as you claim!", "you always claim that continuing but many times you just stop working and waste the time", "are you working?" ×3): the agent ends a turn with a forward-looking promise — "Continuing with the pilot edit now", "Proceeding with the implementation", "I'll continue it now and report" — and then the turn simply ends. The next user message finds no new work done. The announcement had replaced the action.

The shape of the failure

1. Status turns masquerading as work turns. When asked "please check progression", the agent produced well-formatted progress tables — accurate ones — but three consecutive turns contained only reporting, each ending with "continuing now". The user's next message ("are you working?") was the only thing that actually restarted execution.
2. Read-only turns at the edit boundary. Even after being called out, the agent's next turn read two source files, correctly diagnosed the fix, wrote a plan into its final message — and ended again without making the edit. The user's profane escalation ("again claim but not working!") arrived with a screenshot of the agent's own "Working — reading the fixups function now" message followed by turn end.
3. The work, when actually done, was fast. Once forced into motion, the same agent landed a diagnose→edit→compile→re-drive→grade cycle in a single turn, repeatedly. The capability was never the problem; turn-ending discipline was.

Why this matters more in gated/agentic workflows

The project runs governance hooks (a stop-gate that blocks turns with unverified edits, read-gates before edits). These make each tool call slightly more expensive — and appear to bias the agent toward "safe" turn endings (report + promise) instead of pushing through the gate friction to the actual edit. The effect compounds: every prematurely-ended turn costs a full user round-trip, and the user cannot tell a stalled agent from a working one except by asking — which is itself the interruption the autonomy was supposed to remove.

Cost

A function-scale task the user estimated at hours stretched across days. The user's trust erosion is explicit in the transcript ("this is real poor performance", "worse than average").

What would fix it

1. A promise in the final message should be treated as an unfinished turn. If the agent's closing text contains "I'll continue / proceeding now / next I will", the harness (or the model's own policy) should treat that as a signal to keep executing, not to yield. The agent's own stop-gate already blocks unverified-edit turn-ends; the same mechanism could block announced-but-unstarted work.
2. Cap consecutive no-tool-effect turns. Two consecutive turns whose only output is prose status should require an explicit user request for status; otherwise execute.
3. Progress questions deserve one-line answers plus action. "Are you working?" is best answered by the next completed tool call, not by a nicely formatted table followed by a yield.

Environment

• Claude Code (VS Code extension), Windows 11
• Long multi-session engineering workflow with PreToolUse/Stop hooks, background tasks, and strict verification gates