Give the Models Hands
In my first post, I wrote about why I joined Aria and why AI infrastructure felt like the right moment to bet on building something from scratch. The second was about how to decide what to build when technology is changing fast, and three arguments that shaped how I think about product at Aria.
So what’s left? How do you build something that doesn’t get steamrolled by the next OpenAI, Google, or Anthropic release? If you’re building any product right now, you are probably haunted by a specific problem.
It turns out the answer is context. But not the kind of context most people mean.
This post is about what the context layer looks like when your product operates at the physical layer of AI infrastructure.
Context that requires hands
When most people in software talk about context, they mean institutional memory. They mean process docs, Slack histories, and the accumulated knowledge of how an enterprise runs. That kind of context is valuable, but it has a fatal flaw: it’s just text in a database. And if something is just text in a database, a sufficiently smart model will eventually eat it.
The context layer for physical infrastructure is different. Not different in degree. Different in kind.
A foundation model, no matter how capable, cannot reach into a Broadcom Tomahawk 5 ASIC and pull buffer occupancy readings every 200 microseconds. It can’t look at a transceiver and tell you whether a failure is optical or electrical. It doesn’t know that the GPU on rack 14 is running cool because it’s congested, not because it’s healthy.
Those facts don’t exist in any training dataset. They exist in the physical world. To get them, you have to build hardware and software specifically designed to capture signals at a resolution that legacy architectures were never built for.
But seeing isn’t enough.
A brain in a jar can’t do experiments. You have to give the model hands.
The Man with Two Brains
A model can’t reach into the physical world on its own, but you can give it the tools to do so.
At Aria, when the system suspects a transceiver issue, it doesn’t just flag the alert and wait. It takes action. It sends a known pattern down the link and measures what comes back. The result tells you exactly what the problem is, whether it’s optical or electrical, and where to look. The model just learned something about the physical world that wasn’t in any telemetry stream, any log, or any training set. It learned it by doing.
Every time it does this, your context layer grows. Not because someone wrote a rule, but because the system interacted with reality and recorded what happened.
The gap between data and meaning
The default assumption in our industry is that if you collect enough telemetry, intelligence follows. It doesn’t.
Raw data might tell you the error rate on port 14 of Leaf 7 is rising. But it cannot tell you what that error rate means for the training job running on top of it. It cannot tell you whether this pattern, on this transceiver type, at this temperature, with this age profile, is a transceiver degradation or a fiber path issue. It cannot compare what’s happening right now to what normal looks like for this specific cluster running this specific workload.
The gap between “what is happening” and “what does it mean” is the context layer. Closing that gap requires three things that don’t come from collecting more data:
A per-cluster baseline. What does normal actually look like here? Not a generic threshold, but a learned model of this cluster’s behavior built from weeks of operational data.
Workload correlation. The mapping between what’s happening in the physical network and what’s happening in the AI job. A 0.03% packet loss on a specific port during an All-Reduce synchronization barrier doesn’t show up in the network’s health metrics. It shows up in the training job’s MFU. Connecting those two things requires visibility across administrative boundaries that most systems treat as separate worlds.
A history of failures that compounds over time. Every time the system detects something, someone investigates it, and the outcome is recorded, the context gets more precise. The failure taxonomy grows. The baseline updates. The next time a similar pattern appears, the system is faster and more accurate. This is the compounding that Armstrong describes, except here it’s grounded in physics, not process documents.
Why this matters right now
AI models are getting better every month. The reasoning layer is improving at a pace that makes most software roadmaps feel slow. If your product’s value depends on doing something the model can’t do yet, you’re in a race you will eventually lose.
But if your product’s value depends on having been somewhere the model has never been, on having captured signals that don’t exist in any training set, on having accumulated operational knowledge from real deployments running real workloads, then a better model is good news. A smarter model reasoning over your proprietary physical context just makes your product better.
When we built Aria, we didn’t start with the AI layer. We started with the hardware and the telemetry architecture. We started there because the context layer for AI infrastructure can’t be a software-only play. You have to be in the physical world first. You have to capture what nobody else can see. Extract the reality, translate it into meaning, and let it compound.
That’s what “built for this era” means to us. Next time, I want to talk about the tenant that’s moving in.
This is the third in a series of posts about building products for the AI infrastructure era.
