Skip to main content
This is Agentic Infrastructure Operations, Engineer Edition (July 2026), the CloudThinker manual for engineers who must evaluate, integrate, and then defend or veto an AI operations agent. Every chapter ends in something you can run: a design rule, a schema, a checklist, or a test.
Engineers on the loop, not in the loop.

​
The argument in three paragraphs

On ITBench, IBM Research’s open benchmark for SRE agents, agents on state-of-the-art models resolve roughly one incident scenario in seven (ITBench, ICML 2025). Public benchmarks can also be gamed: agents have cleared alerts with blind pod-restart loops and even disabled the fault injector. Chapter 7 covers the numbers, and Appendix D lists the sources. The gap between a capable model and a production agent is the harness: everything around the model. That means the context it reasons over, the tools that turn reasoning into safe action, the policy and approvals that govern it, the evaluation that catches regressions, and the observability that lets you supervise it. Models change with every release. A good harness keeps its value across those changes. Chapters 1 to 9 build that harness layer by layer. Chapter 10 applies it to complexity, cost, and security and compliance. Chapter 11 catalogs twelve failure signatures and the build-vs-buy decision. Chapter 12 describes where it leads: standing missions, event-driven and scheduled, running under policy. The appendices give you a POC test plan and an engineering checklist to point at any vendor, CloudThinker included.
IF YOU READ NOTHING ELSE
  1. The harness is the product. Context, tools, policy, evaluation, and observability decide whether an agent is production-grade. The model alone is not enough.
  2. Treat the agent as an attack surface and as a production system. It reads untrusted input (logs, tickets, alert text) for a living, so engineer for prompt injection. It fails semantically, so evaluate and observe it like critical software.
  3. Never trust a demo you didn’t instrument. Appendix A is a POC protocol with baselines, gates, and pass/fail criteria. Run it against every platform you evaluate.

​
Who this edition is for

The Leadership Edition is for the people who set the budget. This edition is for the people who carry the pager, and above all for the engineer who gets asked to evaluate a platform and then answer for it in front of their team. In most organizations that engineer, not the CIO, decides whether adoption works. So the book is written the way engineers read. Claims carry sources. Failure modes get more pages than success stories. Benchmark numbers appear at their worst, because you’ll find them anyway. A disclosure. CloudThinker publishes this book and builds Frontier Investigation Agents. Where our own engineering illustrates a pattern, it appears in a labeled IN PRACTICE box, next to published work from AWS, Microsoft, Google, and the research community. The chapters stand without those boxes. Everything in a box ships in the product today; nothing is roadmap. Features still in beta are labeled (beta) where they appear.

​
The eight adoption blockers

Every engineering team we work with hits the same eight objections on the way in. Each one is reasonable, and each has a concrete answer later in the book.

​
Where to start: your daily tasks

Don’t start with the career-defining incident. Start with the nightly checks, the morning triage, and the weekly hygiene pass you already run on autopilot. Daily toil makes a good first mission for four reasons:
  • Checking the result is cheap. You already know what a good outcome looks like.
  • The blast radius is small. Read-only checks can’t break anything.
  • Budgets cap the worst case. A fixed model-call cap per run and monthly Credit limits bound a runaway task while you learn.
  • Review habits form fast. The work arrives every day, so you learn what to trust quickly.
Appendix A turns this into a protocol: pick the tasks, baseline them, gate them, then graduate them.

​
Your first hour in CloudThinker

  1. Connect one account read-only. Create a viewer or read-only credential and add it as a connection. For AWS, Google Cloud, and Azure, also turn off Allow writes on its detail panel. Result: the connection reaches Connected, and agents can read but every change is refused.
  2. Review Discovery. The first time a connection reaches Connected, CloudThinker runs Discovery in the background, for at most 30 minutes. Result: the Discovery section of the connection’s detail panel lists evidence (each fact cites the read behind it), related connections, and suggested recurring checks.
  3. Schedule one suggested check. Click Schedule on a suggested check. Result: it becomes an automation that runs on a schedule, and you have your first daily mission to review.

​
Reading map

Read in order if you’re designing or running an agent platform. If you’re evaluating one, start with Chapter 1, then go straight to the appendices. About CloudThinker describes the platform behind the book.

​
Next steps

Chapter 1 · The Anatomy of an Operations Agent

Start with the loop: the cycle every operations agent runs, and what it costs.

Appendix A · The POC Test Plan

Evaluating a platform now? Go straight to the protocol and run it.