Skip to content

Blog

HolmesGPT Can Delete Your Cluster. Here's What Actually Stops It.

Banner image Banner image

HolmesGPT Can Delete Your Cluster. Here's What Actually Stops It.

In April, an AI coding agent deleted a production database in nine seconds. PocketOS founder Jer Crane had it running against a staging environment when it hit a credential mismatch, decided on its own initiative to "fix" the problem, and ran a delete against a Railway volume that turned out to hold live customer data. Asked afterward what happened, the agent wrote back a full account of which of its own rules it had broken: "I violated every principle I was given." The data was recoverable. The judgment call that led there wasn't.

That post reached the front page of Hacker News and stayed there, and the thread landed on the same conclusion the whole industry is circling right now: nobody had built a system where the agent's own carefulness was the last line of defense. The first time someone on your team asks Holmes to "restart the payment-service deployment," it works, and it feels great. The second question is the one that actually matters: what stops the exact same request from being "delete the payment-service deployment"? Or worse, what stops it from ever reaching your engineer at all, arriving instead as a payload hiding in a log line Holmes happened to read during an investigation?

We covered HolmesGPT as a production triage platform back in April, and the runbook feedback loop in June. Neither post touched what happens once you give Holmes write access. That's a different problem, and it turns out the HolmesGPT team already solved most of it — not with a system prompt telling the model to be careful, but with an architecture where the model's carefulness doesn't matter.

What the MCP 2026 Roadmap Means for Your Infrastructure

Banner image Banner image

What the MCP 2026 Roadmap Means for Your Infrastructure

The final 2026-07-28 MCP specification ships in two weeks. The release candidate has been locked since May 21st, which means the ten-week validation window the maintainers gave SDK authors and client implementers is almost up. If you're running MCP servers in production and haven't looked at what's actually in this release, that's the deadline you're working against, not some vague "sometime this year" future.

We already covered the headline change, the stateless protocol core, in a dedicated deep dive with the Kubernetes routing details. This post is about the rest of the release: what's shipping alongside statelessness, what's deprecated but not gone, and, more usefully, which of these changes need action from you before July 28 and which don't.

Banner image Banner image

Count how many MCP servers your team runs internally. Now imagine every new hire clicking "authorize" on each one, separately, the first time they touch it. Nobody designed that as an onboarding flow. It's just what happens when an authorization model built for one person connecting one personal tool gets dropped into a company with forty engineers and a dozen internal servers.

We've watched this play out at a few clients now. A new platform engineer joins, gets handed a laptop, and spends their first week clicking through consent screens for the internal Jira MCP server, the deploy-status server, the runbook server, and whatever else the platform team has stood up that quarter. Security has no central record of who approved what, because there isn't a "what" to record — approval lives in each user's own OAuth grant, invisible to anyone but them.

The Enterprise-Managed Authorization (EMA) extension to MCP went stable on June 18. It replaces that per-user model with something an identity team would actually recognize: the IdP decides who gets which server, once, and every client the user logs into inherits that decision automatically.

Golden Paths: Make the Platform the Easy Way, Not the Mandate

Banner image Banner image

Golden Paths: Make the Platform the Easy Way, Not the Mandate

A new service went from an empty repo to running in staging in twenty minutes. Scaffold, CI wired in, monitoring attached, deployed. The team next door filed an onboarding ticket for a new service that same morning and got a response three weeks later.

Both teams work at the same company, on the same platform. One found the golden path. The other found the ticket queue. And here's the part that should worry you if you run a platform team: the second team isn't going to file that ticket again next time. They're going to copy an old repo and hand-wire the parts themselves, because that's faster than waiting three weeks, even if it means drifting further from every standard you've built.

CLAUDE.md Is Two Files in One. Most Teams Are Only Using Half of It.

Banner image Banner image

CLAUDE.md Is Two Files in One. Most Teams Are Only Using Half of It.

If you've read the Karpathy CLAUDE.md post — the four rules, the 41% to 11% error rate reduction — you know why CLAUDE.md matters as a rules file. Write clear constraints, get better agent behaviour. That framing is accurate and it's useful.

