It's unclear right now how AI is going to play out for most companies, and I don't think anyone has a clean answer yet, including me. But there's a pattern I keep coming back to, and it has less to do with what AI eventually becomes and more to do with what it can already do.
I don't think the capability curve breaks at some single moment we'd call AGI. It just keeps climbing. Each release adds capability somewhere, and we don't need to reach the top of the curve for the bottom of it to start reshaping things.
This past Tuesday at Google I/O, Antigravity 2.0 built a functioning operating system from scratch in twelve hours. It spun up 93 sub-agents, processed 2.6 billion tokens, ran roughly 15,000 model requests, and cost less than a thousand dollars in API credits. Then they ran Doom on it live. When the keyboard drivers were missing, they asked the agent to write them on stage, and it did.
Take the staging with whatever grain of salt you want. The point underneath is what "good enough" looks like in mid 2026. Many small agents, running in parallel, cheaply, reliably enough to compose into something that actually boots. That's the engine worth paying attention to. Not because of where it ends up, but because of what it can already do.
A capable agent loop, called many times in parallel, with reasonable cost and reasonable latency, is enough to recreate most of what the application layer of software currently sells. The curve keeps going from here. The question that follows is which kinds of companies sit downstream of that engine and which don't.
The companies pulling ahead right now share a property that has very little to do with their marketing and not much to do with strategy either. Their products are increasingly being consumed by software, not by people.
Turbopuffer crossed $100M in annual revenue this past March, nineteen months after hitting their first million. The company is profitable, has raised less than a million dollars total, and powers vector search for Cursor, Anthropic, Notion, Cognition, Harvey, and a dozen other names you'd recognise. Modal closed an $355M Series C at a $4.65 billion valuation this week. Months following their series B round in September of 2025. Mintlify just closed a $45M Series B from Andreessen Horowitz, and their own data tells the clearest version of this story I've seen. Across the documentation sites they power, AI agents now account for almost half of all traffic.
None of these companies pivoted into this. Most of them existed before the agent wave and were already well-regarded inside the developer tools world. They didn't bolt a chatbot onto a landing page or rebrand as AI-native. The product mostly looks the same as it did two years ago.
What changed is who their customer is becoming. The buyer is still a human writing the cheque, but the consumer of the API is increasingly an agent. And once buyers start choosing tools based on what their agents use well, the two collapse into the same thing. An agent reaches for the same APIs a human developer does, except it reaches faster, more often, and with less patience for anything that gets in the way. None of this required those companies to do anything new. They were already clean enough, well-documented enough, and API-first enough that a non-human caller could pick them up and use them without help.
The DX-first orientation, the obsession with making the developer's first ten minutes feel effortless, the API-first design, all of that predates agents by years. The agent wave didn't create them. What it did was add a second audience to the same product. One that never sleeps, never gets tired of reading docs, and calls the API like its life depends on it. The pre-existing quality is what made them ready. The agents are what made the growth look exponential.
Meanwhile most of the industry is having a much harder year. Layoffs, flat growth, long sales cycles, a general sense that the air has changed. The easy story is that these companies failed to "do AI." That's mostly wrong. Plenty of them have AI features. The harder truth is that their products were built for humans to look at and click on, and that audience isn't growing the way the agent audience is.
The line that matters isn't AI-native versus legacy. It's whether your product can be consumed by something that doesn't read landing pages.
Strip away the agent framing for a second. What does a company need to do to be useful to an agent? Have a clean API. Have docs that explain it without marketing fluff. Be reliable. Be fast. Scale without falling over. Don't hide behaviour behind cute abstractions.
That list is identical to what made a developer tool great in 2010.
The agent wave isn't introducing new product requirements. It's enforcing the old ones, harder. A human developer will tolerate a flaky API, a confusing doc page, an SDK that needs a workaround. They'll file a ticket, complain on X, and keep using the product because switching is expensive. An agent won't. It'll either succeed on the first call or move on to the next option in its toolkit. The patience floor is gone.
This pushes the whole industry back towards fundamentals that got papered over during the SaaS decade. Most application-layer software built between 2015 and 2023 leaned hard on polish, on smart UI, on workflow magic, on bundling. Some of that was real value. A lot of it was decoration sitting on top of weak primitives, and it worked because the customer was a human who could be charmed.
The customer that's growing right now can't be charmed. It reads your docs literally. It doesn't care about your brand. It doesn't notice your landing page animations. It cares whether the call returned a 200 in under 300 milliseconds and whether the response shape matched the schema. That's the entire relationship.
In a strange way this is good news for builders. The skills that matter are the ones that always mattered. Solid primitives. Honest documentation. Performance that holds under load. A product that does what it says it does. The agent era rewards the engineering virtues that the SaaS era let slide.
The catch is that most of the industry spent the last decade optimising for the other thing.
At the bottom of the stack is bare metal. Cloud compute, networking, storage. AWS, GCP, Azure, Cloudflare. Agents don't operate here directly. They sit on top of it.
At the top is the application layer. CRMs, project management tools, email clients, scheduling apps, the dashboards your company pays for. Most of what gets called SaaS lives here. This is the layer built for humans to log into and click around in.
In between there's a layer I'd call the 0.5 layer. Not bare metal. Not application. Auth as a service. Vector databases. Payment infrastructure. Inference platforms. Documentation hosting that doubles as machine-readable context. Typed SDK generation. The pieces you'd reach for if you were assembling software rather than using it.
Mintlify is 0.5 layer. So is Turbopuffer. So is Modal. So is Stripe, in a way that was always true but matters more now. So is Clerk, Resend, Trigger.dev, Supabase. Any company whose product is fundamentally a primitive that other software gets built on top of.
The reason this layer matters is that it's the layer an agent reaches into. If you asked a competent agent to build a working SaaS product tomorrow, it could stub out an auth flow, hack together a vector store, write basic payment processing. The reason it wouldn't isn't capability. It's that you don't want vibe-coded auth in your security-critical layer, vibe-coded payments anywhere near real money, or a vibe-coded vector store at production scale. So it would call Clerk. It would call Turbopuffer. It would call Stripe. It would assemble a working product out of 0.5 layer components and spend its actual reasoning budget on the thin application layer sitting on top.
This is the part that should make application-layer companies uncomfortable. The 0.5 layer is becoming the lego set. The application layer is becoming the thing assembled from the lego set, in hours, by an agent, on demand. The application layer used to be defensible because building one took a team of engineers, a year of work, and a go-to-market motion. None of those constraints are binding the way they used to be.
The 0.5 layer is harder to commoditise because the work is fundamentally infrastructural, and the moats vary in character. Some are regulatory, like the money-transmitter licences a payments platform holds across jurisdictions. Some are engineering at scale: an agent can write a vector database, but it can't write one that handles billions of vectors at millisecond latency the way a company that's been at the problem for four years can. Some are trust and installed base. 20,000 companies don't switch their documentation platform overnight. Different shapes of moat, same conclusion. The lego pieces themselves take serious work to build. The thing you assemble from them does not.
If you were an agent and someone asked you to build a Slack competitor, what would you reach for? A real-time messaging primitive. An auth system. A search index. A notification delivery service. A file storage layer. Vector embeddings for search. Payment processing. Documentation hosting for your eventual API. By the time you've listed the pieces, you've drawn a map of the 0.5 layer. And you've also, quietly, demonstrated that the Slack-shaped product on top is the easy part.
This is where the bifurcation gets sharp. The 0.5 layer is in a structural growth position because every agent that builds software pulls from it. The application layer is in a structural compression position because every agent that builds software is, by definition, competing with it.
If you run an application-layer company, the question worth sitting with isn't "how should we use AI." Every company is asking that one, and most of the answers are downstream of more important questions.
The question worth sitting with is whether an agent would still need you in three years.
Not whether your product would still be useful. Not whether a human customer would still pay. Whether an agent, given a task that today flows through your product, would route around you and assemble the same outcome from 0.5 layer pieces. If the answer is yes, the rest of the strategic conversation is downstream of that.
There are honest answers that should make a company feel okay. Proprietary data that took years to accumulate. Regulatory positioning that's expensive to replicate. Distribution into a buyer that doesn't trust agents yet and won't for a while. Trust relationships with customers that span decades. Genuinely hard technical problems that aren't vibe-codeable in a weekend. These are real moats and they'll hold for a long time.
The harder case is the company that has none of those. Good product, good team, good growth until recently, but the thing they sell is fundamentally a workflow on top of commodity primitives. That category is the largest single bucket in SaaS, and it's the category where the question doesn't have a comfortable answer.
I've been around the developer ecosystem long enough to have seen a few shifts. Native versus cross-platform. Server-rendered versus SPA. Each one moved value around, but the shape stayed roughly the same: companies built products for humans, and the question was which tools to use. This one is different. The question isn't which tools. It's whether the company is necessary.
I don't have a clean answer for what most companies should do about this. I'm not sure anyone does. The honest read is that most companies won't adapt, not because they're slow but because adaptation here means changing what you sell, who buys it, and how you charge. Companies are rarely good at any of those changes individually. Doing all three at once is something only a small number of teams have ever pulled off.
The companies that survive will probably be the ones honest enough to ask the uncomfortable question early, while they still have the runway and the focus to act on the answer.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。