Azure VM Control Plane Outage, GitHub Agent HQ (Claude + Codex), Claude Opus 4.6, Gemini CLI, MCP

Transcript

This week felt like AI went from cute helper

to, okay, this is now part of the platform, not

just in your IDE. It's showing up in CI, incident

response, and in the places where mistakes become

expensive. Also, Azure had one of those outages

that doesn't just break a service. It breaks

your ability to operate the service. And that

one always hits different. Welcome back to Ship

It Weekly. I'm Brian from Tellers Tech, and this

is Ship It Weekly, the DevOps and SRE news show

for people who actually get paged. All links

are in the show notes on shipitweekly .fm. And

a quick ask up front. If you're getting value

out of the show, hit follow or subscribe wherever

you listen. And if you're on Apple Podcasts or

Spotify, a rating helps a lot. Even a quick review

is huge for discoverability. All right, five

main stories for today. One, the Azure control

plane incident and why it creates the most annoying

type of failure. Two, GitHub leaning harder into

multi -agent dev with Claude and Codex in the

loop, plus actions getting a little less painful.

Three, Claude Opus 4 .6 and the real difference

between better model and new failure mode. Four.

Google talking openly about SREs using Gemini

CLI during outages. Five, the connective tissue

story, MCP as plumbing, and observability getting

pulled into the AI platform gravity well. Then

we'll do a lightning round. Then a quick follow

-up on Ingress Engine X and N8n since we covered

those in previous episodes. And we'll close with

a human closer around trust, guardrails, and

why - why agentic work is not a free lunch. Story

one, Azure incident. VM management ops gets weird

and that ripples everywhere. So what happened?

Azure had a platform incident that impacted VM

management operations across multiple regions.

So not a VM went down. More like the thing that

manages VMs is degraded. Create, update, scale,

start, stop. The day two operations that every

platform team builds automation around. And when

that gets weird, you feel it everywhere because

it's not just VEBS, it's auto -scaling, it's

instance group updates, it's node pools trying

to heal, it's pipeline steps that assume I can

always start a node or I always roll a deployment.

So why does it matter? This is the outage category

I hate the most because it creates misleading

symptoms. Your app might look up. Your load balancers

are still answering. Your metrics are fine until

they aren't. But deploys start hanging. Scale

-outs don't happen. Rollbacks don't apply cleanly.

And you end up in this gray zone where everyone

is arguing about whether it's our code or the

cloud. And here's the key point. Most teams build

reliability thinking about the data plane, requests,

latency, error rates, but control plane failures

break your ability to respond. If you can't change

the system, you can't mitigate. And it turns

a 15 -minute incident into a two -hour incident

purely because you can't operate your own platform.

And if you've ever been stuck in a loop where

you're trying to fix something and all your fixing

tools are failing too, that's what this is. So

what do you do Monday? Go look at your automation

paths and ask a boring question. What happens

when the control plane is slow or degraded? Do

you have retries with exponential backoff? Or

do you have hammer it until it works? Do you

have timeouts that fail safely? Or do you have

jobs that hang forever? Because a lot of people

accidentally build infinite retry storms into

their pipelines. And the control plane is exactly

where that becomes self -inflicted pain. Also,

do you have a decision point in your incident

process that says, stop trying to change the

system, stabilize, communicate, wait for the

provider? That's hard to do because it feels

like giving up. But sometimes it's the correct

move. And one more thing. If your response plan

assumes you can always add capacity or always

recreate nodes or always scale out, make sure

you have a mitigation that doesn't require that.

Sometimes the right move is degrade features

instead of add servers. Sometimes it's shift

traffic instead of rebuild. And you only learn

that when you talk through it before the outage.

All right, that's story one. Story two is GitHub

leaning into multi -agent dev. And there's a

bunch of practical implications for platform

teams hiding under the surface. So story two

is GitHub multi -agent in the workflow, plus

actions getting less painful. What happened?