But it's about half the picture. CLAUDE.md is also a configuration file for Claude Code. And the configuration half — memory blocks, MCP server declarations, tool permissions, hooks, custom slash commands, sub-agents — is where platform engineers have the most to gain. These features aren't available in AGENTS.md, Cursor MDC rules, or Copilot instructions. They're Claude Code-specific, and most teams either don't know about them or haven't made the connection between these features and what they'd actually want to do with them.

Git is the Source. Confluence is the Search Layer. Here's What Connects Them.

Banner image Banner image

Your engineers write markdown in Git. Your ops team lives in Confluence. Your AI agents query Confluence via MCP during incidents. You've been choosing between these audiences every time you write documentation — or maintaining two copies and watching them diverge.

There's a build step that eliminates the choice. This post shows you how to wire it up, and explains the one frontmatter block that makes every published page queryable by an AI agent without relying on fuzzy text search.

GitHub Copilot Has an AGENTS.md. Most Teams Don't Know It Exists.

Banner image Banner image

GitHub Copilot Has an AGENTS.md. Most Teams Don't Know It Exists.

There are somewhere north of 1.8 million active GitHub Copilot users. Most of them use it through VS Code or the GitHub web UI. Almost none of them have a .github/copilot-instructions.md in their repos — and that file would meaningfully change how Copilot behaves on every question they ask.

The file has been available since late 2024. GitHub documents it quietly. It doesn't show up in most tutorials. And for platform engineers who've spent time getting AGENTS.md right, it looks at first glance like a redundant thing. It isn't — it covers different surface area and reaches a different audience within your team.

HolmesGPT Knows What Your Runbooks Are Missing. Here's How to Fix It.

Banner image Banner image

Your runbooks are wrong. Not all of them — but the ones that matter most are the ones that don't exist yet. Every incident HolmesGPT handles without finding a matching runbook is a signal. Every Slack access request it can't resolve from policy. Every team repeating the same escalation pattern. That's your knowledge base telling you exactly where it's incomplete.

This post builds a closed-loop system that listens to those signals and drafts the missing runbooks — automatically, with human review before anything goes live.

Cursor MDC Rules: The More Powerful AI Context File You're Probably Not Using

Banner image Banner image

Cursor MDC Rules: The More Powerful AI Context File You're Probably Not Using

If you use Cursor, there's a good chance your repo has a .cursorrules file — a flat block of instructions that loads into every session. It works. But there's a newer format, .cursor/rules/*.mdc, that the flat file can't match: scoped rules that only activate when you're editing specific file types, multiple rule sets that coexist in the same repo, and front matter that controls exactly when and how each rule loads.

For platform repos with multiple languages, multiple concerns, and strict boundaries between what should and shouldn't change, the MDC format is meaningfully better. This post explains what's different and what a well-structured .cursor/rules/ directory looks like for a Kubernetes platform repo.

Spec First, GitOps Second: The Platform Engineer's Guide to BMAD

Banner image Banner image

Spec First, GitOps Second: The Platform Engineer's Guide to BMAD

Here's a pattern I see constantly with platform teams that have started leaning on AI: they skip straight to building. The security team needs vulnerability data in Prometheus so they can alert on critical CVEs in Grafana. Someone spins up a chat window and asks Claude to "write the ArgoCD Application for the tenable-exporter." No PRD. No architecture decision about secret management. No agreement on scrape interval or which clusters it deploys to. Just vibes and YAML.

And it works, kind of, for a while. Until the tenth iteration when the agent has lost context, the generated code contradicts a decision made in session two, and nobody can remember why they chose that particular pattern.

BMAD is the antidote. It's what happens when you take agile project discipline — upstream thinking before downstream building — and wire it into your AI workflow. And if you're already doing GitOps, the mental model maps perfectly: you don't kubectl apply before you know what you're applying. You shouldn't prompt an AI agent before you know what you're building.

49K reasons people are paying attention

BMAD-METHOD hit ~49,000 GitHub stars in June 2026 with v6.8.0 shipping in late May. It's the most-starred open-source spec-driven AI development framework right now — and it has a dedicated Platform Engineer agent (Sam) built specifically for Kubernetes, GitOps, and IaC workflows.