Why Does an AI Agent Say Done When Nothing Was Updated?

1. Define What Done Means to the User

A ticket request could mean a draft, approval submission, a recorded ticket or engineer notification. Agree the completion criteria: a unique record with correct customer, order and status, plus any required notification evidence. Show separate stages where appropriate instead of one blanket success message.

Expose preparation, approval, submission, verified, failed and uncertain states from backend task records rather than generated text. Record correlation, actor, tool action and business outcome with controlled data access. Users should be able to return later and check progress without triggering a new request.

2. An Illustrative Verifiable Service-Ticket Flow

This is an implementation example, not client production data. Check order ownership and required fields, prepare a draft and obtain confirmation. Recheck access and order state at execution, submit the API and verify returned ticket details in the authoritative system before reporting creation. Missing fields must not be invented.

If creation succeeds but the response is lost, query using a stable request identifier. Verify a unique match instead of creating again. No visible record may reflect asynchronous processing or delayed visibility, requiring bounded waiting or escalation. The same order can legitimately have different faults; business rules, not text similarity alone, define duplicates.

On narrow screens, scroll horizontally to see all columns.

3. Separate Timeouts, Retries and Duplicate Requests

Bind deduplication IDs to an intent and payload, and distinguish separate valid tasks. Verify API idempotency support, retention, lookup and concurrent behavior. Agent memory alone cannot prevent duplicates from other channels. Enforce business rules in the authoritative or trusted execution layer with traceable requests.

Bound retries by count, interval and stop conditions. Authorization failures, bad fields or conflicting states need correction, not endless retries. Recheck payload and expiry even with idempotent APIs. Pause uncertain irreversible actions for reconciliation, and prohibit changing request IDs merely to bypass duplicate controls.

4. Expose Partial Completion and Recovery Limits

Ticket creation, attachment upload and notification are separate actions. Resume failed steps without repeating completed ones. Record input versions, record IDs, outcomes and reasons, defining which actions can safely repeat. Human recovery must inspect current state; a failed overall task does not mean nothing happened.

Compensation does not undo every consequence. Sent notifications may be irreversible and deletion may damage audit links. Agree cancellation or correction semantics first. Across systems without a shared transaction, document reconciliation boundaries and responsible owners rather than displaying a generic retry message.

5. How Staff Resolve an Uncertain Task

Show the action, submission time, known IDs, completed steps and uncertainty reason. Prefer lookup, clarification or escalation over a resubmit button. Link verified records to the original task with reviewer identity. Route users without lookup rights to authorized staff rather than granting broad database access.

Coordinate concurrent reviewers and state transitions in the trusted task system. A resolved task or stale page must not permit duplicate creation; revalidate on the server. Record decisions and scope for cancellation, continuation or compensation. Assign owners to risk-prioritized queues before adding more automation.

6. Limit Scope When Legacy Interfaces Are Unreliable

Where stable APIs and deduplication are unavailable, prepare reviewed drafts for authorized staff to submit in the original system. UI automation requires detection and escalation for layout, login, dialog and network failures. A save-button click is not verified persistence. Distinguish stable integration, constrained adaptation and manual steps.

Evaluate new controlled APIs where the client can change the system; otherwise confirm supported integration with its provider without bypassing access rules. Pilot stable, complete tasks and retain risky exceptions for staff. Document automation exclusions in scope and UI rather than promising autonomy while relying on hidden manual recovery.

7. Accept Authoritative Results and Failure Handling

Test valid creation, missing fields, denied access, duplicates, lost responses, outages and partial completion in authorized environments. Verify UI status against authoritative records, not only friendly wording or successful tool logs. Document agreed concurrency, environment, API and inputs. Production disruption drills require separate approval.

Deliver state definitions, contracts, deduplication, queues, monitoring and operating procedures, then rehearse uncertainty recovery with maintainers. Separate diagnosis, API improvements and application changes in scope. Unsupported legacy APIs may require drafts or manual steps. Start an inquiry with a sanitized task, time and observed result, not databases or credentials.

Official information and scope of verification

Reference check date: 2026-10-06. Platform capabilities change with the version, the package, the area and the authority; information is used to describe technical capabilities and does not represent search volumes, the results of the customer in Sino-China or the original cooperative qualifications.

• AWS Builders’ Library: Idempotent APIs and Safe Retries (External Reference)