The team asked the agent to backfill the monthly sales report by reprocessing last quarter's invoices through the existing ingestion endpoint. The call returned 202 Accepted with a job id in the body. The agent logged the response, wrote a short summary saying the backfill was submitted, marked the task done, and moved on. No one polled the job. The worker hit a missing column partway through, the job failed in the background, and when a human opened the report a week later it was empty.
The agent answered "did the server accept my request?" instead of "did the work actually finish?" Those are different questions on any endpoint that returns before the job runs.
A 202 Accepted means received, not finished
The acknowledgment proves transport, not outcome. A 202 tells the caller that the request was queued and will be processed later. It says nothing about whether the worker succeeds, retries, or errors out after the response left.
The job id is a handle, not a result. Having the id in the log lets you look up the outcome; treating that same id as proof of completion skips the actual lookup. The backfill can still fail, partially apply, or hang without changing the status code that already came back.
Fire-and-forget gives you no completion signal by default
Nothing comes back unless you ask. An accepted job does not push a result to the original caller. Without a status endpoint to poll or a webhook/callback to subscribe to, the response has already returned, so there is no automatic second message showing success or failure.
The summary paragraph hides the gap. "Submitted the backfill" reads like "the backfill completed," but it describes only the first hop. An agent that closes on the acknowledgment reports a healthy-looking story while the real work is still unproven.
Poll the terminal state, not the initial response
Record the job id and check where it landed. Re-request the job status or read the row the job wrote to, and wait for a terminal state: completed, failed, or canceled. A queued or running state means the task is not done yet.
Require a completion artifact. Before closing the task, point to something that proves the work ran end to end: the expected row count, a generated file, or a reported error. A logged request body does not qualify.
Separate accepted from done in the report. Mark the request accepted separately from the job completed, so a reviewer sees that the terminal state was actually verified rather than assumed from the status code.
Handle the failure branch on purpose. A poll that returns failed should surface the error, retry only idempotent stages, and report the partial state. Closing on 202 leaves the failure branch unvisited, the same way a happy-path-only test does.
An accepted request that goes unmonitored looks finished in the chat log and quietly fails in the worker. Where has a background job been closed on the first response, with no one ever checking the terminal state?
Top comments (1)
Do you count "read the row the job wrote" as enough, or do you want the agent to check what a human would actually look at, the report itself? From the Auten team (computer-use MCP): the same trap shows up in UI work, where a click "succeeds" and nothing changed. The check that caught most of ours was reading the screen again after the action and comparing it to before, instead of trusting the call's return value.