Runbooks & Robots #001 | August 14, 2026 | 5-minute read
You do not need to become a machine learning expert to work with AI agents. You already know much of the hard part: permissions, APIs, retries, logs, failure handling, and safe changes.
The new part is understanding how an agent chooses and repeats actions.
The short version
An AI agent uses a model to choose tools and repeat steps until it reaches a goal or a limit.
This week, MCP became easier to run, OpenTelemetry added an end-to-end agent demo, and cloud providers moved toward separate agent identities.
In a Google Cloud survey, 83% of 1,402 IT leaders said production agents require infrastructure upgrades.
The START checklist shows how to try one narrow, read-only agent task with traces and hard limits.
Before adding write access, protect tools against retries that repeat a successful change.
First, what is an AI agent?
A normal chatbot answers a question. An agent can take several steps toward a goal.
For example, you ask: “Why is checkout latency high?”
The agent may:
Query metrics.
Read recent deployment events.
Search logs.
Compare the evidence.
Suggest the likely cause.
The model decides which tool to call next. The tools do the real work. The loop continues until the agent reaches an answer, hits a limit, or is stopped.
That makes an agent similar to an automation workflow whose next step is chosen at runtime. This flexibility is useful. It also creates new failure modes.
Why your DevOps experience matters
Agentic AI uses new names for familiar problems.
A tool call is still an API request.
Agent memory is still state that can become stale or leak data.
A tool permission is still an access-control decision.
An agent loop is still a loop that needs a deadline and retry limit.
A model or prompt change is still a production change that needs testing.
The model is new. Production engineering is not.
Your advantage is knowing that successful execution is not the same as a correct outcome. A command can return zero and still change the wrong resource.
Three signals from this week
1. MCP is becoming easier to operate
The Model Context Protocol, or MCP, is a common way for AI applications to discover and call tools. Its 2026-07-28 revision makes the core protocol stateless, which means servers fit normal HTTP load balancers and gateways more easily.
For a beginner, the idea is simple: MCP is an adapter between an agent and a tool. It does not make the tool safe. Authentication, approval, retries, and permissions still matter.
MCP release notes and AWS compatibility guide.
2. OpenTelemetry now has an agent demo
OpenTelemetry Demo 3.0 includes an agent, an MCP server, and end-to-end traces. One trace follows a request through the model, tool calls, and downstream services.
This is a useful learning environment because you can see what the agent did. You do not need to connect it to your production systems.
Demo walkthrough and GenAI telemetry guide.
3. Agents are getting their own identity
Google Cloud now describes an agent as its own identity. AWS documents a separate authentication pattern for AgentCore.
You do not need these products to understand the lesson. Do not give an agent your personal token. You should be able to identify, limit, audit, and revoke the agent separately from the person using it.
Google Cloud’s agent IAM model and AWS’s JWT pattern.
One number this week: 83%
In Google Cloud’s survey of 1,402 global IT leaders, 83% said their organization needs infrastructure upgrades for production-grade autonomous systems.
This is vendor-sponsored research, not a neutral benchmark. Still, it is a useful signal: many companies can build AI demos, but they are not ready to operate them safely at scale.
Report summary and methodology.
Your first runbook: START read-only
Do not begin with an agent that restarts pods or changes cloud resources. Start with an investigation task.
S: Scope one task
Choose a narrow question such as: “Summarise the likely cause of this alert.”
T: Tools stay read-only
Allow metrics, logs, traces, and deployment history. Do not allow changes.
A: Audit every step
Record the question, model version, tool calls, inputs, outputs, time, and cost.
R: Restrict the loop
Set a deadline, tool-call limit, token or cost budget, and a manual stop control.
T: Test bad conditions
Try missing data, stale data, a failed tool, a timeout, and conflicting evidence. Check whether the agent admits uncertainty.
Your first success is not autonomous remediation. It is a useful answer with a trace you can explain.
Failure mode: a retry repeats the change
Later, when you add write tools, a timeout can become dangerous. The change may succeed while the response is lost. The agent sees a failure and tries again.
The control belongs in the tool, not the prompt. Use an idempotency key, which makes a repeated request return the original result instead of creating another change.
“Please do not deploy twice” is not a control.
Should we add hands-on labs?
I am considering starting weekly lab/project where we take up one Devops/SRE use case and try to implement Agentic AI for it, or maybe take up something on MLOps/LLMOps side and show you how to build it.
Reply to this issue and tell me:
What would make sense to you ?
Which DevOps and AI problems should become labs?
What should this newsletter include more or less of?
What would make Runbooks & Robots worth opening every week?
Looking forward to read your comments to this article.
Robot walks into an incident review
What to do Monday
Write down one investigation task that uses only read access.
List the tools and data the agent would need for that task.
Run or review the OpenTelemetry agent demo and follow one trace.
Closing thought
You are not starting from zero. Agentic AI needs the same discipline that made cloud systems reliable: narrow access, visible work, bounded execution, and safe failure.
Start read-only. Learn how the agent behaves. Add power slowly.