Users Without Heartbeats
In my first post, I wrote about why I joined Aria and what it felt like to finally show the product to the world. The second was about how to decide what to build when technology is moving faster than your roadmap. The third was about what the context layer actually looks like when your product operates at the physical layer of AI infrastructure.
This post is about the tenant that’s moving in, a tease from the last blog. And the answer is changing faster than most people realize.
The tenant
Right now, almost everyone building AI infrastructure is building for humans. The mental model is simple: a team submits a training job, it runs for hours or days, and a human evaluates the result. The network is optimized for long-running operations directed by humans.
That model is already being replaced. Not in five years. Now.
The emerging workload pattern is agents orchestrating other agents. They run inference chains across specialized models, call APIs, retrieve context, and generate new compute jobs autonomously. The human becomes the goal-setter, not the operator.
This changes what the network needs to be. The next users of AI infrastructure don’t have heartbeats. They don’t sleep, they don’t open dashboards, and they don’t file tickets. They are agents. And the infrastructure they need looks nothing like what we built for humans.
Sequential fragility
To understand why this breaks current infrastructure, you have to look at the probability.
A single request to an agentic system can trigger a chain of 50 or more sequential network round-trips across specialized models. Each step calls another model, retrieves context, executes a tool, and passes the result to the next step. The entire chain has to succeed for the task to complete.
A 99% reliable network serves a human chatting with an LLM just fine. But for a 50-step agent chain, that same 99% reliability yields a 60% completion rate.
Every failed task is wasted compute. At scale, network reliability ceases to be an operations metric. It becomes a strict bound on revenue.
Hardware designers already see this. At GTC this year, Jeff Dean and Bill Dally spent most of their dialogue on this exact shift. Dean’s point was direct: once agents start running autonomously, tools designed for human-speed interaction become bottlenecks. Dally laid out the physics of what it takes to get inference latency low enough for agents to operate at machine speed.
They were talking about chips and interconnects, but the implication for the network is exactly the same.
A network that is “good enough” for a human refreshing a dashboard will choke an agent executing 50 sequential steps at 3 AM.
Machine interfaces
There is a parallel shift happening in how software gets consumed, and Andrej Karpathy articulated it better than anyone: CLIs are not legacy technology; they are the exact interface AI agents have always needed. The command line was accidentally optimized for machine consumption decades before machines were smart enough to use it.
MCP, the Model Context Protocol developed by Anthropic, made this concrete. In its first twelve months, MCP went from zero to 97 million monthly SDK downloads and 10,000 active servers. OpenAI, Google DeepMind, Microsoft, and Cloudflare all adopted it. It was donated to the Linux Foundation. Running an MCP server is now the baseline for any software product that wants to participate in agentic workflows.
The implication for infrastructure is clear: a beautiful dashboard is invisible to an agent at 3 AM. A CLI and an MCP endpoint are not.
If your context layer is not programmatically accessible, agents cannot call into it. And if agents cannot call into it, you are building for a tenant who is already moving out.
The operational model
If you accept that agents are the new tenants, the infrastructure has to adapt. When an enterprise deploys an operations agent to assess fabric health before scheduling a job, it must query the system that stores the fabric’s operational model.
At Aria, we are building the authoritative context source that operational agents call into.
“Designed for Humans. Ready for Agents” is on our website. It is not a tagline. It is an architectural decision we made early and have been building against since day one.
In our launch demos, we showed a human asking, “Why is my training job slow?” and getting a conversational answer. Aria conducted an investigation across the network, MLOps tools, and GPU telemetry, and explained what it found.
When an orchestration agent asks the exact same question at 3 AM, it doesn’t need a conversation. It needs a structured response: problem type, affected component, confidence score, and recommended action. It needs to chain that response into the next step of its workflow without waiting for a human to interpret it.
Same context layer. Same knowledge. Different surface.
The thread through the series
Over these four posts, I’ve been working through the same question from different angles: how do you decide what to build?
The answer is always to build what becomes more valuable as models improve.
A smarter model with access to better physical context, richer failure history, and agent-accessible surfaces accelerates the Aria flywheel and makes Aria more useful to our customers.
The next tenant of AI infrastructure won’t be a human staring at a dashboard. We are building for that tenant now.
This is where my series lands, but it’s not where the conversation ends. There is a lot more to say about what it actually takes to build for this era, and you’ll be hearing from the rest of the Aria team on various topics soon.
This is the fourth in a series of posts about building products for the AI infrastructure era.