GitHub rolled out AgentHQ support for using Anthropic

Cloud and OpenAI Codex in GitHub and VS Code

alongside Copilot. So instead of co -pilot only,

it's more like pick the agent that's best for

the job. And GitHub Actions shipped workflow

updates too, including a case function in Expressions.

If you've ever had a workflow where the logic

is basically a pile of nested ands and pipes,

you probably just felt your shoulders drop a

little. So why does it matter? Two reasons. First,

multi -agent is an emission of reality. People

are already switching between tools. Cursor.

Copilot, Claude Code, whatever. Different models

are better at different things. Some are better

at refactors. Some are better at reasoning through

messy requirements. Some are better at quick

code completion. GitHub putting multiple models

in the same surface is them trying to become

the control plane for AI -assisted development.

And if you are a platform team, that matters.

Because the moment these tools can open PRs and

modify workflows, they are part of your software

supply chain. Second, actions changes matter

because CI is still where a ton of production

risk lives. Workflow changes are not just developer

productivity. They are permissions. They are

secrets. They are build artifacts. They are deployment

paths. So if you are enabling AI agents in that

world, you should treat it the way that you treat

any automation. Not cool, ship it. More like

cool, what's the blast radius? So what do you

do Monday? If you want to test agent PRs, do

it like onboarding a new engineer. Start with

read -only or low -risk tasks. Have it summarize

failing CI. Have it draft release notes. Have

it propose a change and explain why, but don't

let it merge. And keep it out of workflow files

and infra repos until you've decided what your

governance is. Because workflow files are basically

production code. Now, about that case function.

That sounds tiny, but here's what it really buys

you. It lets you reduce clever logic and replace

it with readable logic. And readable CI is safer

CI. Because the number of incidents that start

with why did this deploy to prod is not zero.

If your CI logic is hard to reason about, you

are one sleepy reviewer away from a bad day.

Also, a quick mid -episode reminder. If you are

enjoying the show, hit follow or subscribe. It's

a small thing, but it helps a ton. That's Story

2. Story 3 is Opus 4 .6. Story 3 is Opus 4 .6,

and I want to talk about this in a way that's

actually useful, not just the new model dropped.

Claude Opus 4 .6, the real change is trust and

longer running work. Anthropic released Claude

Opus 4 .6. They are positioning it as better

at agentic tasks, longer horizons, more reliable

multi -step work, more give me a goal, I'll do

a thing behavior. So why does it matter? Here's

the trap. When people say better model, a lot

of folks hear cool, the answers will be a little

smarter. But the bigger shift is behavioral.

When the tool gets good enough, people start

delegating bigger chunks of work. Not rewrite

this function, more like implement this feature.

Or refactor this module. or update these workflows

or go fix the failing tests and that's where

the failure mode changes because now it's not

the assistant gave me a wrong answer it's the

assistant completed a plan that was subtly wrong

And it did it confidently. And it did it across

15 files. So now you've got to do a different

kind of review. Not just does this compile, more

like does this match intent? And also, did it

change anything surprising? Because agents are

really good at making changes that look plausible.

So what do you do Monday? If you are using these

tools seriously, I think teams need a new habit.

Spec first, even lightweight. Before you let

the agent touch the repo, you want a short plan.

What are you changing? Why? What does done look

like? What are the risks? What test will it prove?

Because without that, the agent will happily

fill in the blanks with something that feels

right, but isn't. Also, decide what you consider

sacred ground. for a lot of teams that's ci workflows

iam network policy and anything that changes

prod deployment behavior if an agent is going

to touch those that should be behind stricter

review two humans minimum no auto merge and probably

a show me exactly what changed and why requirement

and if you are a security minded org this is

the week to remind people AI capacity upgrades

help defenders and attackers. It's easier to

find bugs. It's easier to exploit them, too.

So the defense is still the same boring stuff.

Least privilege, secrets hygiene, fast patching,

