Model companies are moving up the stack. Anthropic has grown on the back of Claude Code and competes directly with Cursor. OpenAI bought OpenClaw. Both are forward deploying engineers into enterprises to embed their models into workflows. On the surface, the application layer looks like it’s being subsumed from below.

On a closer look though, I think it’s premature to call the application layer won by the model companies. The more model companies push into applications, the clearer it becomes where they cannot win. But to see why means understanding what an AI application actually is, because it’s not what most people think.

The application is a harness

Most people think of an AI application as the UI (dashboards, buttons, alerts, chat) with a light backend that is mostly powered by the models, but that undersells what is actually being built by the best application companies today. Underneath the interface, an AI application is a harness: an orchestration layer that structures how agentic tasks are executed. Harnesses consist of:

• Stages and roles that define the phases of tasks and distribute these tasks to distinct subagents
• Contracts that outline the strict requirements for task steps including inputs and outputs, format, and when to stop or retry
• Hooks for deterministic non-LLM actions like running tests, parsing code or retrieving data
• Memory systems that define what information persists and how it can be accessed in the future
• Referential list of error modes that can be used to trigger recovery behavior

A model and harness are analogous to a processor and operating system. While the model does the raw computation to produce tokens, the harness decides which files to retrieve, how to construct the prompt, which tools the model can call, when to reflect on a failed step and retry, and how to cache results so the next run is cheaper.

A well-designed harness can make a cheaper model outperform a more expensive one. That’s the enormous design space application companies operate in. With the harness defined, the application layer’s three structural advantages follow.

Minimize tokens per outcome

Model companies sell tokens. Enterprises buy outcomes.

The model business has a specific cost structure: companies spend heavily on compute, data, and research to produce intelligence, and they have to commit to that spend well before they can charge for the result. That creates pressure to sell as many tokens as possible.

It’s no surprise that model companies’ own harnesses (e.g. Claude Code, Codex) are not optimized for efficiency. They optimize for task completion quality, and manage tokens mostly to avoid hitting context window limits. As context windows grow to over 1M tokens in the future, the token usage of these harnesses will skyrocket.

Since they’re competing for adoption in an early market, they are happy to underprice the true cost of the tokens. There are reports that Anthropic serves tokens in their own products at negative contribution margin:

Cursor estimated last year that a $200-per-month Claude Code subscription could use up to $2,000 in compute, suggesting significant subsidization by Anthropic. Today, that subsidization appears to be even more aggressive, with that $200 plan able to consume about $5,000 in compute.

Given the capital intensity of model training and inference, contribution margins at some point must reflect actual costs.

The application layer has the opposite incentive. The enterprise will always want a task done for the lowest cost and the application company is more aligned there than the model company. The application wins by reducing the tokens required to reach an outcome at the same quality level. Every token saved is margin earned and value shared back with their enterprise customers.

This misalignment doesn’t shrink as token prices fall. It grows. Cheaper tokens mean enterprises will use AI for more tasks, including ones where ROI thresholds today are tighter. An application that can deliver an outcome for 100 tokens instead of 1,000 doesn’t just save money on existing work. It opens up ten times more use cases. Token efficiency expands the addressable market of tasks worth automating at all.

And token minimization is the observable output of something deeper: understanding which tokens actually matter for a given outcome. An application that has learned which steps in a legal review are redundant, which retrieval patterns waste context, and which model calls can be cached has proprietary knowledge about the workflow itself. The question isn’t about maximizing how many tokens an engineer or application uses, but rather how well each token is used, with the best able to do the most on the least tokens.

Route across models

Model companies compete with each other on the cost of producing intelligence, and they each make different tradeoffs to get there. Those tradeoffs produce different capabilities. Some models have the best raw intelligence, others are the fastest, others are strongest on specific tasks. The charts below from Artificial Analysis show this clearly: no one model family dominates across intelligence, speed and price.

An application company can exploit these differences. The harness picks the right model for each subtask at each price point, but a model company will always prefer to route to itself since it needs to prioritize its own ROI on compute, data, and research.

Some application companies are going further and training their own models on proprietary usage data. Cursor built Composer 2. Harvey and Cognition are fine-tuning specialized models. This might suggest the winning move is to go deeper into one model, not wider across many.

However, I think this conflates two things. An application company can train a fine-tuned model for tasks where it has proprietary data and route to frontier models for everything else. The best application will use its own model where it has an edge and someone else’s where it doesn’t. A model company can’t do that.

