Overview
A two-week side experiment that became a product direction: agentic AI for infrastructure at datacenter scale, plus a new way to measure success when the screens go away. Internal demo done, buy-in secured, alignment with sibling teams in progress. Constraint: prototype, not shipped — the heuristics are argued, not yet proven on a live cohort.
Disclaimer: This is an internal proof of concept and not a guaranteed or committed feature. As IBM is a publicly listed company, nothing here represents a product announcement, roadmap commitment, or official documentation. Please read the following strictly as a design case study — every workflow and dataset shown is mocked.
Context, "the machine"
One mainframe. Up to 85 logical partitions, think C:/D: drives, at datacenter scale. I design the infrastructure layer for IBM Z & LinuxONE.
Three personas run it, all engineering-heavy:
- Partition owner
- Hypervisor admin
- Virtualization admin
How I got the evidence
This wasn't desk research. I ran mixed-methods research directly: I personally interviewed banking customers across Europe, and ran surveys with insurance providers in India, grounding the work in qual and quant, and going to find the data when it wasn't handed to me.
Worth saying plainly: the customers on the other side of those interviews were banks. Regulated, risk-averse, and unforgiving about being wrong. It taught me how much of a financial institution's product thinking is really trust management wearing a different hat.
The problem, five cracks
Countless customer calls, interviews and in-person workshops kept surfacing the same five things. Individually they're complaints. Together they're a product about to be overtaken.
| The crack | What it actually means, first principles |
|---|---|
| Experts are retiring. Customers with 40–50 years of experience, often more than the engineers building the product. | The knowledge lives in people, not in the product. The interface has to carry the expertise. |
| The new workforce won't live in black-and-green terminals. Our Carbon revamp was catch-up, not a leap. | Adoption is now a UX problem, not a capability problem. |
| 6-month to 2-year release cycles. One new dashboard component means a half-year wait. | The UI is hard-coded, so every customer need is a dev ticket. |
| Intent → outcome is a marathon. "Attach storage" means a cascade of screens. | The workflow layer is a tax. Screens are steps, not value. |
| Engineering is shifting from execution to orchestration, the product hasn't. | Users want to decide, not operate. |
The signal
"When I want 500 GB attached to a partition, I want it right away." — sponsor user
And from leadership, the question that set the ceiling for the whole thing:
"The infrastructure automation layer has sibling products, will yours orchestrate them, or be orchestrated by them?"
Second-order thinking
Before designing anything, I made myself answer four "what if" questions. Not features, consequences.
- What if dashboards had zero development dependency, UI generated on demand?
- Chat is becoming the enterprise interface. What if chat is the primary way of interacting, not a helper pinned to the corner?
- We missed the UI wave, and simplification-by-design is us paying for it. What if we miss the AI-fication wave too?
- What if another product becomes the interface for ours, or ours for theirs?
That third question is the one that got the room. The cost of being late isn't hypothetical for this product, we've already paid it once, and everyone in the room had lived through paying it.
The solution, four moves, every crack answered
| Move | Which crack it closes |
|---|---|
| Generative UI, dashboards compose on demand, assembled from conversational input rather than shipped as code. Prototyped directly in code, not mocked. | Kills the dev dependency and the release-cycle wait. |
| Intent → outcome in chat, prompt it, confirm it, done. No screen cascade. Complex operations like partition creation become a fluid conversation. | Closes the intent–outcome gap, and lowers the expertise floor the retiring experts leave behind. |
| Delegate to agents, "host update available" becomes a task you assign to an agent, which resolves it and comes back for approval. You stop clearing notifications and start approving outcomes. | Execution → orchestration. |
| Open interface, both ways, orchestrate sibling products from here, or be orchestrated by them. | Answers leadership's question directly, instead of waiting to be answered by it. |
The part I didn't expect, measuring success without screens
Building it forced a problem I hadn't planned for. Traditional UX metrics quietly stop working when you remove the screens. Time-on-task and error rate assume a user is operating something. When the user states an intent and an agent executes it, time-on-task measures the model, not the experience, and a low number can mean the product is great or that the user gave up.
So I wrote a new set of agentic heuristics and engagement metrics for non-workflow, intent-based interaction. I submitted the work to HCI International 2026; the paper was accepted for presentation.
This is the outcome I'm proudest of, and it isn't the UI. The experiment didn't just change a product interface, it changed how we evaluate whether a user succeeded in an AI-first product. The interface was two weeks. The measurement problem is the one that outlives it.
How I worked
No Figma. No dev hand-off. The whole thing is an end-to-end working prototype, built with Bob, IBM's internal AI-based IDE, on pixel-perfect Carbon components, with realistic but entirely mocked workflows and no real customer data.
In an enterprise the size of IBM, you're never the only person thinking about a problem. Rather than find out later, I went looking: I reached out to the AVS team and connected with engineers already building with agentic AI. I wanted their developer-centric perspective specifically because it contradicted mine. My designer-first assumptions and their engineering assumptions disagreed on a lot, and the tension made the final experience more robust and more user-centric than either version alone.
The design system work around it
InfraX sits on Carbon, and I don't just consume it:
- I authored the Carbon Data Table Figma plugin, now used by 200+ IBM designers, contributing reusable, data-dense patterns back to the system.
- I built an internal MCP server for the Carbon Design System, so agents build inside the system by default rather than approximating it.
- I drove adoption of Bob among non-designers in the IBM Z org.
- I led a strata-map audit across the infrastructure-automation layer, framing gaps and opportunities with product and executive leadership.
The MCP server is the through-line of my whole practice: I'd rather build the thing that makes the team right by default than be the person who's individually careful. Use the system, contribute to it, and push back when it's wrong.
Where it stands, and what I'd do differently
- Prototype, not shipped. Internal demo done, buy-in secured from my design lead and manager, then carried to higher stakeholders.
- Now auditing the infrastructure layer with sibling product teams, merge and alignment in progress.
- The honest gap: the agentic heuristics are argued, not yet proven against real usage. I'd want a live cohort before I'd defend the metrics as right rather than better than time-on-task.