AI for Cloud Operations
Giving an AI agent access to a cloud account is like handing a new operations employee a master key: understanding the request does not mean they should be allowed to perform every action. This seven-part series shows how to introduce AI into cloud operations without creating an uncontrolled administrator: start read-only, climb an explicit authority ladder, treat the cloud API as the contract, handle asynchronous operations honestly, block expensive and destructive calls, separate diagnosis from remediation in incidents, and assemble it all into one reference architecture. One fictional South African retailer and its platform team carry the examples.
7 articles
- Part 1Ask your cloud a question: start your operations agent read-onlyA conversational assistant that can change your cloud is a new administrator, whatever it looks like. Part 1 makes the case for starting with read-only questions, shows what an operations agent is actually useful for on day one, and explains why read-only is the safest start but not a risk-free one.8 min read
- Part 2From read to write: the authority ladder for cloud operations agentsThe jump from a helpful read-only assistant to one that changes production usually happens because a demo worked, not because anyone decided it should. Part 2 sets out six levels of authority, shows how to map them per action and per environment, and explains what evidence should move an agent up a level.8 min read
- Part 3The cloud API is the contract: how a tool-using operations agent should workAn operations agent does not change the cloud by understanding a sentence. It changes it by calling an API, and everything that makes that call safe lives outside the model. Part 3 explains, in plain language, how a tool-using agent should be built so the model proposes and the system decides.8 min read
- Part 4The API call succeeded. The cloud change did not.Many cloud operations return as soon as the request is accepted, long before the change is finished. An agent that treats 'accepted' as 'done' will report success for changes that later fail. Part 4 explains asynchronous operations in plain language, how Azure, AWS and Google Cloud each handle them, and what an operations agent must do differently.8 min read
- Part 5Preventing expensive and destructive tool callsThe worst operations-agent incidents are not exotic. They are an ordinary delete in the wrong account, or a scale-up nobody priced. Part 5 sets out the layered controls that stop expensive and destructive actions without relying on the model to behave, including cost boundaries, plan-before-apply, two-person approval and a kill switch that is part of the architecture.8 min read
- Part 6AI-assisted incident response: where a wrong guess is tolerable, and where it is notIncidents are where an operations agent can save the most time and do the most damage. Part 6 separates incident work into evidence, diagnosis, recommendation and remediation, shows where an AI's mistakes are cheap and where deterministic verification is compulsory, and walks through one illustrative Monday morning.8 min read
- Part 7The cloud operations agent reference architectureIdentity, tools, policy, state, observability, cost and human approval only make an operations agent safe when they are designed as one system. Part 7 brings the series together into a reference architecture, explains why natural language must not bypass change management, and sets out a 90-day route from read-only to approved execution.9 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala