Two customers called it “industry changing.” Neither was talking about the AI.
What they were reacting to was the absence of a translation step — a single view tracing a business-critical transaction across every layer of the stack. Same data, same context, no matter who was looking.
Ben Haddox Field CTO, OnStak 8 min read
That caught me off guard the first time. The second time, I started paying attention to what they were pointing at on the screen.
Both times, it was the same thing: a single view that traced a business-critical transaction across OSI Layers 1 through 7 — firewall, switch, router, load balancer, infrastructure server, VM, Kubernetes cluster, application service, cloud edge, ISP — and held all of that against the business object the transaction was carrying. One screen. Persona-agnostic. No matter who was looking — security, network, app, infra — they were looking at the same source of truth.
That's the hard part. Not the AI. Correlation is the hard part — and it's hard for AI too, especially in bulk data. That's why it gets so expensive.
We have forty-plus years of industry standard working against us: siloed teams buying from siloed vendors doing siloed things inside siloed environments. Each layer has its own dashboard, its own data model, and its own version of the truth. Our build correlates data across those silos before AI ever touches the data.
What they were responding to was the absence of a translation step. Today, when something breaks in production, the network team looks at their dashboard, security looks at the SIEM, the app team looks at APM, infra looks at their tooling — and they meet in a war room to argue about whose picture is right. We collapsed that into a single picture. Same view, same data, same business context, no matter who's looking.
They wanted to know which transactions on their network were carrying patient information, and what the potential vulnerability and attack surface those transactions were exposed to. This wasn't a network exposure, an app exposure, or an OS/Firmware exposure. They wanted to see a true end-to-end view of the transaction with every device and endpoint it touched along with every software version, network protocol, and security risk along the way.
The old way: get your network team, security team, application team, and infrastructure team with all of their data sources. Trace the transaction by hand across firewalls, switches, routers, load balancers, infrastructure servers, VMs, Kubernetes clusters, application services, cloud and ISP. Compare against your current security posture. You spend weeks — sometimes months — with multiple teams burning FTEs, and you still aren't sure the picture is complete.
What we showed them: tag patient-data transactions as business-critical objects. The system auto-flags those objects and traces every hop they touch. It generates a weighted security risk score in real-time. Then the AI produces a prioritized list of quick wins — your N-1 internet-facing protocol matters more than this N-3 buried switch firmware patch, here's why, here's the order.
Ben Haddox — Field CTO, OnStakHours to days to customize for the customer. Seconds for the AI to score risk on a flagged transaction once it's set up. One lead engineer on the POC put it cleanly: "I'm certainly seeing how doing the heavy data work for AI beforehand makes a difference."
That's the right way to read it.
Cisco published research last week. Their CPO, Jeetu Patel, surfaced it in a LinkedIn post — they are projecting enterprise WAN traffic to jump 9x under agentic AI, up from 2.5x without it. Their own caveat in the same post: those numbers might be conservative. What they modelled as a ten-year shift could land in three.
Projected enterprise WAN traffic growth under agentic AI — up from 2.5× without it. Their own caveat: those numbers might be conservative. A ten-year shift could land in three.
"Networking stops being a passive transport layer and becomes part of the intelligence stack." — If that's even close to right, the question isn't whether AI infrastructure needs a correlation layer underneath it. It's whether you build that layer now or learn it the expensive way.
vs a person doing the equivalent work
Scales with prompts, not with users
vs 0.5% for normal web traffic — models keep pulling context back
Here's the architectural choice we made — and it's the one I think the industry is going to have to reckon with.
Take an existing observability stack — typically APM-biased — and bolt an LLM on top to summarize, query, and recommend. The AI does the correlation work in-context, every time, on every prompt. Expensive in tokens, slow, and only as good as the underlying tool data set — which is usually one persona's slice of the world.
We do the correlation in the data layer — across OSI 1 through 7, business objects, and the rules and context that govern them — before AI is ever invoked. By the time the LLM receives the prompt, the work is mostly done. AI does the analysis, the customer gets the insight, and the auditors get a clear trail.
It cuts tokens per decision, because the model isn't reasoning through a haystack — it's reasoning over correlated facts. And it makes the output explainable because the correlation is in the data, not in the model's internal reasoning.
Translation: for LLM-first architectures, the math gets ugly fast. Every prompt where the model is doing correlation work is a prompt you keep paying for — and tokens are the obvious cost. The harder ones are latency you can't claw back at agent speed, and an audit trail you can't reconstruct after the fact, because the join never lived outside the model.
Rolling updates based on satellite link quality, weather conditions, and live ship usage. The correlation across those signals plus their network state is what makes the rollout decision possible. Without the proper correlation, it's a guess.
Correlation first, then the AI callNear-real-time rerouting — production load, distribution network, and atmospheric data correlated against business priority. Same pattern. Correlation first, then the AI call.
Correlation first, then the AI callNeither of those use cases existed as a buyable product six months ago. They exist now because we make the data ready for the AI before the AI gets called.
It ships as part of OnStak's AI Portfolio. With multiple patents pending in our correlation layer, we believe that's where the moat is. Not in the model. In what the model gets to work with.
I'd put to anyone building or buying in this space: if AI is doing the correlation one prompt at a time today, what happens to your tokens, your latency, and your audit trail at 9x the traffic? I'd like to hear how you're thinking about it.
Ben Haddox — Field CTO, OnStakNot in the model.
In what the model gets to work with.
See every capability, every customer outcome, and the full AI Correlation Fabric in action — or register to see it live.