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. A queue may still reject it. A downstream system may fail. A browser may submit twice. A deployment may exist but remain unhealthy.

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.

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 reached its final state.

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.

The release must define which state means “done” for the business task.

Write an expected-state contract first

An expected-state contract describes what must be true after the action.

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.

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. It does not replace the underlying observation.

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. It may have succeeded while the response was lost.

These states require different next actions.

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.

A transport-level request ID helps, but it is not enough when the same business operation can enter through several services or retries.

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, not only an infrastructure setting.

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 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 is missing. A deployment may create resources while the health check fails.

Model these 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 but incomplete.

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.

NIST’s 2026 concept paper covers identification, authorization, auditing, and non-repudiation for agents.

The paper is context, not a certification for this design. The engineering requirement remains direct: preserve the person, task, policy, action, and result in one evidence chain.

The production release gate

Before an action receives write access, test the state transition, not only the model response.

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.

BigCircle 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.

Use the Agent Action Boundary Canvas to define the expected state, verifier, retry rule, partial-failure states, and recovery owner for one action.