Too Many Doors to the Same Room

I spent three days at the Databricks summit watching one company make a mistake and its cure at the same time, and the cure is the bigger story.

A while back I wrote that big companies don't die from doing too many things. They die from doing the same thing twice: from building two, three, four products that overlap so much that no one person inside the company can explain, on the back of a napkin, when you'd use one and not the others. Think of it as too many doors to the same room. The customer stands in the hallway, sees four doors, and can't tell which one is theirs. I used Microsoft as the example. Ask someone there to draw the line between Copilot Studio, Foundry, Agent Builder, and the agent SDK. They start strong, hit the seams within a minute, and land on "it depends on the customer" soon after.

I thought that was a story about one big, old company that had reorganized its product line one too many times. Last week I spent three days at the Databricks Data + AI Summit in San Francisco, and I watched a much younger, much sharper company do two things at once: build the same confusing set of doors at the product level, and, one floor up, build the exact thing that fixes it. Not just for itself. For the whole industry. That second move is the one worth your attention, and almost nobody is writing about it.

What the floor looked like

First the scale, because it matters. This was not a sales event in a hotel ballroom. Databricks put more than thirty thousand people on the ground at Moscone, with tens of thousands more watching online from over a hundred and fifty countries. The keynote stage had the founders, a recorded conversation with Satya Nadella, and people from OpenAI and Anthropic. The theme of the whole event was, more or less, "build apps and agents that actually work." So when I say everyone was doing agents, I don't mean it was background noise. It was the headline.

Let me be honest about what this piece is and isn't. I attended, I walked the floor, I sat in keynotes, and I've built on Databricks before. But I saw a handful of booths out of hundreds, and only some of the sessions. Some of what follows is a read on strategy, not a fact from inside the company. I'll keep the strong claims tied to things anyone can check (product pages, the open-source license, the announcements) and keep my guesses clearly labeled as guesses.

Up close: too many doors

At the product level, Databricks now has several overlapping ways to do the one thing the conference was about: build an agent on your data. There's Agent Bricks, the more automated path: describe the task, let the system optimize it. There's the Mosaic AI Agent Framework, the full developer toolkit with your hands on every control. There's the governance layer. There's the model serving and the foundation-model APIs. Each one touches the agent story from a slightly different angle.

Run the napkin test, the simple test of whether a salesperson can draw the difference on a napkin. Walk up to a booth and ask: I want to build an agent on my data, do I use Agent Bricks or the Agent Framework, and why not both? It's a fair question. The honest answer is that one is the low-setup path and one is the full-control path, and that line is perfectly clear to Databricks and genuinely fuzzy to the buyer standing there. Same hallway, same four doors, same hesitation I described at Microsoft, just in a building ten times the size.

If I stopped here, I'd be writing the same essay again, and you'd be right to be bored. Plenty of people can tell you a big platform has confusing overlapping products. That's true and it's old. The interesting thing happened one floor up.

One floor up: building the cure

Look at the other things Databricks put on stage, though, and a different kind of product comes into focus: not more doors, but the thing that makes a building full of doors navigable. Three of them, and you should look at what they actually are, not just what they're called.

Genie. A way for any employee to ask questions of the company's governed data in plain language. The clever part isn't the chat box. It's that Genie deliberately runs inside other companies' tools. It now plugs natively into Microsoft's Copilot Studio and Foundry, so a Microsoft-built agent can pull trusted answers from Databricks data without the user ever opening Databricks. Read that twice. Databricks isn't fighting Microsoft for the agent. It's making itself the trusted data underneath Microsoft's agent.

Unity AI Gateway. A control plane, the layer that sits above everyone's models and agents and decides what they're allowed to do: cost caps, routing between models on price and quality, runtime policy, monitoring. The key detail is that it governs other vendors' models and agents, not only Databricks' own. It's a toll booth that sits above the whole road, regardless of who built the car.

Omnigent. An open-source "meta-harness": a layer that sits on top of separate agent tools (Claude Code, Codex, and others) and gives them one shared interface to be combined, controlled, and governed. Databricks describes it as doing for agents what Kubernetes did for servers: a common standard above the mess. And they released it under an open license: Apache 2.0.

Notice what these three have in common. None of them is another door. Every one of them is a way to make a building full of doors walkable: a layer above the clutter. The product floor has the problem. The strategy floor is selling the cure.

The mistake and its cure, from one company

Here's where it stops being a contradiction and starts being the actual story. My first essay was about a mistake. Watching Databricks, I think I'm watching a company that has made that mistake at the product level and learned its cure at the strategy level, at the same time, on the same floor.