and not letting random automation have right

access to the keys to the kingdom. That's story

three. Story four is Google talking about SREs

using Gemini CLI in outages. And this is where

the AI and the ops conversation gets real. Google

SREs Gemini CLI as an outage sidekick. What happened?

Google published a write -up on SREs using Gemini

CLI during real outages. The framing is basically

AI in the terminal as an incident companion.

They're using it to classify symptoms, pull context,

suggest mitigations, and reduce the early incident

chaos. So why does it matter? This is the direction

a lot of teams want to go, even if they're not

saying it out loud. Because the hardest part

of incident response is not typing commands.

It's context. What changed? What's impacted?

What are the known safe mitigations? What's the

fastest way to reduce customer pain? And under

stress, humans drop context. We forget what we

already tried. we lose track of timelines. We

waste cycles writing status updates that are

vague because nobody has the full picture. So

the AI as scribe idea is actually super compelling.

You let the tool do the relentless bookkeeping.

Summarize logs, pull the last deploy, list recent

config changes, draft a timeline, draft a status

update. draft a mitigation checklist based on

the runbook. If you can reliably do those things

faster, you've bought the human's time to think.

And time to think is basically MTTR reduction.

But there's an obvious danger. The moment you

let AI run commands, you have to treat it like

any other automation with prod access. You don't

give it a shell and vibes. You give it narrow

tools. And you build guardrails. So what do you

do Monday? If you want to copy this pattern without

being Google, start with the safe version. Make

an incident helper that is read -only. It can

query logs. It can query metrics. It can pull

deployment history. It can draft comms. And it

can suggest mitigations from the runbook. But

a human has to execute. That alone is valuable.

And it's a good stepping stone. Because the minute

you jump straight to AI executes mitigation,

you are going to have trust problems. And trust

problems become adoption problems. And then this

whole thing turns into a failed experiment. So

start small, prove it helps, and build from there.

that's story four story five is the this will

matter more over time story mcp and the platform

layer that's forming around agents ai is becoming

platform plumbing mcp governance and observability

consolidation We are seeing vendors rally around

MCP, the Model Context Protocol, as a way to

connect agents to tools and data sources. Miro

launched an MCP server story to connect collaboration

artifacts into AI coding tools. Kong announced

an MCP registry angle for governance and tool

discovery. So we are moving towards a world where

agents can be given tools in a standardized way.

and in parallel observability is getting pulled

into the ai orbit moves like snowflake planning

to acquire observe are basically saying telemetry

is data and we want ai sitting on top of it so

why does this matter let me translate mcp into

normal person ops language it's basically a standard

way to say here are the tools an agent can use

here's how it calls them and here's the context

it can see And if that becomes common, platform

teams are going to have a new inventory problem.

What agents exist? What tools do they have access

to? What credentials are behind those tools?

What data sources are exposed? What's logged?

What's audited? And who owns the thing when it

breaks? Because if you don't handle this like

a real integration layer, you will end up with

shadow agents the way we ended up with shadow

CI jobs and shadow admin access. And on observability,

the shift is also real. More companies want log

retention. They want to correlate telemetry with

business events. They want to ask what changed

across logs, traces, config, and deploy history.

Then they want AI to help explain it. That's

powerful. But it also turns observability into

governance. PII risk, access controls, data retention

policy, cost controls. Because if you keep all

telemetry forever, you can easily build a compliance

nightmare and a gigantic bill. So what do you

do Monday? If MCP is showing up in your org,

treat it like production integration, not a toy.

You want ownership. You want access controls.

You want an inventory. You want a default deny

stance. And you want audit logs. Because the

first time an agent does something surprising,

the only thing that will save you is knowing

what it did and why. And for observability, if

you are exploring AI there, don't start with

let's let a model roam through prod logs. Start

with specific measurable wins. Better incident

timeline creation. Better alert deduping. Better

correlation across services. Faster what changed

