What is a model stack for enterprise AI agents?

A model stack is the set of AI models a company assigns to the stages of an agent's work, with one lead model per stage. Google Cloud CEO Thomas Kurian wrote on 9 October 2026 that its Gemini agent runs each job on the model that fits best, orchestrating across Google's Gemini models and Anthropic's Claude models. Anees Merchant's stage map is a one-page table for building a stack from a company's own test cases.

How does a stage map differ from choosing a model by leaderboard rank?

A stage map gives each stage of an agent's work its own lead model, chosen from the company's own cases, with the effort setting, the cost per run and a re-test date recorded beside it. Public scores are used only to build the shortlist. Reflection AI's own table lists its Beam model at 80.9 on SWE-bench Verified and 44.4 on DeepSWE v1.1, where the same table lists DeepSeek V4.1 Flash at 74.2.

Why does one AI model lead a benchmark and trail on another?

Benchmarks test different tasks, and results change with the effort setting. Anthropic's launch page for Claude Sonnet 5.5 lists it at 70.6% on Terminal-Bench 4.0 against 66.4% for Opus 5.5, while Opus leads CursorBench 4.0 by 57.8% to 55.5%. Apidog's breakdown of the launch figures shows Opus 5.5 ahead on Terminal-Bench 4.0 at every effort level below Max, including Low, where it scores 38.5% and Sonnet 5.5 scores 20.0%.

When should an enterprise test open-weight models for its agents?

Anees Merchant's advice is to include one open-weight model in every round of stage testing. An open-weight model can run on a company's own servers, which matters for stages that handle data the legal team will not send to an outside API. Recent options include Aleph Alpha's Kolibri, released on 3 October 2026 under Apache 2.0, and Reflection AI's Beam, whose weights Reflection says will follow under the same licence.

What is the first step to building a stage map?

The first step is to pick one agent and list the stages of its work as rows in a table. A stage is small enough when a person can mark its output pass or fail. Then pull ten real cases for one stage, run the current model and one alternative on all ten at two effort settings, and record the score and the cost per run. The remaining columns are an open-weight candidate and a re-test date.

No Model Wins Every Stage: The Stage Map for an Enterprise Agent Stack

A model stack is the set of AI models a company assigns to the stages of an agent's work. A stack is worth building because one launch page can show a model leading one benchmark and trailing on another. Anthropic's page for Claude Sonnet 5.5 does. Google now runs Anthropic's Claude models inside its own agent for work. The stage map below is a one-page table for choosing a model per stage from your own tests.

Google put Anthropic's models inside its own agent

On 9 October, Google Cloud CEO Thomas Kurian published a post adapted from his Gemini at Work keynote. It introduces Gemini as a single, universal agent for work. Kurian writes that the agent runs each job on "the model that fits best", orchestrating across Google's Gemini family and Claude models from Anthropic today, with other private and open models to follow. He adds that a routing tool triages enterprise workloads so that each one runs on the model with the best performance at the lowest cost.

Google sells Gemini. The same post reports that nearly 80% of Google Cloud customers use its AI products and that nearly 90% of the Fortune 100 use Gemini Enterprise. A vendor with those numbers built its work agent to send jobs to Anthropic's models as well as its own.

That post lines up with a note I wrote on 3 August. The note says organisations are making a mistake when they rely on one model, or two at most, and ignore open-source models completely. It also says no frontier model is equally strong at every task in the software development lifecycle, so a builder has to find out which model is stronger at which stage and assemble a stack from the results. My note had no numbers in it. Three launch pages, one newsletter and one third-party breakdown from the two weeks before Kurian's post supply some.

Anthropic launched Claude Sonnet 5.5 on 28 September at $2 per million input tokens and $10 per million output tokens, half the price of Opus 5.5. On Terminal-Bench 4.0, Anthropic's launch page lists Sonnet 5.5 at 70.6% and Opus 5.5 at 66.4%. On CursorBench 4.0 the order reverses: Opus scores 57.8% and Sonnet 55.5%. The cheaper model leads one coding benchmark and trails on another, and both results sit on the same page.

Reflection AI announced Beam on 5 October. Reflection says it will release Beam's weights under an Apache 2.0 licence later this month. Reflection's own table, as the page showed on 12 October, gives Beam 80.9 on SWE-bench Verified. On DeepSWE v1.1 the same table gives Beam 44.4, against 68.0 for Kimi K3 and 74.2 for DeepSeek V4.1 Flash. Google's launch post for Gemini 4 Argon, dated 30 September, claims the top DeepSWE v1.1 score at 77.9%. The same post has Argon first on AutomationBench at 51.3% and tied for first on CWE-bench v1 at 68%.

DeepSeek V4.1 Flash has a split of its own. Kim Isenberg's Superintelligence newsletter of 5 October, summarising Bloomberg Intelligence, put it sixth overall on LiveBench with 81.1, behind Claude Fable 5.1 at 83.4. In agentic coding it scored 77.3, ahead of every other model in the top 15.

I ran none of these tests. Each number comes from a page linked in this essay. Reflection's post carries a note dated 8 October saying Beam's results were revised.

Reading a launch table

