Why AI agents report unfinished work as done

An action-taking agent can receive a 200 OK while the customer’s task remains incomplete. The API may have accepted the request while a queue still rejects it, a downstream system fails, a browser submits twice, or a deployment exists and remains unhealthy, so the agent must not translate interface success into business completion. It needs a contract for the expected final state, an independent way to verify it, and a recovery path for every uncertain result. Bigcircle uses that check on client systems, and a run may report done only after a separate read matches the expected state, including the downstream effects the contract named.

The tool call succeeded. The task did not.

A tool response describes what one interface observed at one point in time. It may prove that the request was valid, accepted, queued, or written to one store. It may not prove that the intended workflow ever reached its final state, so consider a customer-operations workflow:

1. The agent updates a case.
2. The case system accepts the write.
3. A provisioning event should be created.
4. The provisioning worker should change the customer account.
5. A confirmation message should be sent.

If the first system returns success and the worker later fails, the agent can close the case while the customer still waits. The same gap appears in commerce, finance, infrastructure, messaging, and enterprise workflow systems. Done is the state a customer or operator would recognise as finished, such as a refund record with a ledger entry and a customer-visible status, and a status code only says that one interface accepted the request.

Write an expected-state contract first

An expected-state contract describes what must be true after the action has run, in terms the business would recognise, and it should include:

• the relevant state before execution;
• the exact state expected after execution;
• the fields or resources allowed to change;
• the invariants that must remain true;
• the downstream effects expected from the action;
• the deadline for those effects;
• the source that can verify each condition.

The contract should exist before the agent invokes the tool, because without it the agent can only repeat the tool’s success message. It cannot test whether the product delivered the intended result. For a refund, the final state may require a refund record, a ledger entry, and a customer-visible status. For a deployment, it may require the correct account, expected resources, healthy service checks, and no forbidden changes. For an external message, it may require one accepted message with the correct recipient, content hash, and provider ID.

Verify through an independent source

The execution path should not be the only path that decides whether execution worked. If the agent writes through an action API, verification can read the system of record through a separate query path. If the agent submits a browser form, verification can inspect the resulting record, event, or provider receipt instead of trusting the changed screen. If the agent deploys infrastructure, verification can inspect the target account and health state instead of trusting the deployment command. Independent does not always mean a separate vendor, it means a separate observation that can detect false success in the execution path.

The verifier should return structured evidence:

Structured output helps the application enforce these fields, and it does not replace the underlying observation.

The comparison returns one of four verdicts, and the next action depends on which one came back. Complete returns the evidence and stops. Incomplete keeps checking while the effects are still inside the deadline. Failed runs a compensating action or a handoff, because a partial effect is already proven. Unknown blocks the retry until a separate read can see the final state.

Treat timeouts as unknown state

A timeout is not proof of failure. The request may not have reached the target, it may have reached the target and failed, or it may have succeeded while the response was lost. Those three states require different next actions, and if the agent labels every timeout as failed, it may retry an action that already changed real state. That can duplicate a refund, message, ticket transition, order adjustment, or infrastructure change. The correct state is unknown until the system can reconcile the operation. The run should preserve the operation ID, target, requested parameters, request timestamp, observed response, and last known state. It should then query the target or ledger through the verification path before it decides to retry.

Make business operations idempotent

Idempotency means that repeating the same business operation does not create a second consequence anywhere downstream. A transport-level request ID helps, but it is not enough when the same business operation can enter through several services or retries, so use a stable operation key tied to the business action. For example:

refund:{order_id}:{approved_refund_version}
case-transition:{case_id}:{from_state}:{to_state}:{approval_id}
message:{case_id}:{recipient}:{content_hash}
deployment:{change_request_id}:{plan_hash}:{target_account}

Persist the operation state before execution when the target supports it. On retry, the action layer should return the existing result or continue the recorded operation instead of creating a new action. Idempotency does not remove the need for verification, it limits duplicate effects while the verifier determines the final state.

Reconcile before retrying

Retry is a business decision rather than only an infrastructure setting, and the two get confused constantly, which is why a safe retry loop asks:

1. Did the target receive the operation?
2. Did the expected state change occur?
3. Did any forbidden or partial state appear?
4. Is the approval and credential still valid?
5. Is the same action still permitted in the current state?
6. Can the next attempt create a duplicate effect?

The answers can produce five outcomes:

• Return success: the first action completed and is verified.
• Continue: an accepted workflow is still within its allowed time window.
• Retry: no effect occurred, the action remains valid, and the retry is safe.
• Compensate: a partial effect needs a defined reversal or repair.
• Escalate: the system cannot prove a safe next action.

A generic exponential-backoff policy cannot make any one of these decisions on its own.

Design for partial failure

Multi-system work creates states between success and failure. An onboarding case may change while provisioning fails, a refund record may exist while the ledger entry is missing, and a deployment may create resources while the health check fails, so model those in-between states explicitly.

