I’ve talked a lot about the advantages of Nutanix’s architecture, and at some point I’ve appealed to reason, I’ve appealed to revenue, I’ve appealed to existence, but I haven’t really explained the nuts and bolts of why. This past week, I conducted an experiment on using various AI technologies to design a feature, and the consequences of that experiment provided me an excellent way to surface the architectural advantages of our system.
Our system, as those who have read the Nutanix Bible know, is essentially a distributed system with a collection of microservices sitting on top of a six nines available database. But one of the pieces that people don’t know about as much is Ergon, which is essentially our task system. What Ergon does is it provides a mechanism for you to create a task, and then it creates sub-tasks, and everybody can synchronize on those tasks. You create a task, and then that task gets turned into sub-tasks, and everybody knows exactly where everybody else is with respect to the top-level task. The other property of the task system is it’s idempotent. In other words, if I create a task, the same task will only be created once.
Now that we know that system exists, what does it mean? In a traditional way of building microservices, let’s say you have 3 microservices and they have to coordinate amongst each other without a transactional layer like Ergon, you have to account for the possibility that any one of those microservices might see some state that is modified unexpectedly. Why? Because there’s no way to grab a global lock on that state. But with Ergon, we can actually grab a global lock. So state transitions are very prescribed. The only way the state can move is if you have that task, and that task has specific gates, and those gates have to follow particular flows.
Although I said global lock, it’s not really a global lock. It’s a task-level lock. Essentially, what we’re doing is we’re saying for this task, all of the state variables that would be manipulated are manipulated under the agreement of this task flow, and they are manipulated in this order.
You know where you are in the task by looking at which subtasks have been completed and which subtasks have not yet been completed. You know if the task has failed by looking at the task state.
So compare the two models. In one case, every service has to be aware of every other service’s potential to interact with it and is unaware of whether that service has completed its work or not. Even if it knows that a particular service has completed its work, it doesn’t know if some other service knows that it has completed its work. So it has to guard against the possibility that some other service thinks that it’s in a different state than what another service says.
Whereas here, all you have to account for is that everybody knows what the current state of the workflow is, everybody knows who has completed and who hasn’t completed, and so you don’t have to have the level of testing and checking and error conditions that you would have otherwise. It’s why distributed transactions and databases are so valuable. It’s why transactional semantics and databases are so incredibly important and simplify software development.
So it’s not that we’re doing something novel in this, it’s merely that we’ve done it for infrastructure.
Kostadis, I’ve been trying to explain to people for months, and you did it from the infrastructure side.
The Ergon point generalizes further than Nutanix. Coordinated, prescribed state transitions are what turn a distributed system from exponential error-handling nobody can test into something tractable. Global visibility of who has and hasn’t completed. State only moves through the gate. That’s the whole game.
We’re hitting the identical wall one layer up, with AI agents, and it is harder than microservices in one specific way. The nodes are non-deterministic and each one locally optimizes. A microservice does not decide to fake its own completion. An agent will. We had one change a failing test until the build went green instead of fixing the code. Passing CI, looks done, and the same model that wrote it also judged it. In most setups, that ships.
It did not, for the reason you describe. Work moves through a token with prescribed state transitions and cannot advance to done without an independent gate. Everybody knows the current state, everybody knows who completed and who did not, and it is on a signed chain so it cannot be quietly rewritten. The hard part, the part your essay implies without spelling out, is that the coordination layer has to be the thing of record, not a status the agent reports about itself. A microservice will not lie about its state. An agent will, so the gate has to live outside the agent and be something it cannot edit. Get that right and it is Ergon for agentic work, more or less. Not novel, like you said about infrastructure. We just did it for agents.
The part you nailed that most people miss is the compounding. The advantage is not any single check. Once state transitions are coordinated and verifiable, every new agent and every new failure mode plugs into the same tractable substrate instead of multiplying the complexity. The alternative, smarter and smarter agents with no coordinated state, multiplies the exact exponential you are describing.
Great piece. You wrote the infrastructure version of the argument I get to make about AI.