The problem: support bundles are powerful, but slow to analyze
When something goes wrong on a Digital Rebar endpoint, the first thing support needs is a support bundle. Until recently, making sense of that bundle took hours.
A Digital Rebar support bundle is a dense artifact. For a machine-related issue it contains the machine object, all associated job logs, the DRP version running on the endpoint, and the full content installed there. The traditional workflow was to load that bundle into a specially configured DRP endpoint so engineers could inspect it as if it were a live local machine. That process was thorough, but it required expertise and time — often an entire day or more for complex tickets. And any ticket touching VMware infrastructure almost always escalated to Michael, who owns most of the VMware content at RackN.
The bottleneck was not a lack of knowledge. It was the time it took to apply that knowledge repeatedly to each new ticket.
The solution: a Zendesk MCP and a bundle analysis skill
The fix was to give an AI agent direct access to the ticket system and teach it how to read a support bundle.
Michael built a custom MCP (Model Context Protocol server) for Zendesk. This lets Claude reach into the ticket system natively: fetch a ticket, summarize the customer message, pull down any attachments, and identify whether a support bundle is present. When a bundle is found, a second layer kicks in: a bundle analysis skill that knows how to extract the archive, walk through the log files and machine object, and look for what is wrong.
Critically, the skill does not stop at the bundle. It also dives into RackN’s source code, content library, and documentation to search for matching solutions. The result is a diagnostic that is not just faster than a human review, but draws from a wider surface area of institutional knowledge than any single engineer would reference in a first pass.
“It turns something that used to take hours or even multiple days into something that can often be done in just a few minutes.”
Michael Rice, Sr. Engineer, RackNThe entire flow is now a single prompt. An engineer tells Claude to grab ticket 1234, pull any support bundles, and analyze them. Claude fetches the ticket, summarizes the customer message, pulls the attachment, recognizes the bundle, activates the bundle skill, and returns a structured diagnosis with suggested fixes. The escalation chain that used to run from the front-line support team to Michael has been replaced by a skill that any support team member can invoke.
Domain knowledge as code: ESXi and beyond
The bundle skill is the foundation. The real leverage comes from stacking domain-specific skills on top of it.
A generic bundle analysis is useful, but infrastructure support is not generic. A VMware ESXi installation failure and a Linux configuration drift are different problems that require different diagnostic paths. Applying the same broad troubleshooting checklist to both wastes tokens and time on irrelevant hypotheses.
Michael’s approach is to make domain knowledge explicit and composable. When the bundle analysis skill identifies that the machine in question is running ESXi, it routes to a separate ESXi-specific skill that carries deep knowledge of VMware installation patterns, configuration requirements, and known failure modes. The AI agent skips the Linux-specific branches entirely and goes straight to the right diagnostic surface.
That same pattern scales to any technology the platform supports. OpenShift skills, bare metal firmware skills, and RAID configuration skills can all be developed and added to the routing layer. Each skill is essentially a structured knowledge transfer: senior engineers document their diagnostic logic in a form the AI can apply consistently and at scale.
What this means for customers right now
Faster triage is not just an internal efficiency win. It directly changes the quality and speed of the response a customer receives.
Before this system, a VMware-related ticket would be received by the front-line support team, escalated to Michael, sit in a queue while he dug through logs, and eventually produce a diagnosis after a day or two of investigation. Now the support team invokes the skill stack directly and returns a detailed, domain-accurate response without escalation, often within minutes of the ticket arriving.
The AI does not always get it exactly right on the first pass. But even when it misses, it typically identifies the relevant subsystem and eliminates large categories of unlikely causes, pointing the engineer in the right direction faster than starting from scratch. The iteration loop between AI-assisted diagnosis and human review is significantly shorter than the old all-manual approach.
| Metric | Before | With AI skill stack |
|---|---|---|
| Time to initial diagnosis | Hours to multiple days | Minutes |
| VMware tickets requiring escalation | Most | Significantly reduced |
| Knowledge required by support team | Senior-level domain expertise | Skill invocation |
| Diagnostic coverage | Varies by engineer on duty | Consistent, cross-referenced |
Where this is headed: AI inside the platform
The current workflow still requires a human to initiate the prompt. The next iteration removes that step entirely.
This is the architecture shift at the core of what Michael is building: moving from AI as a support tool that engineers use reactively, to AI as a first-class operational layer that the platform ships natively. The Zendesk MCP is the prototype. The in-product agent will be part of the product.
The model strategy: Opus plans, Sonnet and Haiku execute
Getting cost-efficient results from a multi-step agentic workflow requires the right model at each stage.
Michael runs his workflow in Claude Code using Opus Plan mode. Opus handles the planning phase: it reads the ticket, identifies the relevant skills, and writes a detailed step-by-step execution plan specifying which files will be created, what inputs and outputs are expected, and what tests will be run. The plan is precise enough that Sonnet or Haiku can then execute it by essentially writing the already-described files to disk.
Because Opus has already resolved the reasoning, the execution model does not need to re-derive the approach. It uses fewer tokens and produces reliable results. The cost of the high-capability model is concentrated where it matters — in planning — while the high-volume execution steps run on faster, cheaper models. For teams building agentic workflows on top of complex infrastructure systems, this layered model strategy is worth adopting deliberately rather than defaulting to a single model for everything.
