The Agent Stack Is Splitting in Two

The most expensive mistake in agent design right now is using the same model for everything. You reach for a frontier model to decide whether to call an API, then use that same model to format the JSON payload. One of those tasks needs a physicist; the other needs a competent clerk. Paying physicist rates for clerical work isn't just wasteful — it's bad engineering. It couples your agent's intelligence to its operating cost in a way that makes both worse.

Meta's release of Muse Ember makes this split concrete. It's a small model built specifically for what agents actually spend most of their cycles doing: tool calls, routing, and data extraction [1]. At 10 cents per million input tokens, it undercuts Claude Haiku 5.5 and GPT-6 Luna by a wide margin [3]. Meta claims it delivers more intelligence per dollar on these repetitive tasks, while freely admitting it falls short on actual programming [1]. That admission is the interesting part. They're not selling a model that does everything; they're selling a model that does the boring parts of agency extremely cheaply.

The execution layer becomes a commodity

For the past two years, the default agent architecture has been monolithic. One model — usually a frontier one — handles planning, reasoning, tool selection, and the mechanical work of structuring outputs. This made sense when smaller models couldn't reliably produce valid function calls or follow routing instructions. But that reliability threshold has been crossed. Muse Ember isn't the first small model to handle tool use competently, but its pricing and Meta's explicit positioning of it as an agent execution engine signal that this layer is now a commodity market.

The implication for builders is that your agent's architecture now has an obvious seam. The reasoning layer — where you need actual intelligence to decompose tasks, handle ambiguity, or write code — stays with a frontier model. The execution layer — where you need fast, reliable, structured outputs from known patterns — moves to something like Ember. The two layers can be different models, from different providers, optimized for different things.

What this means for evaluation

This split complicates evaluation in useful ways. You can no longer benchmark your agent as a single black box and call it done. An agent that routes intelligently but formats tool calls sloppily has a different problem than one that formats perfectly but routes stupidly. When the reasoning and execution models come from different vendors, you need evals that isolate each layer. That means tests for tool-call schema adherence, routing accuracy under prompt variation, and extraction fidelity that run independently of your planning evals.

It also changes how you think about fallback. If your execution model is cheap enough, you can afford to run it multiple times with different prompts and vote on the output — a pattern that's prohibitively expensive with frontier models. Reliability through redundancy becomes a legitimate strategy when the redundant calls cost fractions of a cent.

The Instagram lesson

There's a second signal worth noting, though it comes from a different direction. Instagram's Effect Builder now generates AR filters from AI prompts [2]. This isn't agent infrastructure — it's a consumer feature. But it illustrates the same pattern from the other side: AI is moving into execution roles where the output is a structured artifact, not a conversation. A prompt produces a filter, not a chat message. The model is doing tool use, just wrapped in a user-friendly interface.

For agent builders, this is a reminder that structured output is becoming the default expectation, not a specialized capability. When consumer apps treat prompt-to-artifact as a normal feature, your agent's ability to produce valid JSON on the first try stops being impressive and starts being table stakes. The differentiation moves upstream to the reasoning that decides what JSON to produce and why.

The practical takeaway is straightforward. Look at your agent's token consumption and separate it into reasoning work and execution work. If more than half your spend is on structured output generation, routing decisions, or schema adherence, you have a seam where a model like Muse Ember belongs. The cost difference isn't marginal — it's an order of magnitude — and the engineering benefit of decoupling intelligence from execution will compound as both layers evolve at different speeds.