Anthropic, Reflection and Google each published their own results. Apidog's 29 September breakdown of the Sonnet 5.5 launch reports that Artificial Analysis got 63.6% for Sonnet 5.5 on Terminal-Bench 4.0, seven points under Anthropic's 70.6%. Anthropic's footnote 1 says the Opus 5.5 figure on that benchmark was recorded at Xhigh effort, which it calls the model's highest score.

The tables are still the fastest way to build a shortlist, and a shortlist is the only job they get in the map below.

The stage map

The stage map is a table with one row for each stage of an agent's work and four columns to fill in. My August note named the software development lifecycle, so the example rows below are software stages I have picked for illustration.

STAGE     LEAD MODEL   SETTING AND     OPEN-WEIGHT    RE-TEST
                       COST PER RUN    CANDIDATE      DATE
-------   ----------   -------------   ------------   --------
Plan      ?            ?               ?              ?
Write     ?            ?               ?              ?
Test      ?            ?               ?              ?
Review    ?            ?               ?              ?

Every "?" is filled from your own cases, one stage at a time.

1. Split the work into stages you can score. The example rows are plan, write, test and review. An agent that handles invoices or contracts has different rows. A stage earns a row when you can hand its output to a person and get a pass or a fail back.

2. Fill the lead-model column from your own cases. Public scores give you a shortlist of models to test. On DeepSWE v1.1 the four models above span 33.5 points, from Argon's 77.9 to Beam's 44.4. Beam also lists 80.9 on SWE-bench Verified. None of these pages says a benchmark stands for a stage of your agent, and reading them that way is my inference. Your stage is a third test, built from your tickets, your codebase and your definition of done. Run every shortlisted model on the same cases for one stage, write down the winner, then move to the next row.

3. Write the setting and the cost beside every score. Apidog's breakdown of Terminal-Bench 4.0 lists both models at every effort level. At Max effort, Sonnet 5.5 scores 70.6% at $12.54 per attempt and Opus 5.5 scores 64.8% at $11.24. At Low effort, Opus scores 38.5% at $1.29 and Sonnet scores 20.0% at $0.76. Sonnet leads by 5.8 points at Max and trails by 18.5 at Low. In between, Opus reaches 57.6% at Medium for $2.94 per attempt, and Sonnet does not pass that score until Xhigh, where it gets 61.5% for $5.30. Anthropic's page gives its own split, calling Sonnet 5.5 strongest at "well-scoped everyday tasks" and Opus 5.5 "clearly stronger at complex, open-ended work requiring sustained judgment." If your team runs agents at Low or Medium to control spend, the Max-effort headline describes a model you are not running.

4. Keep an open-weight candidate in every test round. Reflection says Beam's weights arrive this month under Apache 2.0. Aleph Alpha released Kolibri on 3 October under the same licence, a German and English model that its technical report describes as built for regulated domains such as public administration, industry and aerospace. Kurian's post says open models will join the agent later. An open-weight model can run on your own servers, which matters for any stage that touches data your legal team will not send to an outside API. Test one in each round and record how far behind the leader it sits on your stage. You will want that number on the day a vendor changes its price or its terms.

5. Put a re-test date in the last column. Apidog's table records the earlier Sonnet 5 at 10.3% on Terminal-Bench 4.0 at Max effort. Sonnet 5.5 scores 70.6% at the same setting, a 60-point move in one release. Reflection revised Beam's published results three days after posting them. A map filled in before 28 September has a Sonnet entry that describes Sonnet 5.

One row, filled in with public numbers

For illustration only, treat Terminal-Bench 4.0 as your test stage and use Apidog's table as the evidence. A team that caps effort at Medium would write Opus 5.5 in the lead-model column, with 57.6% and $2.94 per attempt beside it. A team that runs at Max would write Sonnet 5.5, with 70.6% and $12.54. The two teams read the same table and end up with different rows, and each row follows from the setting that team runs. The open-weight cell stays empty in this example. The re-test date would be the day Anthropic ships its next Sonnet or Opus.

When one model is enough

Each added model is one more contract to sign and one more set of prompts to maintain. A stage map can come back with one model in every row. If your cases say so, standardise on it, and keep the dated table that shows why. Run the cases first, then set the standard.

Google's agent puts several models behind one product, and Kurian's post describes real-time spend caps set per project in the Cloud Billing Console, with the project's agent pausing when a cap is hit. A stage map gives you your own cases to check the routing tool's picks against. If you get access to the agent, run the same cases through it and compare the results with your table.

Three things to do this week

List the stages of one agent. Pick the agent your team ran most often last month and write its stages as rows. Stop splitting when each row has an output a person can mark pass or fail. My software example has four rows.
Pull ten real cases for one stage. Take them from last month's tickets or documents, each with the output a person accepted. Run your current model and one other on all ten at two effort settings. Record the score and the cost per run for each of the four combinations.
Add one open-weight model and one date. Aleph Alpha has published Kolibri's weights, and Reflection says Beam's are due this month. Put one of them in your next round. Then write a re-test date in the last column and give it to the person who owns the agent.

Footer

Anees Merchant writes one essay every Tuesday about enterprise AI, agentic systems, and the human side of the work. He is the author of Merchants of AI, a TEDx speaker, and a doctoral researcher in Human-AI Communication at the Swiss School of Business and Management.

The newsletter version, with extra commentary, goes out separately on Mondays. Subscribe at /newsletter.

See you Tuesday.