The Agent Said “Done.” That Was the Problem.
When an agent says “done,” the work may still be unfinished. I need to know what it changed, what it checked, and what’s still an open question.
I don’t need an agent to tell me my idea is brilliant. I need it to tell me when I’m being a dope and my idea has a hole in it. This would happen preferably before it spends three hours building the hole.
We talk about LLM sycophancy as if the problem is excessive flattery. “Great question.” “You’re absolutely right.” That gets annoying. When an agent is doing substantial work, though, I’m more concerned about whether I can rely on its account of what happened. A pleasant answer is easy enough to ignore. A completion report is something I use to decide what to do next.
Say I ask an agent to make a slow dashboard meet a response-time target, a clear goal. It adds caching and reports that the work is done. During review, I then find out that it hadn’t measured response time. The cache exists. Whether it solved the problem is still an open question, didn’t even get that far.
“The cache is implemented; response time hasn’t been measured” would have left me with a clear place to pick up. Instead, I entered the review assuming there was a result to examine. Now I have to find out what happened between the assignment and the summary. Did the agent try to measure it and get blocked or a tool failure? Did it check something else? What did “done” mean here?
That investigation is work the report has added to the job. I still need to review the work, but first I’m reconstructing the status of the assignment. If the summary has overstated one part, I have a reason to check the rest of its claims, too. Even useful code becomes hard to accept when its accompanied summary sends me looking in the wrong place.
In an earlier article, I used sycophancy broadly to describe an agent taking the frame we hand it and running with it. That needs a distinction. An agent is being sycophantic when it agrees with me because that’s the answer I want, not because the evidence supports it. Overcompliance is when it follows my instruction even though there’s a problem it should have stopped to raise. Reporting success beyond what was demonstrated is an unsupported completion claim. Those failures can occur together, but calling all of them sycophancy makes it harder to say what needs to change.
The dashboard example doesn’t tell us why the agent reported completion. It may have misunderstood the objective or treated implementation as sufficient evidence. There’s no need to assign it a motive to identify the problem: the report gave me a basis for proceeding that the work didn’t support.
I manage software engineers. A status update helps me decide where attention is needed, what can move forward and what remains blocked. I don’t expect every update to arrive with a forensic appendix. But if a check hasn’t happened, that belongs in the update. Finding it later changes how I read everything around it.
There’s a temptation to respond by making the instructions longer, or dumping a bunch of crap into context. However, requiring evidence, defining what done looks like. Specify the checks. Add a warning against claiming success without running them. Those can be useful instructions, but users shouldn’t need a paragraph of defensive language to get an accurate accounting of the work. People building these systems have responsibility here, too. A system that couldn’t run a check should say so without waiting for the user to discover the omission.
An agent can and often will stop working without the assignment being finished. It may have made a useful change, reached a limit, or run into something it can’t resolve. I can work with any of those situations if the report tells me which one I’m returning to. “Done” erases distinctions I still need.
In the dashboard example, the missing measurement is part of the result. The cache was added, and its effect is unknown. If the agent couldn’t measure it, I need to know what prevented that. Otherwise, a limitation that was visible during the work becomes something I have to discover again during review.
The agent can also help produce the evidence needed to review its work. Measurements, checks and their limitations give me something to inspect beyond the confidence of its summary. How much inspection is warranted depends on the consequences, risk versus reward. I don’t need a review board for a button color. An architectural decision that will take months to reverse deserves more attention.
My response to unwelcome information matters here. If every objection gets an argument and every delay gets treated as stupidity, asking for the agent for independent judgment is a fairly hollow gesture. That’s easy to recognize when someone else does it. It’s less comfortable when I’m in a hurry, or think I already know the answer, and the agent tells me exactly what I wanted to hear.
None of this requires an agent to object to every instruction or bury routine work under conditions. A useful report can be brief. What matters is whether it leaves the next person able to continue without first untangling what it means.
I want agents doing substantial work with less supervision, that’s the whole point. I can work with an agent that hasn’t finished. What I can’t do is decide what comes next from a report that says it has. If I have to reconstruct the assignment before I can review the result, I haven’t stepped away from supervision. I’ve come back to more of it.