The Model Is Not the System

I just finished the final season of The Bear, so this post is partly the show’s fault.

There’s a moment in season two, while Carmy and Sydney rebuild The Beef into The Bear, where Carmy starts timing the kitchen. How long from station to station? Seven seconds. Can it be five? Move the island. Rethink the pass. Run it again. Nobody became a better chef because a counter moved a few feet, but over a dinner service those seconds compound.

Same people. Better system.

Strip that scene down to a thought experiment and it looks like this. Two five-star restaurants, same menu, same chef in both kitchens. In the first kitchen, the knives are sharp and the stove holds its temperature. In the second, the knives are blunt and the pans are warped.

Which kitchen would you rather work in?

The first, obviously. Not because that chef is better. It’s the same person. Past a certain level of skill, the tools start deciding the outcome.

In a previous post, Give the Models Hands, we argued that models need to act in the physical world rather than just observe it. This post picks up where that one left off, at a question that sounds simple and mostly goes unasked: if the models have hands, what are you putting in those hands?

Everyone gets the same chef

Frontier and open-weight models improve every few months, and everyone gets the improvement on the same day. Whatever LLM you run - Fable, Sol, Opus, GPT, Gemini - your copy is exactly as smart as your competitor’s. Whatever advantage lives inside the model is an advantage you share with the whole market.

The system around the model is another matter. Model capability and system capability have quietly become different things. A model can reason brilliantly about congestion. But if all it sees are the counters any monitoring stack exposes, you get brilliant reasoning about incomplete information. World-class chef, blunt knife.

The pantry is not the kitchen

The obvious reaction is access. Give the model SSH to your switches, wrap your CLI in tools, and point it at your dashboards.

That helps less than you’d expect, because access to data is not the ability to investigate. A show command tells the model a counter went up. It doesn’t say whether that matters for the job you’re training right now, what your cluster looks like when it’s healthy, or which hypothesis to test next without breaking something. Generic tools produce generic investigations, no matter which model you attach to them.

And tool quality compounds. A tool that answers in seconds instead of minutes changes how many hypotheses the model can afford to chase. A tool that captures signals at resolutions no human ever sees changes which hypotheses can exist at all.

The countdown clock from The Bear. Ours counts in microseconds. (Image: FX)

Chefs don’t forge their own knives

A fair objection: tooling is software, so build it yourself.

You could. A chef could also forge their own knives, hammer their own pans, and build their own range. Almost none do. Each of those is its own craft, and cooking teaches you none of them. The steel is purchasable and the technique is learnable, but every hour at the forge is an hour the kitchen runs without you. The people who make great knives have made thousands of them and carry the scars from the ones that cracked in the quench.

The Bear makes the same point at a smaller scale. When Tina heads to culinary school, Carmy gives her his knife. He doesn’t hand her a block of steel and a metallurgy textbook. There’s a reason chefs don’t forge their own knives.

The same logic applies here. Could your team wrap your fabric in homegrown tooling for a model to use? Probably. Doing it well is a different job. The signals have to come off the ASIC at resolutions the hardware was designed to capture. Normal has to be baselined per cluster, and someone has to decide which actions are safe to put in a model’s hands.

Same model, two kitchens

We’ve run this comparison internally.

Here’s a problem you’ll recognize if you operate training clusters: a job slows down intermittently, and the fabric is the suspect. The congestion tuning on a RoCE fabric, and the PFC and ECN thresholds that keep lossless traffic honest, is expert territory even for senior network engineers.

Give the problem to a frontier model, Claude in our runs, with the access most teams would give it today: SSH to the switches, the configs, the logs, the dashboards. It does better than you might expect. It knows the theory cold, reads every config, explains DCQCN more clearly than the vendor docs, and recommends sensible, textbook threshold changes. Watch it closely, though, and you notice it’s working from general priors. It can’t see what buffers do between polling intervals. It has no idea what normal looks like on your particular fabric. No tool lets it line up pause frames against the job’s iteration timeline or test even a single hypothesis. You receive a smart consultation, not a diagnosis.

Then we put the same model inside Aria. Same problem, same model. It pulled buffer occupancy from Aria, which had collected it from the ASIC at the microsecond resolution our switches were built to capture. It compared that against this cluster’s own baseline and lined the anomalies up against the workload. The pattern it found was invisible in the counters: a small set of ports running out of headroom during specific phases of the job, recovering before any dashboard could notice. Its recommendation came back grounded in measured behavior, and it verified the change did what it predicted.

I’m deliberately not walking through how the platform works. That’s its own post, and we’re working on it. The part worth remembering fits in one line: the model didn’t change. Its leverage did.

Build a better kitchen

The labs are spending billions to build you a better chef. Smarter models will keep arriving, and you inherit every improvement the day it ships. We made this case in an earlier post: a smarter model with better context produces better outcomes than a smarter model with no context at all.

The kitchen is where the game actually is. Differentiation is moving into the layer around the model, and “tool” is almost too small a word for that layer. A knife is a tool. What we’ve built at Aria is the kitchen itself: the switch, the network OS on it, and the telemetry pipeline between them, all of it designed with an agent on the other end in mind, arranged so the model can do real work. For physical infrastructure, that can’t be a software-only play. It has to be built against real hardware and real failures. That was the argument in Give the Models Hands. Everything we’ve run since has made it look conservative.

To end where we started: when Carmy wanted a faster kitchen, he didn’t ask for a faster chef. He moved the island. The models are ready. We’ve been building the kitchen. Yes, chef.

If you’d like to see what that looks like on a real fabric, get in touch.