The phone lights up on the nightstand at 2 AM. A server acts sus and goes offline — no warning, no context, just an alert from whatever on-call stack you're running: PagerDuty, Opsgenie, Slack, take your pick. Not the dying that's the problem — things die. The problem is what happens in the next twenty minutes.
The on-call engineer opens the first window: vCenter. The VM is gone. Okay. Which host was it on? Click through the inventory. alpha1-esxi-90. How many other VMs are running on that host right now, and are any of them production-critical? Back to the search, filter, cross-reference. The clock is running.
Who owns this thing? Second window — the CMDB, or whatever passes for one this week. The entry is stale. The owner field says "Infrastructure." The contact hasn't worked here in eighteen months. Third window — a spreadsheet someone built two years ago during an audit and never updated. Maybe it's in there. Maybe it's not.
What network segment is it on? Is there a certificate tied to it that just lost its upstream connection? Is there another service depending on it that's about to cascade? Fourth window. Different tool. Different login. Different mental model entirely.
Twenty minutes later, the answer to what broke took longer to find than the actual fix. And somewhere in the middle of all of it, you opened a terminal session just to verify what the GUI was already telling you. The data existed the whole time. It was just scattered across four systems that have never been introduced to each other.
"A VM goes down at 2 AM. The on-call admin doesn't know what's on it, who owns it, what network it's on, or whether the host has other critical VMs. They're clicking through four tools while the clock ticks."
I've lived this. Every infrastructure engineer reading this has lived this. And the thing that kept nagging at me, as I started mapping out my VMware Explore 2026 experience, is that the data to answer all of those questions already exists. It's sitting in inventory exports, certificate check scripts, patch baseline files, VLAN tables. The problem isn't that the information isn't there. The problem is that you can't have a conversation with it.
What if you could just ask?
That's the premise of what I'm building for the VMware {code} Hackathon at Explore 2026 in Las Vegas, running Monday evening August 31st.
The project is a conversational intelligence layer over a unified VMware infrastructure data store — built on top of Anthropic's Model Context Protocol (MCP) and the Claude API. Instead of four open windows and twenty minutes of cross-referencing, you ask a single question in plain English and get a single answer that synthesizes across all of it.
Three questions I want this thing to answer live on the demo floor:
Each of these queries crosses at least two data sources to answer properly. In the current world, that means multiple tools and a human doing the mental join. In this project, Claude reasons across the data, calls the right tools in the right order, and returns a narrative answer — the kind of answer an engineer would write, not a raw data dump.
The thing that doesn't wake anyone up
The 2 AM scenario is urgent. You know something's wrong. Someone's paging you. But there's a different category of infrastructure problem that never trips an alert, never generates a ticket, and never appears in a status dashboard. It just sits there.
A few weeks ago, a question surfaced in our Slack channel about a server nobody could place — RPT-ARCHIVE-04. Someone looked it up. It was built for a specific person, for a specific reporting task. A task to retire it had been opened years earlier, quietly filed and forgotten.
That task was never closed.
The server had been powered on, backed up, patched, and scanned for vulnerabilities every single month since. No active workload. No owner on record. No documented purpose. Sixty-eight months after the last person who needed it stopped needing it, it was still running — quietly consuming storage, backup windows, patch cycles, and licensing headroom.
Someone did the math out loud in the channel — six full years of just sitting there, untouched, since anyone last needed it.
Someone on the team dropped a GIF of a guy on a beach in a floppy sun hat, margarita in hand, not a care in the world. It was the right call. And at roughly $2,300 per year in licensing, storage, backup overhead, and patch admin time, it was approximately a $13,000 punchline. Within two messages, someone had already spotted the next one.
after retirement
one server
per zombie found
in our environment
The unified inventory portal this project is built on now scores every one of those 300-plus servers against a five-flag zombie model. Unowned. Undocumented. Powered off. Deallocated in Azure. Unknown power state with zero CPU allocation. Flags accumulate. A score emerges: Watching, Suspicious, or Zombie. It runs automatically on every inventory load. No audit required. No spreadsheet. No one has to notice.
Which surfaces a fourth demo query — one that every person in that hackathon room on August 31st is going to feel in their chest:
Every infrastructure team has an RPT-ARCHIVE-04. Most of them haven't found it yet. The conversational layer doesn't just answer operational questions — it surfaces the financial ones that nobody thought to ask. That is not a subtle thing.
Why this, why now
The 2025 VMware Explore Hackathon winner built something similar in spirit — an MCP server that let admins query live vSphere data through a conversational interface. The judges saw it and immediately understood it. That's the tell. When a room full of infrastructure engineers sees a demo and nods, you've found the real problem.
The arc is clear: every year the hackathon pushes further toward AI-native tooling for practitioners. Not AI for its own sake, but AI that closes the gap between where the data lives and where the decision needs to happen. The 2 AM scenario isn't a contrived demo hook — it's Tuesday.
What I'm adding to the conversation is something the prior work didn't quite reach: the data layer isn't live vCenter queries, it's a unified inventory built from sources already in motion — PowerCLI exports, RVTools data, cert check outputs, patch baselines. The kind of data every shop already generates. The question is whether you can make it talk back.
The architecture in one sentence
An MCP-powered conversational layer over a unified VMware infrastructure data store that answers operational questions in plain English — no dashboard-clicking required.
The implementation stack is deliberately lean: Python for the tool layer, four JSON data files as the backing store, the Anthropic API for reasoning, and a Streamlit chat interface that takes maybe thirty minutes to wire up. The complexity budget goes where it matters — the tool functions that actually know how to traverse the data and the system prompt that teaches Claude to think like an infrastructure engineer at 2 AM. The longer arc, one that's already starting to take shape, is what happens when the layer stops just answering questions and starts acting on them.
What comes next
The concept is locked. The architecture is designed. Between now and August 31st, the work is building the sanitized demo dataset, wiring the MCP tool functions, and rehearsing the three demo queries until they run cleanly in front of judges. There's also the matter of assembling a team — more on that in the next post.
The hackathon runs 7 PM to 11:30 PM on Monday, August 31st, in the Venetian Convention Center. Teams build, judges review, and somewhere around 11 PM someone stands at a podium and gives a five-minute presentation. I intend to be in that room with something worth showing.
Whether it wins is a secondary question. The primary question is whether someone in that room — someone who has been that on-call engineer at 2 AM — looks at the demo and says yes, that's the problem, I want that.
That's the only metric that matters.