Every engineering team debugging AI failures right now is quietly building the same tool. That’s usually the first sign a category is about to exist.
Ask ten engineering teams running AI in production how they catch a bad decision, an agent that reasoned itself into the wrong answer, a silent failure that passed every check, and you’ll get ten different homegrown answers. A spreadsheet someone updates after an incident. A Slack channel where postmortems get pasted and never revisited. A script one engineer wrote to grep the logs for a pattern that burned them once. Nobody bought any of this. Everybody built it, because there was nothing to buy.
The market is still where I left it
I wrote earlier this year about AI’s business layer feeling like 1999: real technology, unsettled market structure, company formation outpacing category clarity. The argument was that endurance comes from occupying a structural position that deepens as the market matures, not from moving first. That piece stopped at diagnosis. The layers were forming, but the boundaries were still too blurry to name any of them precisely.
One layer has since come into enough focus to name. It’s the one sitting underneath almost every “why did the AI do that” conversation happening in engineering orgs right now, and it’s following a pattern old enough to set a watch by.
Every category starts as everyone’s side project
Infrastructure categories don’t arrive with a vendor attached. They arrive as a problem enough teams hit that each one, independently, builds a small internal tool to survive it. Error tracking used to be a homegrown script tailing production logs for stack traces, before it was a category with a leader everyone just buys. Application performance monitoring used to be a dashboard someone’s infra team hand-rolled out of cron jobs and a spreadsheet, before it consolidated into a handful of platforms nobody questions building versus buying anymore. Security monitoring followed the same arc: every sufficiently large company had someone stitching together log alerts before SIEM became a purchasing line item instead of an engineering project.
The pattern repeats because the sequence is the same every time. The problem shows up before the market does. Teams patch it themselves because that’s the only option on the table. Enough teams patch the same problem, in roughly the same shape, that the patches start looking less like fifty different solutions and more like fifty rough drafts of the same one. That convergence is the signal. It’s not proof the problem is important, everyone already knew that. It’s proof the problem has stopped being differentiated engineering work and started being plumbing, and plumbing is exactly the kind of thing a market eventually builds once and sells.
What today’s version looks like
For AI systems, that plumbing isn’t logging what happened. That part’s basically solved, every serious stack traces requests, prompts, and tool calls now. What’s still homegrown, still hand-rolled, still different at every company, is the layer above it: capturing why a decision got made, scoring whether it was a good one, catching drift before it compounds, explaining a failure to a stakeholder who wasn’t watching when it happened.
Call it decision-quality tooling, or behavioral intelligence, or something else the market hasn’t settled on yet. The label isn’t fixed. What’s fixed is the shape of the work every team building it is independently rediscovering:
- some way to capture the reasoning behind a decision, not just the steps that executed it
- some way to judge, after the fact, whether that reasoning held up
- some way to catch a system’s behavior degrading before it shows up as a customer complaint
- some way to hand a non-technical stakeholder an answer to “why did it do that” that isn’t a raw trace
None of these are novel ideas. What’s notable is how many teams are building rough versions of all four right now, with no shared vocabulary, no shared tooling, and usually no idea another team down the street is solving the identical problem from scratch.
The decision every team is actually facing
That convergence is what makes buy versus build a real, current question instead of a hypothetical one. It’s tempting to treat this layer as something to keep building internally, since it started as internal tooling and internal tooling is cheap to keep patching one more time. But the same was true of error tracking and APM right up until it wasn’t, and the teams still running their own version of Sentry five years after Sentry existed weren’t protecting a strength. They were maintaining a project that had quietly become someone else’s job description.
The honest version of the question isn’t whether this layer exists. It already does. Every team running AI in production has some version of it. The only question is whether it remains an internal project or becomes infrastructure.
What this means for the market
Not every vendor racing to formalize this layer will be the one still standing when it matures. That’s the same selection dynamic from the 1999 comparison: Google and Amazon didn’t win because they arrived first, they won because they anchored to a position that got more valuable as usage scaled, while plenty of faster movers didn’t. The same selection is coming for whoever tries to own the decision-quality layer. Being early to build it is not the same as being the one teams are still buying from in three years.
What is true right now, before any of that selection happens, is that the category is close enough to existing that hand-building this layer is no longer free R&D. It’s a team quietly re-solving a problem every other team in this position is also re-solving, alone, at the same time. Somebody is going to build this once and sell it, the same way somebody eventually built Sentry so the rest of the industry didn’t have to keep hand-rolling it. I’m building Nalyqor on the belief that it will be that build.