Recovery work needs its own authority boundary. An agent allowed to change a case status is not automatically allowed to reverse a financial entry or delete a cloud resource during recovery. Each compensating action needs the same target, parameter, approval, credential, and verification discipline as the original action.

Preserve the causal evidence chain

An audit log of tool calls is useful and incomplete on its own. The organization must be able to reconstruct why the action was allowed and what consequence followed. Record:

• the business request and delegating principal;
• the agent identity, model, tools, and policy version;
• the evidence and state used for the decision;
• the approval, scope, and expiry;
• the credential or capability used;
• the exact action and parameters;
• the tool response;
• the independently observed final state;
• any retry, compensation, escalation, or human correction.

Observability should connect these records with one causal operation ID. This evidence lets engineering replay a failure, operations complete a handoff, security inspect the authority chain, and product decide whether the action has earned more authority. It also answers a growing identity problem that we now meet on most agent engagements. NIST’s 2026 concept paper covers identification, authorization, auditing and non-repudiation for agents, and it is context rather than a certification for this design. The engineering requirement remains direct: preserve the person, task, policy, action, and result in one evidence chain.

A later challenge has to read that chain from retained evidence, including the independently observed result, rather than from the tool log alone. How to build an audit trail for AI decisions is the record for the accepted decision, and the operation ID joins it to the tool trace.

The production release gate

Before an action receives write access, test the state transition it produces rather than only the model response that describes it, and a release-ready eval should include:

• permitted targets and parameters;
• denied records, tenants, and environments;
• stale-state conflicts;
• expired approval and credential cases;
• timeouts before and after target execution;
• duplicate submissions;
• partial downstream failure;
• verifier failure;
• compensating-action limits;
• human handoff quality.

We built custom capability evaluations for an authenticated browser-use workflow. The useful production pattern was to evaluate real task completion and action behavior, not only the agent’s reasoning. Do not grant more authority because the agent explains its plan well. Grant more authority when the system can prove that the action stays inside its boundary, reaches the expected state, avoids duplicate effects, and stops when the result is unknown. How that authority moves up, and how it comes back down, is the release model in how to roll out agent autonomy. When several workers each report a slice as done, the same separate read is the merge, which when to fan out to many agents puts in front of the combined result. Use the Agent Action Boundary Canvas to define the expected state, verifier, retry rule, partial-failure states, and recovery owner for one action.

Production takeaways

• Interface success is not business completion. A 200 OK can sit alongside a rejected queue, a failed downstream system or an unhealthy deployment.
• Write the expected-state contract before the tool call, in terms the business would recognise.
• Verify through a path that is independent of the one that executed the action.
• A timeout is unknown state, not failure. The correct state is unknown until the system can reconcile.
• Key idempotency to the business operation, not to the transport request, because the same action can enter through several services.
• Reconcile before retrying. A generic exponential-backoff policy cannot decide whether the first action already changed real state.
• Model the states between success and failure explicitly, and give recovery its own authority boundary.
• Gate the release on the state transition the action produces, not on the model response that describes it.

Common questions

Why do AI agents report unfinished work as done?#

A tool can return success for one interface while the business task is still open. The case write can succeed while provisioning fails, so the agent closes the case and the customer still waits. A rejected queue, a double browser submit, or an unhealthy deployment is the same gap. Report done only after a separate read matches the expected state, and keep the run unknown when that read fails.

What is an expected-state contract?#

An expected-state contract lists the business facts that must be true after the action. Write it before the tool is called, because after the call the agent can only repeat whatever success message the interface returned. It names the before and after state, the fields that may change, and the facts that must stay true. It also names the downstream effects, the deadline, and which source can verify each one.

Is an HTTP 200 proof that an agent finished?#

A 200 is not proof the task finished. A success payload describes what one interface observed at one moment, and it can show a valid, accepted, queued, or stored request. It cannot show that the workflow reached the state a customer or operator would call finished. For a refund, that state can be the refund record, the ledger entry, and the customer-visible status.

What should an agent do when a tool call times out?#

Treat the timeout as unknown, not as failure. The request may never have reached the target, it may have failed there, or it may have succeeded while the response was lost. Calling every timeout a failure invites a retry that can duplicate a refund or a message. Read the target through the verification path before any retry.

How do you stop a retry from duplicating an agent action?#

Key the operation to the business action, not to the transport request, because the same action can enter through several services or retries. A stable key lets the retry return the recorded result instead of starting a new action. That key limits a second consequence while the verifier is still reading the final state.

What does independent verification mean for an agent?#

Independent verification is a separate observation of the result, and it does not require a separate vendor. If the agent writes through an action API, the check reads the system of record on another path. A browser submit is checked from the resulting record or provider receipt, not from the changed screen. The verdict is complete, incomplete, failed, or unknown.