The Control Layer: Why the Next Era of AI Is About Infrastructure, Not Just Models

The Model’s the Easy Part - How to Get, and Keep, Value

Here’s how I see the evolution of AI in enterprises over the last few years:

• Autumn of 2022, the world thinks it’s going into a recession.  IT budgets are frozen for 2023.
• November 30, 2022: ChatGPT launches, and the non-technical parts of the C-Suite have a tangible interaction point with AI - a simple chat interface available online.
• CEOs, CFOs, CROs go home for the holidays and are wowed by early-stage GenAI - making Taylor Swift rap like Eminem, summarizing emails, chatting about travel plans.  Impressed, they unlock IT budget only for GenAI pet projects in 2023.
• 2023: pet projects, experimentation.  The only new budget was in GenAI, so that’s where all IT teams focused.
• 2024: the great culling of 90% of GenAI pet projects not being promising, and the 10% that were starting to go through GRC for deployment.
• 2025: applications go into production, with varying levels of guardrailing, cost tracking, and ROI measurement.  (Also, agentic coding becomes real in late 2025 - so product deployment velocity increases.)
• 2026: internal and external usage of GenAI in production explodes.  Annual budgets are blown away in months or less.  Concerns around system and data ownership increase with sovereign AI discussions and increased government involvement with frontier labs.

Put simply, we’ve moved from "should we experiment with AI?" to "why isn't this in production yet?" to “what’s the ROI, and my lord how much did that cost?!, and where did my data go?!.”

Very different discussions!

Experimenting is cheap: spin up an API key, see what happens, move on.  Production is different.  You need reliability, auditability, cost control at scale.  You may need hard constraints over geography, on-premises compute, the ability to own your own models.  That's why we built Otari.  Not because models aren't good enough - in fact, the opposite, so many models are good enough for so many tasks.  But, the infrastructure to manage them at an organizational level doesn't exist yet.  We're building it.

What Changed in the Last Two Years

A contentious take: the most important shift hasn't been model capability.  Models have improved dramatically, sure.  Open source and open weight models especially.  But the real change is adoption velocity.  AI in production has gone from a handful of well-resourced tech companies to thousands of teams across every sector.  With that came problems nobody fully anticipated.

First: fragmentation.  Most teams aren't using one model - they’re using dozens.  At a high-level, that might be a GPT release for text summarization, Claude for coding, an on-prem open-weight model for something sensitive.  But even if they’re an “OpenAI shop”, they’ll still have teams using GPT-5.5, -5.4, -5.4-mini, -5.4-nano, and legacy models that worked well at deployment and haven’t been touched since.  Each with its own API, pricing, latency profile, rate limits.  What looked like flexibility quickly became operational chaos.

Second: cost opacity.  AI inference scales non-linearly.  A feature that costs $200/month in testing can cost $20,000/month in production if usage shifts.  This is only getting more important as the “VC subsidies” on tokens lift with the upcoming frontier lab IPOs, and the true cost of a token becomes less opaque.  Most teams don't find out what they’re on the hook for until they get the invoice.  There's no native tooling across providers to surface this before it's too late.

Third: governance gaps. As AI moves into regulated industries - finance, healthcare, legal, education - "which model said what, when, to whom, and why" becomes a compliance requirement.  And the sovereign AI discussions happening worldwide add complexity to these requirements.  Current infrastructure has no answer for this.

The Challenge of Managing Multiple Providers

Here's what multi-provider complexity actually looks like in practice.  A product team is routing to three or four different model providers, with multiple models per provider - and they’re routing to ad hoc local solutions.  They've built custom failover logic for outages.  They've got spreadsheets tracking costs.  Engineers are manually tuning which model handles which request type based on gut feel and incomplete data.

This isn't a sustainable architecture.

The problem isn't that teams are doing something wrong.  The tooling just hasn't caught up. When cloud computing matured, organizations stopped managing servers manually and adopted platforms that abstracted the complexity away.  We're at the same inflection point with AI.  Models are the compute.  The control layer above them is what's missing.

Cost Visibility Is a First-Class Problem