answers. Then measure if it actually reduces

pager pain and toil. All right, time for the

lightning round. All right, lightning round.

GitHub Actions hosted runners had an incident

this week where jobs queued, timed out, and people

had a rough morning. It's a good reminder that

hosted is not the same as immune. If CI is business

critical, know what your fallback is. Docker

patched an Ask Gordon issue. And even if you

don't care about the specifics, the theme matters.

If you're feeding AI systems untrusted input,

including metadata, you can accidentally build

a prompt injection path into your workflow. Treat

AI inputs like any other untrusted input. Terraform

1 .15 alpha dropped. Not a headline, but worth

noting for platform folks. Deprecation warnings

for variables and outputs is the kind of feature

that makes shared modules easier to evolve without

surprise breaks. And Wiz wrote up the Malt Book

situation. Misconfigured backend. Tons of exposed

API keys and sensitive data. It's a perfect vibe

coding meets production credentials cautionary

tale. Also, a quick mention from the open source

side. Chainguard's Ameri -OSS effort is an interesting

trend. Commercial orgs stepping in to maintain

projects that everyone depends on, but nobody

wants to own. You don't need to have a strong

opinion on it yet, but it is worth watching.

And a couple of quick follow -ups. Ingress Engine

X had multiple issues disclosed and fixed versions

called out. If you run Ingress Engine X, double

check your versions and patch. And N8n is still

in the patch fast and treat your automation layer

like a control plane category. If you are running

workflow automation tools, assume they are part

of your perimeter. And here's the human theme

this week. We keep talking about agents like

they remove humans from the loop. They don't.

They move humans to a different part of the loop.

The hard part is shifting from can I run the

command to can I decide what to trust? And then

can I recover cleanly when the automation does

something confidently wrong? Because with agents,

the risk isn't the tool is dumb. The risk is

that the tool is competent enough that people

stop double checking. And the first time that

that happens in pride, you get a weird kind of

incident. Not a bug. Not a bad deploy. More like

automation drift. Everyone thought the automation

was safe. Then one day it does the wrong thing

and nobody notices until it's already rolled.

So if you are adopting this stuff, the boring

work is the real work. Guardrails. Approvals.

Ownership. Audit trails. And clear stop the line

rules. Because the future isn't no humans. It's

humans overseeing more automation. And that's

its own skill. All right, time for a recap. We

had five main stories for today. Azure reminded

us the cloud control plane is part of the product,

and it can absolutely be your incident even when

your app is fine. GitHub is going multi -agent

with Claude and Codex, and Actions got a little

less painful with better workflow logic. Opus

4 .6 pushed agent workflows further into the

mainstream, and the real risk is trust and multi

-step changes. Google is using Gemini CLI in

real SRE outage work, which is basically the

AI and ops playbook taking shape. And MCP plus

AI -driven observability is turning into platform

plumbing. And platform teams are going to own

governance whether they want to or not. And the

lightning round was GitHub Actions hosted runners

having an incident, Docker patching an Ask Gordon

AI supply chain issue, Terraform 1 .15 alpha,

the Malt Book credential exposure story, and

the Emirate OSS maintenance trend. All links

are in the show notes on shipitweekly .fm. If

you made it this far, hit follow or subscribe

wherever you are listening. And if you can, drop

a rating or review on Apple or Spotify. It helps

more than you think. All right, I'll see you

next week.

Azure VM Control Plane Outage, GitHub Agent HQ (Claude + Codex), Claude Opus 4.6, Gemini CLI, MCP

Watch this episode here

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

More from Ship It Weekly

Ship It Conversations: Gareth Kersey on IaCConf 2026, AI, and Corey Quinn’s Terraform Keynote

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

containerd CRI Vulnerabilities, Datadog PostgreSQL HA on Kubernetes, AWS DevOps Agent with Datadog MCP Server, EKS Control Plane Egress, and Why Users Feel the Wait

Get the next episode in your inbox