Deep Networking in Practice
We recently made four short videos about AI infrastructure. Each one starts with a specific problem I hear constantly from people building AI Factories. If you watch just one, you learn how a feature works. But if you watch all four, you see how the whole product fits together, and what Deep Networking actually looks like in practice.
Why this matters
I covered this in the first post, but as a recap, in traditional cloud networks, if one server slows down, it only affects the people on that server. But with AI, workloads are tightly coupled. A single degraded optical signal or one straggling component will drag the entire cluster down to the speed of that weakest link. The monitoring tools we built for the cloud are useless here. They were designed for thousands of independent programs, not a single massive machine.
To fix this, we had to build what we call Deep Networking from the hardware up. It requires three things working together: fine-grained telemetry, visibility across the entire stack, and specialized agents running on every layer.
These four demos show how those three things actually work in practice.
Put the whole system on one timeline
When an AI job slows down, there is almost never an obvious place to look. The data you need is scattered across completely different systems. Your job metrics are in one place, your GPU telemetry in another, and your network state in a third.
To find the bottleneck, an engineer has to open five different tools and try to line up timestamps by hand. You are trying to figure out if the problem started in the job, the host, the NIC, or the GPU itself. Doing this while a massive cluster is sitting idle is incredibly stressful.
This demo shows what happens when you stop treating these as separate layers. It pulls everything, from job behavior and GPU state to the actual network topology, into a single view. This lets you trace an issue as it travels through the entire system.
The world has enough dashboards. This one earns its place by showing cause and effect: what the job actually experienced, lined up against what the hardware was doing at that exact microsecond.
See events at the resolution where they actually happen
A unified view is only useful if the data behind it is precise. If your measurements are blurry, a single dashboard just gives you a unified view of a blurry picture.
Traditional monitoring tools sample the network once every second, or sometimes longer. To a human, a second feels fast. To a cluster running matrix operations, a second is an eternity. At one-second resolution, your network can look completely healthy while brief spikes of congestion choke your bandwidth. The utilization graph looks flat, but your training job is crawling.
This demo shows what happens when you look at the network on a microsecond scale. By reading hundreds of measurements per second directly from the switch ASIC, Aria reveals what traditional monitoring averages away.
AI workloads do not experience averages. They experience tail events. If your monitoring tools miss an event because it happened between two samples, they will report that nothing went wrong. And if your infrastructure never saw the event in the first place, neither you nor any automated system can ever diagnose it.
Apply the right intelligence to the right problem
Collecting more data does not automatically solve anything. If all you do is gather more telemetry, you just end up with more alerts, more charts, and more noise for an already stressed engineer to dig through.
This demo shows what happens when you give the system actual reasoning. In a previous post, I called this “giving the model hands.” We do not mean slapping a generic LLM on top of legacy software and giving it permission to mess with your production network.
We mean purpose-built agents designed specifically for networking. Some operate down at the switch layer to react in microseconds, while higher-level agents correlate evidence across the stack to figure out what actually broke.
Instead of dumping a pile of raw signals on your screen and expecting you to triage them by hand, the system tells you what happened, why, and what to do next.
Build the interface around the operator’s question
Traditional dashboards are built on a fundamentally flawed premise: that someone can predict, months in advance, every question you will need to ask during an outage.
Real incidents never follow a script. When an AI cluster stalls, your questions change every thirty seconds as you find new clues. You might start by looking at a training job, then suddenly need to compare a single GPU against a specific switch port over a three-second window. You cannot stop mid-investigation to ask an internal tooling team to build a new graph for you.
We took a different approach with Aria Console. Instead of forcing you to hunt through pre-baked charts, you describe what you want to see in plain English. The system then builds a live visualization on the fly using real telemetry from your fabric.
It combines microsecond telemetry, full-stack context, and intelligent agents to give you a clear, custom view built specifically for the question you are asking right now.
One loop
Put the four pieces together, and they form a cohesive story. You catch events at the scale they actually happen and trace them across the whole stack. Specialized agents find the cause. Then the answer shows up in whatever form is useful right then.
Every time this loop runs, the system learns something new. It adjusts its baselines, catalogs new failure patterns, and makes the next investigation faster. This is the compounding effect I wrote about in my earlier posts.
Deep Networking is not a research project or a future roadmap. It’s shipping in production today. I’d watch all four videos in order. They add up to one story.
This is the fifth in a series of posts about building products for the AI infrastructure era.
