# Why L3 Stalls

> L3 is where every infrastructure platform has landed, and none has left. The gap to L4 is not reasoning. It is whether anything underneath knows how your fleet is wired together.

- URL: https://blog.asama.ai/blog/why_l3_stalls/
- Published: 2026-08-16
- Tags: Articles

Every serious platform in this market is at L3 on something, and not one of them is at L4 on anything. Here is what separates the two columns.

| | At L3 | At L4 |
|---|---|---|
| **Detection** | Two hundred alerts collapse into one incident. A chat box sits over your history and answers in English. A probable cause is named, with the logs and change records around it. | One cause, and the mechanism behind it: which setting, which firmware level, which link. Plus the blast radius: the other nodes carrying the same fault right now, before any of them page anyone. |
| **Remediation** | The platform recognises the problem class, finds the runbook you wrote for it, and hands it to your automation tool to execute. | A plan composed for that exact machine, against its firmware, BIOS and kernel as they are today. Executed with a rollback worked out beforehand, then verified against how that node behaved before the incident rather than against whether the alert went away. |

L3 demos beautifully. The difference between those columns is not intelligence.

**L3 tells you where it lost the trail. L4 tells you what broke.**

We have scored 23 platforms and combinations against 13 components. 39 cells sit at L3. Zero sit at L4, and the two of those 13 that make a causal chain possible at all have nobody above L2. This is what is in the way.

---

## L3 answers the first why. There are five.

An infrastructure root cause almost never sits one level below the symptom. It sits four or five levels below, and the levels are predictable enough to write down.

| | The question | What answering it takes | L3 |
|---|---|---|---|
| **Why 1** | Which resource is under pressure? | metrics on the resource | **answers it** |
| **Why 2** | Why is that resource behaving this way? | the right metric happening to exist | **sometimes** |
| **Why 3** | What state is it in that causes that? | configuration held as state, not as a graph line | no |
| **Why 4** | What put it in that state, and when? | change brought forward at the moment you are looking | no |
| **Why 5** | Which other machines are in that state now? | a fleet cohort to compare against | no |

The three it cannot reach are not harder questions. They are questions about things nobody collected. Why 3 is configuration, and nobody collects configuration. Why 4 is change history: retained in a log somewhere, surfaced nowhere near the person staring at the graph. Why 5 needs a cohort. There is no cohort.

Concretely: latency spikes, and the platform walks it back to CPU pressure on host-47 in seconds, correctly. Two levels short of a power governor pinned in powersave by a firmware update eleven days earlier, on nine machines from the same procurement batch, of which host-47 happens to be the one that paged.

**L3 answers the first why and gestures at the second. That is a directional answer, and directional answers are worth having. It is not a root cause, and the four whys it did not answer are the four that determine what you actually do tonight and whether you do it once or nine times.**

---

## Where the chain breaks

The chain can only break in five places, and they are the five components of Infrastructure Coverage. Not a coincidence. They are the same thing described from two directions.

**Breadth.** The layer was never collected. BIOS attributes, kernel parameters and loaded modules, firmware tuples, driver versions, PCIe link generation and width. Most platforms reach a BMC sensor and stop there. A sensor reading is not a setting. *A person crosses this by SSHing into the box.*

**Depth.** You hold the value and nothing to judge it against. Even where clock speed is collected, 1.2 GHz is only wrong if you know what this model should be doing under this workload, and that reference does not exist. Self-history is no help. A machine that has been wrong since it racked has always looked like this. *A person crosses this by remembering what normal looks like.*

**Normalisation.** Records do not mean the same thing across vendors, or across layers. Dell's power reading and HPE's power reading are two unrelated numbers. `/dev/sda`, bay 3 on the controller, the Redfish drive resource and the serial on the caddy are four objects, not one drive, which is how you end up with four terminal tabs open and a serial number written on the back of your hand at 3am. *A person crosses this by knowing both vendors.*

**Topology.** Most people underrate this one, and it is broader than a rack diagram. Your estate is a graph: a VM sits on a host, the host's NIC lands on a leaf port, the leaf has uplinks into a spine, the host has HBAs into an array, the array has a controller and a shelf, the host draws from a PDU pair, and the job it is running is one rank of a collective spread across forty other hosts. Almost nothing holds all of that at once, kept current, with state on the edges rather than just the existence of an edge.

So when a leaf port starts silently dropping frames, nothing connects it to the forty ranks that just went slow, nothing connects those ranks back to the two hosts sharing that leaf, and nothing knows that one of those hosts also fronts the array shelf where latency doubled. Three incidents get opened. Three people work them. **Interconnectedness is not a nice-to-have on top of collection. It is what makes a chain a chain rather than a list.** *A person crosses this by having personally built that part of the estate.*

