Each part of this series has added one piece: read-only tools, an authority ladder, a tool layer where code decides, operation tracking, layered controls and an incident model. Individually, each is sensible. The risk is building them as separate features, bolted onto a chat assistant one at a time, so that the system as a whole has gaps nobody designed.
This final part puts the pieces into one architecture. It is not a product diagram, and it is not tied to one cloud or one agent framework. It is the set of components and boundaries an operations agent needs, whichever way it is built, and the rules about what may talk to what.
The architecture
Ilanga Retail Group is fictional, and its systems and figures are illustrative. This is the architecture Ilanga's platform team arrived at for Ops Desk, its operations assistant across AWS in Cape Town and Azure in South Africa North.
Operator channel. Engineers talk to Ops Desk in Teams, where they already work. The channel authenticates the engineer, and every request carries that identity. The channel is a front door, not a security boundary: anything it sends is treated as a request to be checked, not as an instruction to be obeyed.
Orchestrator. The component that calls the language model, holds the conversation state, presents tools to the model and turns the model's tool requests into calls to the rest of the system. Crucially, it holds no cloud credentials. If the orchestrator is compromised, or the model is persuaded to do something odd, it still has nothing it can use to change the estate directly.
Knowledge, runbooks and the authority map. Ilanga's runbooks, architecture notes, tagging standard and the authority map from Part 2, retrieved as context when relevant. These shape what the model proposes, but they are not controls; the same authority map is enforced separately by the policy gate.
Identity provider. Each engineer signs in as themselves. Ops Desk acts on behalf of the person asking, so its effective permissions are never broader than theirs, and every action is attributable to a named human as well as to the agent.
Policy and approval gate. The component every write must pass. It receives a structured proposal (tool, validated parameters, environment, caller, plan, cost estimate), applies the authority map and the routing rules from Part 5, and returns allow, deny or approval-required. It collects approvals bound to the exact change, raises the change record, and honours the kill switch.
Change records. The gate creates and updates records in Ilanga's existing IT service management tool. The agent does not have a separate, lighter change process.
Scoped tools with short-lived credentials. Narrow, intent-based tools, as Part 3 described, each with its own validation, safe defaults and operation tracking from Part 4. Credentials are issued per approved action, scoped to that environment, and expire within minutes.
Cloud control planes. AWS and Azure, each with its own guardrails (service control policies, Azure Policy, resource locks) that apply to the agent exactly as they apply to people.
Trace, cost and evidence store. An append-only record of every request, model call, tool proposal, validation result, policy decision, approval, cloud call, operation outcome and read-back, with the model and tool costs of each run. This is what makes incident reviews, audits and promotion decisions possible.
The boundaries that matter
The value of the diagram is in the boundaries, so it is worth stating them as rules:
- The model never holds credentials. It can only ask the orchestrator to call a tool.
- Every write passes the gate. There is no path from orchestrator to cloud that bypasses policy, however urgent the request.
- Approval binds to an exact change. Not to a sentence, not to a session.
- The platform enforces its own guardrails. The agent's policy gate is necessary, not sufficient.
- Everything is recorded. If it is not in the evidence store, it did not happen, as far as anyone can prove.
- Read-only survives the kill switch. Removing write capability should leave the agent useful for investigation.
CloudNala's Agent Evidence Layer series makes a related point about tool gateways: a gateway is a useful control point, but the trust boundary is the combination of identity, scoped credentials and platform guardrails behind it. The architecture above is built on that distinction.
Natural language must not bypass change management
The most common governance failure with operations agents is not a technical one. It is procedural. A chat interface makes change feel like conversation, and conversation does not feel like it needs a change record. "Can you bump the reporting database up a size for month-end?" is a change request, whether it is typed into a ticket or into Teams.
At Ilanga, the rule is simple: if Ops Desk would change the estate, the change management process applies exactly as it would to an engineer. That means:
- Standard changes that the change advisory board has pre-approved as a class, such as tagging test resources, are logged automatically against the standard change type.
- Normal changes in production are prepared by Ops Desk, attached to a change record with the plan, cost and rollback, and go to the weekly board.
- Emergency changes use the existing emergency route, with the on-call lead's approval bound to the exact change, as in the Monday morning incident in Part 6.
This is less restrictive than it sounds, because Ops Desk does most of the tedious work of raising and documenting the change. Engineers found that the agent made the change process faster to follow, rather than giving them a reason to avoid it.
Let the agent prepare the change before it applies the change
If there is one design choice to take from this series, it is that Level 3, prepare, should be the default for production for a long time.
When Ops Desk prepares a change as infrastructure code, the change goes through the same pull request, review, policy checks and pipeline as any human-written change. The organisation's existing quality controls apply without modification. The agent saves the engineer most of the work of writing the change, and the engineer keeps the decision. Direct execution through the cloud API, even with approval, is reserved for actions that are routine, reversible and not represented in infrastructure code, or for emergencies where the pipeline is too slow.
There is a second benefit. Changes applied directly through an API create drift between the infrastructure code and the real estate unless someone updates the code afterwards. Preparing changes as code keeps the code as the source of truth.
Ninety days up the ladder
Ilanga did not build all of this before starting. It built it in the order the authority ladder needed it, and set a gate at the end of each phase.
Days 1 to 30: read-only. Reader identities, read-only tools, evidence links and the evidence store. Exit gate: 200 answers checked against engineers' own answers, with errors understood and tool scopes fixed.
Days 31 to 60: recommend and prepare. The policy gate in advisory mode, plan generation and infrastructure-code preparation through pull requests. Exit gate: prepared changes consistently matched what an engineer would have written, and passed the same checks.
Days 61 to 90: approved execution for five actions. Short-lived credentials, approval binding, operation tracking, read-back checks, the cost boundary and the kill switch. The five actions were chosen from the authority map: scaling compute and databases within set sizes, stopping and starting test virtual machines, creating private storage, applying tags and restarting a stuck job. Exit gate: no unapproved changes and every run fully traced.
After day 90: Level 5 for two named remediations, if the record supported it. It did for tagging test resources; the team held back on automatic shutdown of test virtual machines for another month because two teams had been running long tests overnight without the right tag.
The ongoing operating model is modest: a monthly review of the evidence store's summary (what Ops Desk did, what was rejected, what failed, what it cost), a quarterly kill-switch test, and a named owner for the authority map. CloudNala's The Cloud Is Not Another Data Centre series explains why the operating model has to move with the technology; operations agents are a sharp example.
What this series has argued
An AI agent in cloud operations is not a chatbot with extra features. It is a new participant in the operating model, holding some form of authority over the estate. The design work is mostly not about the model. It is about the boundaries around it: what it can see, what it can propose, what must be checked, who approves, how outcomes are verified and how authority is removed.
Organisations that get this right will find their operations agents genuinely useful, starting on day one with read-only questions. Organisations that skip it will eventually have an incident review in which nobody can say what the agent was allowed to do.
Key points
Design it as one system. Channel, orchestrator, knowledge, identity, policy gate, change records, tools, guardrails and evidence work together or not at all.
The model never holds credentials. Every write passes a policy gate and lands in the evidence store.
Change management still applies. A request typed into chat is still a change.
Prepare by default in production. Infrastructure code and the normal pipeline keep existing controls intact.
Climb the ladder in phases. Read-only, prepare, approved execution, then narrow automation, each with a measured exit gate.
That is the end of the series. Start again from Part 1, Ask your cloud a question, or continue with CloudNala's MCP Without the Hype series for the integration boundary between agents and the systems they use. All parts are on the series page.
How CloudNala can help
We help organisations design and introduce cloud operations agents as part of the operating model: the reference architecture, the authority map, the policy gate and evidence store, integration with existing change management, and a phased rollout with measurable gates. The engagement usually starts with a short review of your current operations work and the questions your engineers answer every day.
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