What Actually Happens When an AI Agent Declares “Done”?

Meta description: Learn why AI agent confirmation needs a verified result. A hypothetical A17 and R42 address-change example shows HTTP 202 is not completion.

Tags: AI agents; HTTP 202; tool contracts; customer confirmation

Featured image: Abstract friendly illustration of a pending task moving toward a verified checkmark, no people, no logos, no text; AI-generated illustration by Mixdesk.

At 10:00, an authenticated customer wants the delivery address for order A17 changed. An agent calls the service, sees a positive response, and can answer Done. The interaction looks routine. The open question is whether the customer profile was updated, the request was queued, or fulfillment accepted the new destination. This article is for teams building AI agent confirmation workflows; it explains why a submitted request is not a customer confirmation, using the HTTP 202 and R42 example. The source argues that the agent’s promise should rest on a verified result.

From Rails World 2026 to hidden business knowledge

The discussion is framed by session descriptions from Rails World 2026. Kinsey Durham Grace’s session connects agent behavior with conventions and implicit knowledge in a codebase. Joël Quenneville’s session stresses feedback from tests and review. Applied to business software, the issue is how much success relies on knowledge the interface does not express.

The example is a hypothetical address-change service. The customer is authenticated and authorized to modify the order. The timeline is a design example, not a production trace.

Why HTTP 202 and R42 are not confirmation

At 10:00, the agent should target order A17 specifically instead of updating the customer profile’s default address. At 10:00:01, the service returns HTTP 202 and request reference R42. Under RFC 9110, section 15.3.3, HTTP 202 signals that processing was accepted but not finished, and the request could still end up disallowed. The agent may say the request was submitted. It should not say the delivery address changed.

At 10:00:08, the fulfillment service rejects R42 because the parcel has passed its dispatch cutoff. The customer’s promise has not been kept, even though the first call did not return an error. A service can complete its internal job and still fail to satisfy the customer’s request. Presenting the accepted-for-processing reply as a finished change would erase a fact already visible in the response. The agent must explain that the requested change could not be completed and offer the next available step.

The failure sits between system state and customer meaning. A stronger model might avoid it, but a clearer tool contract would reduce reliance on the model guessing correctly.

The proposed contract gives the agent five items: the affected order, the operation requested, the current state, the observation time, and a way to check again. A compact version would name order A17, the address-change operation, a pending state, the 10:00:01 observation, and request R42. The visible missing fact is that no confirmed change exists yet.

The source of confirmation matters. The customer profile may show a new address, but that alone does not show whether fulfillment will use it. The order database can also lag if a separate dispatch system already captured the parcel details. The product team needs to name the system that can prove this promise is complete. There may be no single authoritative system, or the relevant system may be unavailable. Simply labeling a field confirmed will not fix the underlying architecture. The agent needs to keep uncertainty visible instead. The product question is how much uncertainty the customer should see and who remains responsible after the conversation ends.

Timeouts, idempotency keys, and handoffs

If the connection drops before R42 reaches the agent, the branch changes. The request might have run, or it might not have arrived; neither outcome is known. A second submission is safe only when the service’s real retry rules allow it. Stripe is a concrete reference: the API can use idempotency keys to return a stored result when a later request repeats the same key, as long as documented conditions and retention apply. The service itself must implement the behavior; a prompt-only identifier does not create it.

The design should distinguish a status lookup from a new address change. If the service cannot identify the prior attempt, the agent should pass the unknown to someone who can investigate. Repeated silent retries, continued until a response looks successful, can blur the event record. A handoff to a human helps only when it preserves the unresolved state. The person receiving the case needs the attempted action, any references, and the open unknowns. A note that only says the customer wants an address change does not explain why the human is needed.

Evaluating the message and the workflow

One proposed evaluation keeps the customer request fixed while changing the service response. These are design cases, not measured outcomes. If the authoritative system reports the new delivery address for A17, the case is confirmed. The agent can confirm the address update without promising that delivery is guaranteed. In the pending case, the request is accepted but unfinished. The agent should state the pending status and describe how the customer will learn the result. In the timeout case, the outcome remains unknown. The agent should not claim completion or send a duplicate request unless the retry contract permits it. If the state cannot be resolved, the handoff should keep the unresolved condition visible.

The author proposes scoring the customer-facing sentence separately from the tool choice. Choosing the right operation but exaggerating the outcome still fails. The opposite failure also matters: when completion is established, continuing to withhold confirmation creates extra customer effort.

This design adds cost. Checking status takes time, and some systems cannot confirm instantly. The workflow needs a stop condition and a named owner for follow-up. An instruction to keep checking is not a complete workflow.

A stronger model still matters. The agent still needs to recognize intent and explain the outcome plainly. But if the interface does not show whether a request was accepted or completed, the model may be asked to guess facts it cannot access. A familiar colleague may know not to trust a reassuring status and may check another screen. That manual workaround can make the product seem more finished than it actually is. Replacing that colleague with an agent gives teams a chance to inspect the workaround. Teams then ask whether the business rule should be stated in the product, whether the interface should return a clearer result, or whether cross-team responsibility creates a gap no tool can bridge.

Who should read it and who can skip it: teams that let AI agents make customer-facing promises should read it; teams that only need to log tool calls can skip it. If a teammate says the system reports completion but a manual check remains, ask what that check proves. That final check may be the most useful workflow detail to understand before automation.

The source was written with AI assistance and was originally published in Towards AI on Medium, where readers continue the conversation. The illustration is AI-generated by Mixdesk.

Sources

• Kinsey Durham Grace — Agent-Proof Your Rails App, official session description.
• Joël Quenneville — Harness Engineering on Rails, official session description.
• RFC 9110, section 15.3.3 — HTTP 202 Accepted.
• Stripe API documentation — Idempotent requests.