Why I Went Back to Nutanix
On October 12, 2026, I rejoined Nutanix. From the outside it can look like a loop back to where I started. From the inside it's the most direct line I've drawn in fifteen years: the hardest problem I hit building agentic AI turned out to be a storage problem, and storage is where I come from.
Thesis: The bottleneck in agentic AI isn't the model. It's context: where it lives, how it's shared, and how many agents coordinate around it without corrupting it. Those are storage and data problems wearing new clothes, and that's why I went back to my storage roots.
Nutanix, the first time (2011–2020)
I joined Nutanix in 2011 as one of its early employees, after my first conversation with Dheeraj Pandey about collapsing enterprise infrastructure into software on commodity hardware. Hyperconvergence went from "that's a toy" to "that's how everyone builds datacenters", and Nutanix went from a scrappy startup to a multi-billion-dollar public company, with its IPO in 2016.
The work I'm proudest of from that era is the Nutanix Bible. It was a deliberate bet that explaining exactly how the system worked — the distributed storage fabric, how data is placed, replicated and kept consistent — would build more trust than any NDA-protected whitepaper. It became the reference for how a new category was understood.
What I took from those years wasn't a product. It was a way of thinking: state is the hard part of any distributed system. Compute is easy to move. Data has gravity, it has to be durable, it has to be consistent across nodes that fail, and everything else in the system is shaped around where it lives.
DevRev: building from the beginning (2020–2025)
In 2020 I wanted two things I couldn't get by staying. I wanted to go deep on engineering with AI, and I wanted to build a company from the very beginning rather than join one that already worked. When Dheeraj started DevRev, I went with him.
Building that early teaches you what a mature company hides: every system you take for granted is a decision someone made, usually under pressure. It's also where I went deep on engineering with AI.
Ema: doubling down on AI (2025–2026)
By 2025 I wanted to double-click on AI itself, not AI as a feature inside another product, but AI that owns outcomes. That took me to Ema and to building agentic AI employees.
This is where the lesson landed. The hard part wasn't the model. It was everything around it:
- Storing context. An agent that runs for hours accumulates history, and the history becomes a liability long before the window is full. The pattern I trust is moving memory out of the window and onto disk, as I wrote in The Files Are the Memory and Three-Tier Context.
- Coordinating context. Knowledge baked into a tool or a prompt goes stale the moment the business changes. It has to live in a service with its own lifecycle, the argument in Externalize the Knowledge.
- Coordinating agents. Several agents working on one goal need a shared, consistent view of what is true and what has been done. Most "multi-agent" systems skip that and pay for it, which is the point of The Multi-Agent Illusion and .ctx: Memory for Amnesiac Agents.
Read those three bullets again with a storage engineer's eyes. Durable state. Shared state with a lifecycle. Many writers that must agree on what is true. They're the problems a distributed storage system exists to solve, now showing up one layer higher, in the context agents run on.
Why that leads back to storage
Context for agents is becoming a data tier. It needs the things every serious data tier needs:
| What agents need from context | What storage has always had to provide |
|---|---|
| Memory that survives a crash or a restart | Durability |
| Many agents reading and writing the same facts | Consistency across concurrent writers |
| The right context close to where the agent runs | Locality and placement |
| Knowing which version of a fact an agent acted on | Versioning and snapshots |
| Who may see which context, and an audit of who did | Access control and auditability |
I spent nine years in a company whose whole job was making those properties true for enterprise data. That's the work I want to be close to again, applied to the context agents depend on, and it's why I'm excited to be back at Nutanix focusing on those pieces: how context is stored, how it's coordinated, and how agents coordinate around it.
When the opposite wins
There is a credible counter-view: context windows keep growing, so maybe context becomes a model problem and storage stops mattering. Give a model ten million tokens and let it hold everything.
I don't think that holds for long-running, enterprise agents, for three reasons. First, bigger windows degrade before they fill: Chroma's Context Rot study, which I wrote about in The Files Are the Memory, found models degrading well before the window is full, and that's why I stopped trusting accumulated history. Second, a window belongs to one run of one agent. The moment two agents, or two runs, need the same facts, you are back to shared state. Third, enterprises have to answer "what did the agent know, and who allowed it to know that" — a governance question a window can't answer and a data tier can.
Where the counter-view does win is in short, single-agent tasks with no shared state. If that describes your workload, a long window is the simpler answer and you should take it.
What to do next
- Find where your agents' context actually lives. If the honest answer is "in the conversation", you have a durability problem you have not hit yet.
- Separate memory from the window. Write what an agent must remember to durable storage it reads back deliberately, rather than letting history accumulate.
- Treat multi-agent coordination as shared state. Before adding a second agent, decide where the shared facts live and how concurrent updates are reconciled.
- Ask the governance question early. For any agent in production, be able to say which context it acted on and who granted access to it.
This is my own living context of what I've learned building with AI; the views here are mine, not Nutanix's. The posts behind each step are linked above, and the earlier chapters of the story are in Why I Joined Ema and About Me.