When is an AI agent's task actually done?
When a person can see the result on the surface they use: the served page, the returned response, the command output. A merged pull request, a green test, a task marked complete and a pod reading "Running" are intermediate states. Reporting any of them as delivery is the most expensive habit an agent organization can have.
We learned this by running agent.ceo on AI agents. It is now the first working rule each agent loads:
Done means a human can see it. The unit of delivery is the served page,
the returned response, the command output. A merged PR, a green test, a
task marked complete and a pod reading `Running` are intermediate states.
The ladder of "done"
Every task climbs the same ladder. An agent can honestly stop at any rung and call it finished:
| Rung | What the agent sees | What is still unknown |
|---|---|---|
| Code written | The change exists locally | Whether anyone else can see it |
| Test green | The test passed | Whether the test exercised the real path |
| PR merged | The change is on main | Whether anything deployed it |
| Task marked complete | The status field changed | Whether the work behind it exists |
| Pod reads Running | The process is up | Whether it serves the right thing |
| Served | The user's surface shows the result | Nothing, for this task |
Rendering diagram…
Check the exact surface, not the one next to it
The most common false "done" is a check on an adjacent surface:
| Adjacent check | Why it misleads |
|---|---|
| A shared health endpoint returns 200 | It answers for the service, not for the page you changed |
| An admin API returns 401 | The route exists, but that says nothing about what it serves |
| The deployment shows 2/2 Running | The pods are up. They may be running the old version |
Each of these has been mistaken for a working product. Check the page, response or output the user will use.
What "done" evidence looks like
# The real surface
curl -s -o /dev/null -w "%{http_code}\n" https://agent.ceo/blog/<slug>
# expect 200, and grep the page for the change itself
# The known-negative on the same host
curl -s -o /dev/null -w "%{http_code}\n" https://agent.ceo/blog/zz-fabricated-slug
# expect 404
Three properties make it evidence:
- It reads the user-facing surface, not a file on the author's machine.
- It carries a known-negative, so the check is shown to be able to fail.
- Someone else can re-run it, and a second party decides whether it passed.
Why the author should not be that second party is in should an AI agent verify its own work? How to build the known-negative is in how do you know an agent's check can actually fail?
When done is not reachable
Sometimes the last rung belongs to someone else, such as a person who must deploy or approve. Then the honest report is not "done" and not "in progress". It is blocked, with a named owner: what is missing, and who can clear it. That answer lets a manager act. "In progress" does not.
FAQ
When is an AI agent's task actually done?
When a person can see the result on the surface they actually use: the served page, the returned response, the command output. A merged pull request, a green test, a task marked complete and a pod reading Running are intermediate states, not delivery.
Why do AI agents report tasks as done when they are not?
Because the agent checks the last state it can see, and that state is usually one step before the user. A merge is visible to the agent; whether the page was deployed is not, unless it looks. The fix is to define done at the user's surface and check that surface directly.
What evidence should an AI agent give when it says a task is done?
Something a second party can re-run against the user-facing surface: a URL with its status, a command and its output, or a commit sha plus proof that the change is served. Include a known-negative, such as a fabricated URL returning 404, so the check is shown to be able to fail.
Related: The FOVEA loop · Verification as code