There is also a ceiling on fine-tuning. It produces diminishing returns once the model is good enough at the narrow task. Meanwhile, frontier models keep improving on general capability. The application company that locks itself into a fine-tuned model risks being leapfrogged by a competitor that routes to the latest frontier model for most of the workflow and only uses a specialized model where it has a real data advantage.

And then there is a practical ceiling too. Post-training (fine-tuning a model on task-specific data after its initial training) and reinforcement learning are hard, especially in enterprise contexts. They require compute, top researchers, and significant experience. The large labs have better access to all three. An application company can tune small, precise models as a cost-savings play on specific subtasks. But trying to fully replace foundation models through post-training recreates the same cost structure and token incentive that model companies face. That’s the wrong game for the application layer.

The right game is routing. Cross-model routing generates quality, speed, and efficiency that no single model company can replicate without routing to competitors. And it decouples the application from any one model provider’s position in the cost and capability race. If you are locked into one model family, your fate is tied to theirs. Routing turns that dependency into optionality.

The harness evolves

Token minimization and cross-model routing are advantages the application layer has today, but there is more on the horizon. Most applications today have harnesses that were hand-engineered once and then maintained manually. Some recent research suggests that doesn’t have to be the case.

Meta-Harness demonstrated that the harness can be optimized automatically. Instead of a human engineer tuning prompts and retrieval logic, a coding agent reviews what happened in prior runs (which steps failed, which succeeded, how many tokens were used) and proposes changes on its own. In their experiments, they showed harnesses outperformed hand-engineered ones while using fewer tokens. One discovered retrieval harness improved accuracy on IMO problems by 4.7 points across five models the system had never seen.

The harness improved performance across models it was never optimized for. This is a different kind of feedback loop than fine-tuning a model on proprietary data. Fine-tuning improves a model’s capability on a specific task, but those gains are locked to that one model. Harness gains are portable. They transfer to whichever model the application routes to.

The harness feedback loop also adapts faster. Enterprise workflows change: new regulations, new tools, new internal processes. A fine-tuned model needs to be retrained when the underlying workflow shifts. A harness that evolves from execution signal adapts in real time.

A second paper, Natural-Language Agent Harnesses, takes this further. It proposes expressing harness logic in natural language rather than code. This makes the harness a portable, editable artifact that non-technical users can review and modify. The enterprise domain expert who knows which steps in a workflow actually matter could shape the harness directly, without waiting for an engineer to translate their feedback into code.

This has a direct implication for how the application layer competes with model companies’ go-to-market. Model companies forward deploy engineers (FDEs) into enterprises to sit with customers, learn their workflows, and tune the integration by hand. That works for initial deployment. An FDE can configure the top 10 workflows in an organization.

But enterprise value lives in the long tail: the hundreds of smaller, department-specific processes that no field engineer will ever learn. A new compliance check that only the risk team cares about. A procurement approval flow that changed last quarter. An onboarding sequence specific to one regional office. The FDE model breaks down here because every new workflow requires more headcount, and every workflow change requires another visit.

An editable harness covers the long tail. The enterprise’s own people refine it in plain language. The application gets better at the speed of the customer’s feedback, not at the speed of the model company’s services team. A consultancy can audit a workflow once. An evolving harness learns from every execution.

Put this all together and the application becomes a system that gets better automatically. Every task it executes generates signal. That signal feeds back into the harness. The harness evolves. And because this evolution happens at the application layer, it compounds into proprietary knowledge about how to convert tokens into outcomes for specific enterprises and specific workflows. That knowledge is the moat.

So what does this mean for builders?

If you are building an application layer company, the playbook for a durable business that’s out of reach of the model companies is clear. Minimize tokens per outcome so your incentives align with the customer’s, not the model company’s. Route across models so your efficiency is unreachable by any single provider. And build your harness to evolve, so that every task you execute makes the next one cheaper and better without additional engineering effort.

The model companies will keep pushing up the stack. They will ship their own apps, deploy countless FDEs, and subsidize usage to win enterprise contracts. But each of those moves costs them margin and pulls them further from their core business of producing intelligence. The application layer doesn’t need to outspend them. It needs to out-learn them in the wild. A system that improves from its own execution history, shaped by the customer’s own domain experts, compounds in a way that FDEs and partner networks cannot match.

That is the application layer worth building.

If you are building the next great enterprise AI application, I’d love to hear your perspective on what I got right and where you disagree. Please feel free to reach out.