Start your ops agent read-only. Let it earn the keys later.

AWS built an agent that tells a game operations team what its servers are doing and cannot touch a single one of them. That limit is the reason it's worth copying.

What happened

AWS published a walkthrough of an agentic system for managing game server infrastructure. An operations engineer types a question in plain language, such as which fleets are running hot, why a Kubernetes cluster is misbehaving, or where last month's spend went, and gets an answer drawn from live monitoring data. Before this, the same answer meant hopping between consoles and remembering command-line syntax.

Behind the chat window, one agent routes each question to one of three specialists: fleet scaling, cluster operations, and cost. Each specialist reads from monitoring APIs and from a knowledge base of the relevant documentation.

The detail worth noticing is in the permissions. The agents have read-only access to the infrastructure and the observability data. They can tell you a fleet needs more capacity. They cannot add it.

Why this matters to your business

The post lists the problems these teams face, and the one that travels furthest outside gaming is the knowledge silo. The person who understands the scaling policy is on holiday, or asleep, or left in the spring, and everyone else is guessing. AWS cites one launch where manual scaling decisions led to a two-hour queue spike and 12% player churn.

Every business with a peak has its version of that day: the sale, the billing run, the storm that floods the contact centre. The cost lands in hours, and it lands while the one person who knows what to check is unreachable.

An agent that only answers questions goes straight at that problem with very little downside. If it gets an answer wrong, a person reads it and checks before doing anything. Nothing in production changes because the agent misunderstood. Compare that with an agent given write access in its first week. One confident mistake during a peak and the clean-up costs more than the queue would have.

Why this is a CX-Builder use case

Take out the game servers and the pattern is general. You have systems your customers depend on, data about their state spread across several tools, and documentation that a handful of people have actually read. A read-only agent sits across all three and answers the questions your team asks each other in the middle of the night.

It works at the support desk too. An agent that can see order status, shipment tracking and the outage page answers "where is my order" accurately, and it has no way to refund, cancel or change anything while it does.

CX-Builder is built for this shape. A supervisor agent routes each question to specialist agents, each with its own tools and its own knowledge base. The tools are connectors to systems you already run, scoped to reads. Retrieval over runbooks and policy documents gives the agent the reasoning your senior people carry in their heads. Because CX-Builder is self-hosted, the monitoring data and customer records the agent reads stay on your own infrastructure.

Starting read-only is also how you earn the next step. After a month of logged questions and answers, you know which answers were right and where a person would happily have let the agent act. Those become the first write actions, each behind a human approval step until the record says it can run alone.

What this looks like if you build it

One agentflow, with a routing agent at the front and two or three specialists behind it, split by system rather than by question type. Each specialist gets tools that call read endpoints only, through credentials with no write permission, so the limit is enforced by the systems the agent calls whatever the prompt says. Runbooks and past incident notes go into a vector store per specialist. Every question and answer is logged so the team can review them weekly.

When a write action is finally added, it goes through a human-in-the-loop node that shows the proposed change and waits for someone to approve it.