Cost is underappreciated as a strategic issue, although that’s changing in 2026 as organizations start to realize how much “tokenmaxxing” is burning capital for questionable return.  That said, most organizations treating AI infrastructure as a cost center are thinking about it wrong.  The real question isn't "how much are we spending?"  It's "are we getting the outcome we need at the lowest cost possible, and do we even know?"  Those are very different questions.

Right now, most teams can't answer the second one. They can't compare cost-per-outcome across providers.  They can't see in real time which routes are burning budget without proportionate value.  They can't set policy ("never spend more than X on this use case, unless Y happens") and have it enforced automatically.

Finance teams will eventually demand - frankly, are now demanding - this kind of visibility. Engineering teams that get ahead of it will have a structural advantage over those that don't.

Why Control Becomes Increasingly Important

Here's the thesis I keep coming back to, and what we’re building for: control is the new moat.

For the past few years, teams competed on which model they used.  That advantage is eroding. Models are commoditizing.  The marginal difference between top-tier models is shrinking, and there are multiple competitive options at every level of model performance down to what can be run on a Raspberry Pi.  The next competitive layer is operational: who can deploy AI reliably, cost-effectively, and safely at scale?

That's a question of infrastructure.

What does "control" actually mean here? It means routing requests intelligently by cost, capability, latency, and compliance.  It means real-time observability into what your AI is doing and why.  It means setting policies at the org level and having them enforced consistently, without asking every team to reinvent the wheel.  It means swapping providers without rewriting your application layer.

Control means operating AI like a mature engineering discipline.

Why Mozilla Decided to Build Otari

Mozilla has always believed in a particular kind of internet: open, decentralized, governed in the public interest, and governed by the public.  When we looked at where AI infrastructure was heading, we saw a familiar pattern.  Consolidation of power in a small number of providers.  Most organizations dependent on opaque systems they couldn't inspect, modify, or control.

We've seen this story before.  We know how it ends if nobody intervenes.

Otari is our answer to that. It's a control plane for LLMs, open-source at its core, designed to give organizations genuine agency over their AI infrastructure.  Not just a router.  Not just a cost dashboard.  A full control layer that sits between your applications and your models, giving you the visibility, governance, and flexibility to operate AI on your own terms.  (And, as we move into an era where cos

We built it open source deliberately.  The organizations that need this most, in healthcare, education, defense, finance, and civic tech, can't afford the lock-in.  Yes, open source is a distribution channel - and one that aligns with our core values - but we see it as more than that: an absolute requirement for adoption in the most important industries, agencies, and organizations that drive the world economy.

Otari’s Opportunity: Defining a New Category

The agentic era isn't coming, it's here.  The next architectural shift in software isn't another model release.  It's agent harnesses: systems that coordinate dozens or hundreds of AI agents in parallel, each making model calls, each generating cost, each touching data that needs to be governed.  The complexity of managing that at scale is orders of magnitude beyond what current infrastructure handles.  This is the problem that needs to be solved, and it doesn't have a good answer yet.

That gap is the category.  Not a feature, not a niche.  A foundational layer that every serious AI deployment needs.  The organizations that instrument for control now will have an operational advantage that compounds.  The ones that wait will be retrofitting governance onto systems that were never built for it.

We're building Otari to be that control plane, open-source so the community can shape what this category becomes, and so the organizations that need it most can actually adopt it.  Healthcare systems, public agencies, financial institutions, civic infrastructure: they can't depend on black-box vendors.  ServiceNow's Amit Zavery said it directly: "Every customer, when they're thinking of AI adoption and agentic, they're worried about control."  Michael Dell of Dell Inc. made the infrastructure case - what cloud delivered was elastic scale: "what it didn't promise, and cannot perhaps deliver, is cost-predictable agentic AI at scale on sensitive enterprise data." And heck — even Palantir's Alex Karp is weighing in on choice and open source AI: "What the technical customers want is control over their compute, their models, their data stack and their alpha. They want to know they own the means of production."  The most important institutions and enterprises need to own their stack, and Otari is a step toward that necessity.

The future of AI isn't just about which model wins.  It's about who controls the layer above the models. We think that control, done right, should belong to everyone.  We're building Otari in the open to prove it.  Pop on over to our hosted instances at Otari.ai or set up your self-hosted gateway from our fully open-source GitHub repository - own your inference, own your AI stack.