**History.** What this was before is not brought forward. The firmware changed eleven days ago, the governor changed with it, and none of that surfaces while somebody is staring at a latency graph. Retained is not recalled. *A person crosses this by remembering eleven days ago.*

Five breaks. Five handoffs. Every one of them is the same handoff: **the software stops and your senior engineer starts.**

---

## Why everyone landed on the same rung at the same time

Split the 13 components into the ones where L3 is common and the ones where it is not, and the split is clean.

**L3 is easy on history, correlation, root cause, symptom detection and detection learning.** All five mean the same job: reason over data you already hold. You reach L3 on all five by attaching a language model to a store you already have. That is a weekend for one engineer with an API key.

**L3 is rare or absent on breadth, depth, normalisation, topology, plan, act, verification and remediation learning.** All eight need the same two things, and neither is a model. They need the estate held as a live interconnected graph, and they need a mechanism that knows infrastructure state, behaviour and change as they happen, across vendors, interoperably enough that a record from one layer can be reliably tied to a record from another.

That is not a feature. It is a collection architecture, a data model, and a per-vendor engineering commitment that grows every time a new hardware generation ships.

So the market did the rational thing. Everybody built the half a model unlocks. Inside eighteen months they had all arrived on the same rung: wire Claude to Zabbix through its API and you reach L3 on correlation and root cause in an afternoon, while LogicMonitor, valued at $2.4 billion and running a dedicated AI organisation, gets to exactly the same two cells. Same store underneath. (Zabbix also ships with its IPMI poller disabled by default, which has nothing to do with any of this and has cost more than one team a weekend.)

**The ceiling on those five was never intelligence. It was input.**

---

## Why it plateaus, rather than climbing slowly

Here is the shape of the trap.

Improving the reasoning layer over incomplete input has **very steep early returns and then almost none**. The first model integration is transformative, because it does in seconds what an engineer did in an hour. The second improvement is worth less. By the fourth you are tuning a system that is already extracting close to everything the input contains.

The curve flattens fast, and it flattens well below the ceiling, because the binding constraint was never the reasoning. Teams read the flattening as maturity. It is saturation.

Meanwhile the work that would move the constraint looks nothing like an improvement to what is shipping. Collecting BIOS attributes across five OEMs and every generation, resolving four representations of one drive into one object, deriving what normal looks like from the fleet rather than from a template: none of that makes the current product better. It makes a different product possible.

**You cannot reach L4 by extending an L3 stack.** You reach it by replacing what sits underneath one. That is a local maximum in the strict sense: every direction from here is downhill in the short run, and the only way out is to leave.

---

## Your senior engineer is the join

Go back to the five breaks and read them as a job description.

Someone SSHes into the box. Someone knows both vendors well enough to compare them. Someone joins the four records that describe one drive. Someone holds the wiring of the estate in their head. Someone remembers what normal looks like and what changed eleven days ago.

That is one person, and you know exactly who they are. They are the interconnectedness. They are the normalisation layer, the reference the platform does not have and the history it does not surface. **The five gaps are not five problems. They are one missing model of the fleet, and a human is standing in for all of it.**

Two things follow. Your incident time is bounded by that person's availability rather than your platform's throughput, which is why adding reasoning made triage faster and made nothing else faster. And none of it accumulates: 16 of the 23 platforms we scored retain nothing about what fixed anything, so the same five gaps get crossed by hand next time, and the time after.

## What we got wrong, and what we still do not know

Our first version of this ladder had six detection components rather than four. We deleted one because it was counting the same artefact twice. Scoped logs attached to an incident were scoring once as correlation and again as verification, which inflated five well-regarded platforms by a full level each, and we had already published scores built on it. The correction moved LogicMonitor, Datadog, Dynatrace, OpsRamp and the AIOps correlators down a grade. That is the cost of publishing a framework while you are still finding its seams.

Here is what we cannot answer yet. We do not know whether the five gaps have to be closed in an order, or whether closing three of them buys you anything at all before the fourth lands. Our own reading is that partial coverage returns close to nothing, because a cohort built on unnormalised data compares a Dell power reading with an HPE one and means nothing. We believe that. We have not proved it, and the only way to prove it is for somebody to try and fail in public.

L3 stalls because L3 is precisely the line where the software stops and that person starts. Moving the line is not a reasoning problem. It is a question of whether anything underneath knows how your fleet is wired together and what each machine is supposed to be.

*Levels refer to our published evaluation of 24 platforms and combinations across 13 components. Every anchor is public, and every cell can be re-scored against it.*