The AI Efficiency Frontier: How Enterprises Scale Agentic AI Without Letting Cost Outrun Value
The 8-Digit Line Item
The question facing CIOs and Chief AI Officers is no longer whether foundation models can produce useful work. It is whether agentic systems can do that work repeatedly, securely, and economically across the enterprise.
Making agentic work reliable at enterprise scale is a different problem. A chatbot answers one question in seconds. An enterprise agent researches across sources, calls tools, spawns subagents, generates documents or software, checks its own output, recovers from errors, and runs for minutes or hours. Every additional step consumes inference, adds latency, and creates another opportunity for failure.
At that scale, the economics change quickly. In a recent conversation with a global systems integrator, I learned that an AI-services program for a household-name manufacturer had grown from a few million dollars to tens of millions as adoption expanded, with inference consumption driving much of the escalation. Once AI moves into production workflows, inference cost stops being an engineering metric and becomes an executive constraint.
At Genspark, we've spent the past year engineering against that constraint directly. Our conclusion is simple:
The enterprise should not pay frontier-model prices for every step of every workflow. It should pay for the right level of intelligence at the point where that intelligence changes the outcome.
The rest of this post lays out how we do that: the economics behind it, the architecture we run in production, and the discipline we believe every enterprise will need next as agentic systems move from pilots into daily work.
Intelligence Got Cheaper. Why Doesn't It Feel That Way?
The unit price of intelligence has been falling roughly tenfold per year as newer, cheaper models keep matching what only the frontier could do twelve months earlier. So why doesn’t AI feel more affordable? Because the bill is the product of two numbers:
Cost per task = price per token × tokens per task.
The first factor fell 10×. The second rose faster: a chatbot exchange consumed a few thousand tokens; a long-horizon agent that researches, plans, calls tools, and revises its own work consumes millions. Enterprises aren't paying more per unit of intelligence, instead they’re buying vastly more units per outcome.
And the real denominator is stricter still: A cheap model is only cheap if it succeeds. If the output has to be retried, corrected by a human, or escalated to a stronger model, the real cost goes up quickly. The metric that matters is cost per successful task, and the goal is not to minimize tokens but to move the efficiency frontier: more valuable work per dollar, without lowering the standard. That will not happen just by waiting for models to get cheaper. It has to be engineered. It starts with a decision most enterprises get wrong. How many models should they build on?
Why No Enterprise Should Bet Its AI Strategy on One Model
Enterprise work is heterogeneous. Research, coding, document generation, visual design, extraction, and synthesis differ in reasoning depth, latency tolerance, data sensitivity, and risk. No single model is best at all of them, and no single price is right for all of them.
The model landscape is just as dynamic — consider only the past week. On July 30, OpenAI cut the price of GPT-5.6 Luna by 80%, to $0.20 per million input tokens. One day later, DeepSeek shipped V4 Flash 0731, a substantially stronger model at the same rock-bottom price of $0.14. And that came just days after Kimi K3, an open-weight release, landed alongside the strongest closed models on coding at a fraction of their price. Three providers, three moves, one week. The best option today may not be the best option next quarter. It may not even be the best option next Friday.
Against that backdrop, a single-model architecture concentrates three risks at once. Economic risk: pricing and usage growth are tied to one provider's decisions. Capability risk: every workload inherits one model's weaknesses along with its strengths. Operational risk: availability, policy changes, and roadmap sit outside the enterprise's control. Any one of these would concern a CIO looking at any other category of vendor; AI is currently the only major spend category where betting everything on one supplier is treated as normal.
Genspark is built on the opposite premise. We connect to a broad ecosystem of frontier, closed, and open-weight models. Then we continuously evaluate which model, or combination of models, is best suited to each part of a workflow. We don't need to predict a permanent winner. When the frontier moves, we test the new model against real work and adopt it where it improves the quality-cost equation. We make sure that when the next winner arrives, our users can benefit right away
Three Execution Layers, One Evaluation System
That premise is what makes real cost engineering possible: access to every model, and the ability to combine them freely. We manage inference through three execution layers, each answering a different question:
| Layer | Question it answers | Cost lever |
|---|---|---|
| 1 · Model routing | Which model should run this task? | Never pay frontier prices for non-frontier work |
| 2 · Fine-tuning | Can a cheaper model be made stronger? | Turn open-weight models into domain experts |
| 3 · Advisor pattern | Can frontier reasoning be reserved for frontier moments? | Pay frontier prices only where they change the outcome |
All three are governed by a fourth piece: a continuous evaluation system. That matters because routing, fine-tuning, and advisor systems are becoming more available across the industry. What's defensible is a production system that can tell, from real task behavior, which optimization improves outcomes and which quietly degrades them. More on that after the layers.
Layer 1: Automatic Model Routing
Not every task needs the most powerful model.
A lightweight router evaluates each incoming task based on its type, context length, tool use, and historical performance across similar task families. Repetitive, well-defined work goes to more cost-efficient models. Complex reasoning goes to frontier models.
When a new model ships, it enters our evaluation pipeline the same day, gets benchmarked on our real task distribution, and graduates into the pool through gradual rollout. We also track router regret, the share of tasks where, in hindsight, a different model would have done better. That way, the router itself is measured, not trusted.
Routing also doesn't stop at the first request. Our agents spawn subagents constantly, and which model drives a subagent is itself a launch parameter. In a complex research task, the main agent can split the work into focused lines of inquiry. Each subagent handles a narrower, more structured piece of the problem, so it can often run on a lower-cost model without sacrificing quality. That's what makes fan-out affordable: the main loop can spin up many subagents in parallel without the cost multiplying with it. Routing isn't a triage desk at the entrance. It's a decision at every node of the execution graph.
For an enterprise, this same mechanism doubles as a governance layer: routing rules can encode not just which model is best for a task, but which models are approved for it — by data sensitivity, geography, or risk tier.
Layer 2: Fine-Tuning Open-Weight Models
Routing picks the best existing model. Fine-tuning makes a better one for a specific job. It fits when a task is high-volume, repetitive, and well-defined: clear output format, clear quality criteria, enough data to learn from. Under those conditions, a tuned open-weight model routinely beats general-purpose frontier models at a fraction of the price and latency. Fine-tuning isn't free, though — it takes data, training, evaluation, and ongoing monitoring for drift — so the decision should rest on training payback and sustained task volume, not novelty.
We treat fine-tuning as a continuous practice, not a one-off project. As stronger base models ship, we re-tune on the newest ones and keep improving the experience. In October 2025, working with Fireworks AI, we applied reinforcement fine-tuning to Kimi K2, a trillion-parameter open-weight model, for our Deep Research agent. The tuned model outperformed the closed frontier model we started from, with reward quality improving from 0.76 to 0.82, 33% more tool calls, and 50% lower costs (full numbers here).
[Table 1: — reward score & tool calls across models on Fireworks]
The practice isn't limited to open weights, either: in November 2025, using OpenAI's Agent RFT, we trained a reasoning model as the final harmonization layer for slides. It judged content and visual quality together, improving bad cases by 88%. OpenAI later featured the work in a Build Hour. And most recently, in early 2026, when Kimi K2.5 arrived, we tuned it for single-page slide writing — with even better results, at a fraction of frontier cost and latency.
None of this works without a steady stream of strong open-weight releases. Fortunately, that stream keeps accelerating, which is good news for the entire ecosystem. Open weights let every organization match the right model to the right job at the right cost, free from lock-in — an openness we actively support and believe is worth sustaining.
Layer 3: The Advisor Pattern
The third layer inverts the usual agentic setup: a cheap executor model does the bulk of the work and consults a stronger advisor model only at critical junctures — planning, error recovery, ambiguous instructions. In long-horizon tasks especially, most steps are mechanical execution, so nearly all tokens are generated at cheap-model rates. Total cost lands near the cheap model running alone; quality lands near the expensive model running everything. A junior developer who checks in with a senior architect when stuck.
This pattern isn't unique to us. Anthropic offers a server-side advisor tool that automatically feeds the entire conversation to the advisor. Our implementation differs: the advisor is an ordinary tool, and the executor constructs the call itself, distilling where it's stuck into an explicit question. This keeps the pattern open to any executor/advisor pairing across providers. It comes with a limit: the advisor doesn't share the full context, and only sees what the executor chooses to share. We accept that trade, and our evaluation loop (below) tells us when it stops paying.
Evaluation: The Layer Underneath the Layers
Here is what the three layers deliver when they compound. Our slide-generation workflow spans research, content planning, page writing, visual reasoning, rendering, and quality review. With the new harness, routing, tuned specialists, and the advisor pattern work together. The cost of generating a slide page fell to roughly one-fifth to one-tenth of the previous architecture, at comparable quality in our internal evaluations.
The question any CIO should ask before believing that sentence: how do you know quality didn't quietly fall off a cliff?
Fair question, and it points at the real foundation. Every decision across the three layers is a trade between quality and cost. Which model should handle this task? When should a tuned model replace a frontier one? When should the advisor step in? Without sufficient evaluation, those trades are blind. With it, you can be aggressive. The depth of your eval determines how far your cost optimization can safely go.
Genspark's platform produces many output types: slides, sheets, documents, designs, coding projects. Each output type has its own grader agent, and the graders do two jobs. First, they read the agent's full execution trace. They score not just the final artifact, but the process behind it: whether the right tools were called, how many detours the agent took, where tokens went, and where the workflow slowed down.
Second, they incorporate the most honest signal available: user hindsight behavior. Did the user adopt the output as-is, regenerate it, or rewrite it by hand? No synthetic benchmark argues with that. It isn't a perfect signal since users edit for preference as well as correctness, so we weigh it alongside the graders rather than treating it as ground truth.
The grader output feeds all three layers at once. Routing win rates come from it. Fine-tuning reward signals come from it. Advisor invocation policies are tuned against it. It's one loop: every optimization is proposed by the architecture and ratified by the evals.
Cost optimization without evaluation is just corner-cutting. With it, it's engineering.
From Token Management to AI FinOps
A decade ago, cloud spend went through a familiar arc: early enthusiasm, runaway bills, and then a discipline called FinOps that turned cost from a monthly surprise into a managed, cross-functional concern. Enterprise AI is at the start of that arc, with one difference: an AI control plane has to manage more than consumption. Model choice affects quality, data policy, and vendor risk all at once, so the discipline has to govern them together.
Call it AI FinOps.
The anchor metric is the one introduced earlier — cost per successful task — tracked alongside quality-adjusted cost per workflow, the share of work routed away from frontier models, spend concentration by provider, and the rates of fallback, retry, and human correction. Routing, fine-tuning, and advisor models are techniques. The durable capability is the learning system above them: one that evaluates every new model against real work, adopts what moves the efficiency frontier, rolls back what does not, and reinvests the savings in verification and user experience.
That system gets more valuable every time the model market moves. Which, as the last week of July showed, is often.
The Enterprise Advantage
Go back to that 8-digit line item. A program swelling from a few million to tens of millions can start to sound inevitable, as if intelligence simply costs this much. It doesn't. It is a governable line: pay for the right intelligence at the moments that change the outcome, and govern that trade continuously, across every workflow.
In the years ahead, access to capable models will not differentiate anyone. Every enterprise will have it, from many providers, at falling prices.The companies that pull ahead will be those that can deploy intelligence across thousands of workflows while holding quality, control, and economics together. That is a systems capability, not a procurement decision.And it is the capability we are building at Genspark.
The next frontier isn't more capable models. It's more efficient systems.
—Kay Zhu, Co-founder and CTO of Genspark.
