Ask a restaurant for a table for eight on Saturday and the person on the phone says "noted". That is not a booking. It means someone will check the floor plan and call back. If you tell your friends the table is booked at that point, you may be right, and you may find out on Saturday that you were not.
A large share of cloud operations work exactly like that phone call. The API answers almost immediately with "accepted", and the real work happens afterwards: capacity is found, disks are attached, configuration is applied, dependencies are checked. Some of those steps fail. The success the caller saw at the start was the success of being heard, not of the change.
Humans who work with cloud consoles learn this through experience. They watch the spinner, refresh the resource and check the activity log. An operations agent has no such instinct. Unless it is built to track the operation to the end, it will report "done" the moment the request is accepted, and the person relying on it will act on a change that has not happened.
What happened at Ilanga
Ilanga Retail Group is fictional, and its systems and figures are illustrative. During the third month of the pilot, when Ops Desk had just begun executing a short list of changes with approval in shared non-production, the platform team ran a month-end rehearsal. A finance analyst needed the reporting database in the Azure non-production environment scaled up before running a heavy set of reports.
The engineer asked Ops Desk to scale it. Ops Desk prepared the change, the engineer approved it, the tool submitted it, and the Azure Resource Manager API responded with 202 Accepted. Ops Desk's early tool code treated any 2xx response as success, so it replied "Done: the reporting database has been scaled up." The engineer told the analyst to start.
Twenty minutes later the operation finished with a status of Failed: the requested size was not available at that moment. The database was still at its original size, the reports were crawling, and the analyst had been told otherwise. Nothing was damaged, but the team had learned something important in a rehearsal rather than at real month-end.
Accepted is not done
The life of an asynchronous operation has a few distinct stages:
- The request is sent.
- The platform accepts it and returns a handle: a URL, a token or an operation resource that represents the work in progress. The API call has succeeded at this point. The change has not happened.
- The operation runs. The caller polls the handle, ideally at the interval the platform suggests.
- The operation reaches a terminal state: succeeded, failed or cancelled. Only these mean the work is over.
- The caller checks the result. Even "succeeded" deserves a read-back of the resource itself, because the state you asked for and the state you got are not always the same thing.
There is a sixth case that agents and scripts both handle badly: the caller stops waiting. A timeout on the caller's side does not mean the operation failed. It means the outcome is unknown. The operation may still complete five minutes later. An agent that treats a timeout as failure and retries can create the thing twice, or apply two conflicting changes.
Three providers, one pattern
The pattern is shared across the major clouds, but the vocabulary differs enough to trip up a generic tool. The following was checked against each provider's documentation on 14 October 2026.
Azure Resource Manager. Microsoft's documentation on asynchronous operations explains that a long-running request initially returns 201 Created or 202 Accepted, and that the response headers say how to track it. If an Azure-AsyncOperation header is present, the caller polls that URL for a status. If not, it uses the Location header. A Retry-After header suggests how many seconds to wait between checks. The operation is finished only when the status is Succeeded, Failed or Canceled; any other value, including provider-specific ones such as Accepted, means it is still running. Microsoft also notes a detail that matters for agent identities: tracking the status needs permission at the resource-group level, because the status URL is not scoped to the individual resource. An agent identity scoped too tightly can start an operation it cannot follow.
AWS Cloud Control API. AWS's resource-agnostic API treats create, update and delete as asynchronous by design. Each request returns a ProgressEvent with an operation status such as IN_PROGRESS and a RequestToken, which the caller passes to GetResourceRequestStatus to track the request. AWS notes that resource operation requests expire after seven days, and that cancelling a request does not roll back changes already applied: it can leave the resource partly changed. Other AWS services have their own variants. CloudFormation, for example, reports stack status as it progresses, and its change sets let a caller preview a change before executing it.
Google Cloud. Google's API design guidance (AIP-151) describes long-running operations as returning an Operation resource that the caller polls. When the operation finishes, its done field becomes true, and the outcome is in either a response or an error. That is the trap in its purest form: done means finished, not succeeded. Compute Engine follows the same idea with its own operation resources, which can be polled or waited on.
What an operations agent must do differently
After the rehearsal, Ilanga rebuilt every write tool around an operation record, a small piece of state that belongs to the system rather than to the conversation:
- Store the handle immediately. The moment the platform accepts a request, the tool records the operation URL, token or name, along with the approval reference and the intended end state.
- Poll with discipline. Respect
Retry-Afterwhere it is provided; otherwise use a backoff interval. Stop at a maximum duration set per operation type: seconds for a tag change, tens of minutes for a database resize. - Distinguish four outcomes, not two. Succeeded, failed, cancelled and unknown. Unknown is reported as unknown, with the handle, and is never silently retried.
- Read back the resource. After success, fetch the resource and compare it with the intended state. "The database now reports the requested size" is a different claim from "the operation reported success".
- Make retries safe. Before retrying anything, check whether the first attempt eventually landed. Where an API supports an idempotency or client token, use it, so that a repeated request is recognised as the same request rather than a new one.
- Keep the conversation honest. Ops Desk now replies in stages: "Request accepted by Azure; tracking operation", then "Finished: succeeded; the database reports the new size", or "Finished: failed, capacity unavailable; nothing changed". The engineer can tell the difference between being heard and being done.
None of this is new to experienced platform engineers. Good deployment pipelines and infrastructure-as-code tools have handled asynchronous operations for years. The point is that an AI agent bypasses those habits unless they are built into its tools. A conversational interface makes it very easy to say "done" too early, because a fluent sentence feels like a result.
Business completion is a further step
Even a correctly tracked operation only tells you the cloud change completed. The business action may need more. Scaling the reporting database helps only once the reporting service has reconnected. Creating the price-file bucket helps only once the export job has permission to write to it. At Ilanga, each write tool declares a short completion check that tests the business outcome where that is practical, such as a test write from the export job's identity. Where it is not practical, Ops Desk says so: "The bucket exists and is private. I have not confirmed the export job can write to it."
This is the same lesson CloudNala's Agent Evidence Layer series draws from a different angle: a tool can fail while the answer looks complete. In cloud operations, the gap between the two is often measured in minutes, and in what someone did during those minutes.
Key points
Accepted is not done. Many cloud APIs return before the change happens; the response is a handle, not a result.
Track to a terminal state. Succeeded, failed or cancelled end the operation. Everything else means it is still running.
A timeout is unknown, not failed. Never retry blindly; check what happened first, and use idempotency tokens where available.
Read back the resource. Confirm the intended state, then check the business outcome where you can.
Each cloud says it differently. Azure, AWS and Google Cloud share the pattern but not the vocabulary, so tools need a small adapter per provider.
Next: Part 5, Preventing expensive and destructive tool calls. All parts are on the series page.
How CloudNala can help
We review operations agents and automation for the gaps that only show up after the demo: asynchronous operations reported as complete, unsafe retries, identities that can start what they cannot track, and missing read-back checks. We then help rebuild the tool layer so every change is tracked to a real outcome and every reply says what is actually known.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Operations AI Review or write to us at consult@cloudnala.co.za