Open source vs frontier models. What 10 operators actually run in production.

Decagon runs 90 percent of its agents on open-source models, and the reasoning is not ideological. They evaluate every model on three axes at once: cost, intelligence and latency. A smaller open model, fine-tuned on a specific business task, frequently beats a larger general-purpose frontier model on that task while also being faster and cheaper. That is the rare case where all three axes move the right way together.

What they did not do is pick a side. Open-ended work like trend analysis still goes to frontier models, because that is where breadth actually matters. The split is by task, and it gets re-decided as models change.

The app-versus-infrastructure argument is a false dichotomy, and Decagon says so directly. Successful AI companies build deep domain-specific platforms, because applications are what encode the business logic that models alone cannot provide. Their defensibility is not a model weight anyone can download. It is the accumulated complexity of making a powerful model safe, compliant and collaborative inside a rigid enterprise.

That is the part a competitor cannot copy by switching providers, and it is the part that gets stronger every deployment.

The a16z inference conversation traces open source from research curiosity to critical infrastructure, and lands on a motive worth noticing. Startups now build on open source specifically to avoid being simple wrappers. That is a positioning decision as much as a technical one. If your entire product is a prompt plus an API key, your roadmap belongs to whoever owns the API, and the distinction between open and closed models is increasingly about go-to-market strategy rather than raw capability.

Arena calls what enterprises now want AI sovereignty: owning the whole AI supply chain. The drivers are data security, cost, and the ability to fine-tune on internal data to maintain a competitive moat. That last clause is the one founders skip. Fine-tuning is not primarily a cost play.

It is how proprietary data becomes a product advantage that a competitor with the same API key cannot reproduce. Arena sizes the data market at 100 billion to 1 trillion dollars by 2030 on exactly this logic, because data is a scaling complement: as model usage grows, demand for quality data grows with it.

Arena identifies evaluation as the single biggest bottleneck in AI deployment, and it is the least glamorous item on any roadmap. The useful part is what they measure against: performance, cost and latency together, tied to real business value rather than a leaderboard. A team without its own evals cannot safely swap models, which means it cannot take advantage of the thing that makes open source attractive in the first place. Evals are the precondition for optionality, not a nice-to-have after launch.

The 20VC panel puts it plainly: enterprise value is increasingly defined by proprietary context and vector databases rather than raw model intelligence. As models commoditize, the ability to train on internal data is what differentiates. Their worked example is Palantir, whose growth they attribute to providing a sophisticated harness around enterprise data rather than a better model underneath. Customers pay a premium for answers to messy, data-heavy problems.

The harness is the product.

Max Hodak arrives at the same place from deep tech, where nobody is arguing about token costs. Being AI native, in his framing, means structuring your company data so agents can actually use it, and he treats that as a competitiveness requirement rather than a project. He pairs it with a related call: custom internal software now beats generic commercial systems, because building it has become cheap. Both moves point the same direction.

The tooling is not the constraint anymore. The legibility of your own data is.

Garry Tan draws the line the whole playbook rests on. On one side is rented corporate intelligence, whatever your provider is serving this quarter. On the other is a personal agent running on your own infrastructure, holding your own data context, compounding what it knows over time. The distinction matters most for the smallest teams, which is counterintuitive.

A solo founder has no procurement department and no vendor leverage, so the parts they own outright are a larger share of what they have.

Tan's concrete instruction is unglamorous and takes about an hour. Index your personal history, emails, notes and project files, into a centralized markdown library, creating a context no public model possesses. He then extends it: capture repeat task logic into reusable skill files so the system compounds instead of resetting every session. He is also blunt about where those files live.

Skill files sitting in an employer-controlled repo mean your expertise can be extracted without you, which makes file ownership a question worth answering deliberately.

From the Buzz walkthrough, the practical version for small teams. Running models locally keeps work out of proprietary platforms and out of reach of arbitrary model restrictions or price changes. The same setup lets a team pool compute across machines, so limited hardware stops being the reason you default to a frontier API. Treat one local workload as an insurance policy: you find out what actually breaks while the stakes are low, rather than during a pricing change you did not choose.