Because the cure isn't "have fewer products." It never was. The cure is the move my first essay quietly praised when it pointed to Amazon's cloud as the company that did breadth right. Amazon won not by having an opinion about every application a customer might build, but by being the ground everyone else builds on: the substrate, the layer underneath. You can have two hundred services and still be navigable if the customer can safely ignore most of them and trust the foundation. Open-sourcing Omnigent is the same instinct. You don't give away a product you're trying to sell. You give away a standard you're trying to own. Kubernetes was Google's gift that became Google's position. Apache 2.0 is not generosity. It's strategy wearing generosity's clothes.

So the right way to read the two floors is not "sprawl versus focus." It's one ambition seen from two heights. Confusing up close, at the booth, where a buyer can't tell which of four agent-building doors is theirs. Coherent once you step back, at the altitude where the plan is clear: let everyone else fight over models and agents (the parts that are quickly becoming cheap and swappable) and quietly own the two things that stay valuable underneath all of it: the trusted data, and the control plane that governs whatever runs on top.

Why this is the real game now

Step back from Databricks for a second, because the same shift is happening everywhere. Two years ago the prize was the best model. That prize is disappearing fast, not because models stopped improving, but because they're becoming interchangeable. Every one of the three announcements above assumes you'll run many models, from many vendors, and swap them as prices move. When the model is the cheap, swappable part, the value moves down the stack: to whoever holds the proprietary data the models need, and whoever runs the control plane that decides what the models are allowed to do.

That is the competition of the next couple of years, and it will be quieter and less glamorous than the model launches that get the headlines. Not "whose AI is smartest" but "whose foundation does everyone else end up standing on." Databricks sees it clearly. So do the big cloud players. So, in its own corner, does a company like Snowflake. Substrate layers don't support many winners. They tend to settle on one or two, plus an open standard that everyone agrees to share. Which is exactly why you give the standard away early, before someone else's becomes the default.

And there's a casualty class worth naming, because it's the one most people reading this are closest to. The squeezed middle is the vendor who built a single agent product: no data foundation beneath it, no governance layer around it. In a world organizing itself into substrates and control planes, that product becomes a checkbox inside someone else's platform. The deep specialists survive on real depth. The substrate owners survive by being the ground. The un-anchored middle gets absorbed.

Before we believe the keynote

One more thing, because I don't want to sound like I bought everything from the stage. Most grand platform layers underdeliver against the slide that announces them. Omnigent is an alpha: early, not production-ready. "Govern every model and agent in one place" is a beautiful sentence and a multi-year, partly-broken reality in practice. The conservative bet is that the strategy is right and the timeline is two or three times longer and messier than the keynote implies.

Which, if you think about it, is a second and quieter version of the same problem. Up close, the buyer can't tell which agent-building door is theirs. One floor up, the platform vision is genuinely coherent, but it's a promise, not a finished floor you can walk on yet. The clutter is real today. The cure is real on paper. The gap between them is where the next two years of enterprise AI actually gets fought, and where a lot of money gets spent learning which parts of the keynote were true.

Three questions, whichever floor you're on

I should name my own bias. I run a consulting firm. A world where the platform is too big to navigate alone is good for my business: confused buyers hire people to read the map for them. So take the argument knowing the person making it benefits from the confusion he's describing. I still think the pattern is real, and I think it's the most useful thing I saw in three days on that floor.

If you're building something and wondering which floor you're on, three questions usually settle it:

1. Can a customer ignore this new thing and still get full value from what they already have? If yes, it's breadth they can walk past: the Amazon pattern, two hundred services you never have to think about. If no, you've added another door to the same room, and the buyer pays for it in confusion.
2. Are you adding it to serve a buyer, or to be the layer everyone else stands on? Both are real strategies. They're just very different ones, and pretending you're doing the first when you're doing the second is how product lines turn into hallways full of doors.
3. If your own salesperson can't draw the difference on a napkin, what makes you think the buyer can? The napkin isn't a gimmick. It's the test the customer is silently running on you, every time they stand in the hallway and try to choose a door.

Microsoft built its hallway by letting products drift apart over the years. Databricks is building its hallway and, one floor above it, building the elevator that's supposed to make hallways like that obsolete: for everyone, as an open standard, with itself as the ground underneath. That's not the same mistake repeated. That's a company making the mistake and selling the cure in the same building. The cure is the part to watch. It's also the part that isn't finished yet.