The right idea in the wrong culture: what Apple's Siri detour teaches about adopting AI

How an organization rejects its own best idea

Siri did not start as a feature. It started as a bet on a different way to use a computer.

Siri was a spinout of SRI International, born from a DARPA-funded research program called CALO, at the time one of the largest artificial intelligence efforts in the country. The founders, Dag Kittlaus, Adam Cheyer, and Tom Gruber, did not build a voice shortcut for setting timers. They built an agent: something that took a request in plain language and orchestrated real actions across a web of third-party services. Book the table. Call the car. Buy the ticket. One conversation, many tools, the assistant reasoning across them. If that sounds like the definition of an AI agent in 2026, that is the point. They had the architecture of the current moment, fifteen years early.

Steve Jobs saw it. He drove the acquisition personally, reportedly calling Kittlaus at home more than once to close it, and Apple bought the company in 2010 for a figure reported around 200 million dollars. This was not a junior product-team feature buy. At the very top, the thesis was a platform thesis.

Then the organization went to work on it, and the platform became a feature. Apple narrowed Siri, tightened its control, integrated it deep into iOS, and stripped out much of the messy third-party orchestration the founders had built. The standalone Siri app that existed before the acquisition could do more, in some respects, than the version that shipped on the iPhone 4S the day before Jobs died in October 2011.

The founders did not stay to fight it out. Kittlaus left in 2011, Cheyer in 2012. They went on to build Viv, an agentic assistant that did the open-orchestration thing they had wanted all along, and Samsung bought Viv and turned it into Bixby. Apple kept the code and the name. The people who held the direction walked out the door inside two years.

That is the whole mechanism, and it is worth naming plainly: an organization can acquire the right idea and still reject it, not in a single decision but through a hundred small ones that each optimize the thing it already knows how to do.

This is a structural story, not a stupidity story

It would be easy, and wrong, to read this as Apple being foolish. The more honest read is that Apple behaved exactly the way a successful organization is built to behave, and that is precisely the trap.

Three forces, none of them stupidity, did the work:

The product was framed as a feature, not a platform, so every roadmap decision pushed toward incremental polish rather than a risky rebuild. A feature gets refined. A platform gets bet on. Frame the same asset the wrong way once, at the top, and a decade of incrementalism follows logically.

The company's greatest strengths became its blind spots. Apple's identity is polish, privacy, and on-device processing. Every one of those is genuinely good, and every one of them was a reason not to chase large foundation models built on huge data and shipped rough. The moat Apple defended was the disruption it could not see.

And cash was never the constraint. Money buys data centers and GPUs. It does not buy a research culture that lets people publish, or the institutional willingness to ship something embarrassing and improve it in public, which is exactly how the current generation of AI got good. You cannot wire a check for a mental model.

Put those together and you get a company that won the war it was in, perfecting the touch-and-app interface, while the next interface, conversational and model-centric, was built somewhere else. The failure is sympathetic. It could happen, in miniature, to any of us.

What this means for adopting AI in a business that is not Apple

The reason this matters to a forty-person company, or a four-person one, is that the same gap shows up at every scale. The model is the easy part to acquire now. You can buy frontier intelligence by the API call. What does not come in the box is the direction and the operating model: what the AI is for, where it is allowed to act, who owns the vision, and how it is wired into the way the business actually runs.

We watch teams make Apple's mistake in fast-forward. They buy a capable model, bolt it on as a narrow feature, never decide what it is really for, and then wonder why it never becomes the thing they imagined. The technology was fine. The operating model was missing.

When we help a business adopt AI, the work is mostly the part Apple got wrong, not the part it got right:

We treat the decision as a platform decision, not a feature decision. Before any model is wired in, we get explicit about what this is for and what it could become, so the integration is built toward the second version, not just the first demo.

We keep the direction with someone accountable. An AI capability with no owner drifts the way Siri drifted. We embed as the fractional engineering leadership that holds the technical vision, so the person who understands where it is going does not walk out the door in year two.

We encode the operating model in the system, not in a slide. Scoped tools instead of raw access, approval queues on the actions that matter, policy in the tool layer rather than in a prompt. The agent is deployed the way you would onboard a new hire: trained on the playbook, scoped on what it can touch, supervised where the stakes are real.

None of that is exotic. It is the unglamorous half of AI adoption, and it is the half that decides whether the capable model you bought becomes a platform or a punchline.

What this article is not

This is not a prediction that Siri AI will fail. Routing hard reasoning to the best available model is a defensible call, and the new Siri may well be good. The point is about the decade before it, not the product shipping this fall.

This is not a claim that Apple was wrong to partner with Google now. Given where it stood, leaning on scale it did not have is the pragmatic move. We are not above that decision and would likely make it too.

This is not a "build everything in-house" argument. Buying capability is often correct. The argument is narrower: when you buy capability, you still have to supply the direction and the operating model yourself, because those are the parts that do not come with the purchase.

One-sentence takeaway

You can buy the technology, but the direction and the operating model around it are the parts that decide whether it becomes a platform or a feature, and those are exactly what no acquisition, and no API key, hands you for free.