State of Agentic Product Manager 2026

In 2026 the model stopped being the product, and the job of the agentic product manager changed with it.

That sounds like a slogan, so let me be precise. For one, open-weight models now handle a large share of real work at a fraction of what frontier APIs charge. Meanwhile, the price of a GPT-4-class token has fallen roughly 60× in three years. On Terminal-Bench, an agent benchmark, third-party harnesses (the code around the model) held a 21.8-point advantage. However, it shrank to about 3 points in eight weeks once the labs pulled the harness in-house.

And yet closed labs still collected 96% of the revenue at the model layer in 2025.

Those facts look contradictory until you read them as one system. Read one at a time, the 2026 reports look like a list of unrelated trends. However, read in order, they form a single chain. Moreover, every link in that chain lands on a product manager’s desk.

This is a long post. First of all, it walks through the evidence from two primary sources (Mozilla’s State of Open Source AI v1.1 and the OpenRouter and a16z study of more than 100 trillion routed tokens). Then it turns to the part I care about most: what happens to the PM role when building gets cheap. Specifically, which half of the job grows, which half shrinks, and how to move your own week from one to the other in 90 days.

So if you only have a minute, here is the whole argument on one page.

The short version

Six findings, one chain:

1. Tokens got cheap, so open weights won the volume.
2. Cheap tokens were not saved, they were spent. Instead, usage exploded on bigger, longer, more autonomous jobs.
3. Memory got expensive, so cost moved from compute to state.
4. Price per token stopped predicting cost, so the unit became the solved task.
5. The harness decides the score, so the product moved into the loop around the model, and the labs are pulling it in-house.
6. Production is still hard and owners are buying the layer, so what is left to win is operations and distribution.

Then comes the implication for our profession. PM work splits into a half that grows with cheap building and a half that shrinks under it. In particular, five disciplines (evals, harness, routing, cost and ops) make up the growing half. However, most teams have nobody who owns them.

1. Open wins the tokens. Closed wins the money.

Start with the market, because it explains everything downstream.

Closed providers took 96% of model-layer revenue in 2025. Over the same period, however, open-weight models carried roughly three in ten routed tokens. By August 2026 they also held 8 of the top 10 slots on OpenRouter, seven of them from Chinese labs.

Both facts are true at once because the two camps are playing different games.

• Closed labs run a margin game. They sell the hardest reasoning to the buyers with the highest willingness to pay. They also sell certainty: support, indemnity, a phone number to call. As a result, revenue per token is high.
• Open weights run a volume game. They offer good-enough quality at a price that makes high-throughput work viable. In contrast, revenue per token is low, sometimes near zero, because the weights are free and the hosting is competitive.

Why coding tipped the volume

The workload that tipped the volume is coding. Programming went from about 11% of routed tokens in early 2025 to about half by late 2025. Agentic coding burns tokens in long loops, and it is extremely price-sensitive. Besides, on a router, switching models is a config change. That is why a cheaper model can win share in weeks, not years.

What it means for the agentic product manager: usage share and revenue share are now two different leaderboards. So if your roadmap reports “tokens served” as a success metric, you are measuring the open-weight game. Meanwhile, you are probably being paid in the closed one. Therefore, decide which game each feature plays. For example, a feature that answers a high-stakes question once a week is a margin feature. By contrast, a feature that classifies ten million support tickets is a volume feature. They should not run on the same model, the same contract or the same success metric.

2. Cheaper tokens, way more tokens

Here is the part most forecasts got wrong.

The intuitive expectation when prices fall is that buyers pocket the savings. If AI gets 60× cheaper, companies should spend less on it. In fact, that is not what happened, and it is not what usually happens. In 1865 the economist William Stanley Jevons noticed that more efficient steam engines did not reduce Britain’s coal consumption. They increased it, because cheaper energy made new uses of coal worthwhile. When a resource gets cheaper, total demand often goes up, not down.

AI is following the same pattern. In short, developers stopped rationing. Instead of asking short questions, they started handing the model much bigger jobs:

• Whole codebases and huge documents in one prompt. As a result, context grew by orders of magnitude.
• Agents running on loop in the background, testing, fixing and retrying on repeat. Consequently, calls multiplied.
• Reasoning models writing thousands of hidden thinking tokens before answering. Output per answer also grew.

Meanwhile, normal chatbot users did not suddenly type ten times more prompts. That demand is inelastic: people only have so many questions. The growth came from developers and automated systems, whose demand is elastic. Today more than half of tokens run through reasoning and agentic loops. In addition, programming alone is about half of routed volume.

The bill and the memory squeeze

Two consequences follow, and both matter more than the headline price cut.

The bill. Price per token falls, but tokens per task rise. As a result, cost per task can go up even as the price list goes down. For example, on one benchmark the open-weight K3 used about 130M output tokens against a 63M median. That is roughly twice as many to get the same work done.

The memory squeeze. Big contexts and long loops land on memory. Moreover, memory is the one input that got more expensive, as the next section shows.

There is also a loop here. More volume means more scale, and more scale makes tokens cheaper again. In turn, cheaper tokens bring more volume. So this is not a one-off price drop. Instead, it is a flywheel, and it is still turning.

What it means for the agentic product manager: developers stopped rationing, so somebody else has to. As a result, per-task cost caps, loop limits on agents, routing rules and cache design are now product decisions. However, in most teams they are nobody’s job.

3. Compute got cheap. Memory got dear.

A GPT-4-class token costs about $0.40 per million today, 60× less than 37 months ago. Over roughly the same period, however, DRAM spot prices rose about 700%. In other words, the price on the pricing page fell, but the cost of holding context did not.

In fact, Mozilla’s report names the KV cache as the primary cost variable in inference now. The mechanics are simple when you see them:

• To begin with, prefill, the work of reading the prompt into the model, takes 85–95% of GPU time in agent workloads.
• A cache hit skips most of that work, because the model has already read the same prefix. By contrast, a cache miss costs roughly 10× a hit.
• Agents make this worse and better at the same time. Long loops carry the same system prompt, tools and history on every call. So depending on how the prompt is assembled, they are either very cache-friendly or very expensive.

Here is the consequence nobody puts in a PRD. Two teams on the same model, shipping the same feature, can pay bills ten times apart. For example, put a timestamp or a user ID at the top of a prompt and every request is a miss. On the other hand, put the static parts first (system prompt, tool definitions, schemas) and most requests hit.

What it means for the agentic product manager: prompt order is a pricing decision. Therefore, cache hit rate belongs on the same dashboard as latency and conversion. Similarly, “design for the cache” belongs in the spec, not in one engineer’s head. In short, if you own the unit economics of an AI feature, you own the cache.

4. Price per token lies

On the same agentic benchmark, the open-weight K3 solved tasks for $0.86 each. By contrast, Opus 5 cost $2.03 and Fable 5 cost $3.15. In other words, K3 was 2.4× and 3.7× cheaper per outcome.

However, the interesting part is how it got there. In fact, K3 used roughly twice the output tokens of the median model. It was cheap per task despite being verbose, because its low price per token absorbed the extra tokens. Still, that will not always hold. A verbose cheap model can cost more per task than a terse expensive one. Unless you measure, you cannot tell which from a price sheet.

The formula, however, is not complicated:

Cost per solved task = (input tokens × input rate + output tokens × output rate) ÷ tasks that passed

Two details make it bite. First of all, output tokens cost several times as much as input tokens (6× on OpenAI’s current list prices). As a result, agents that write a lot (code, reports, actions) have very different economics from agents that mostly read. In addition, the denominator is tasks that passed, not tasks attempted. So a cheap model that fails often is not cheap.

What it means for the agentic product manager: the unit of AI economics is the solved task, not the token. Therefore, make cost per solved task the number on the roadmap, the dashboard and the business case. It is also the number that lets you defend a model switch to finance, in either direction.

5. The competition moved to the harness

On Terminal-Bench 2.0 in May 2026, third-party harnesses held a 21.8-point advantage. In other words, that score came from the loop around the model: its tools, its context, its retries and its self-checks. Then the labs pulled the harness in-house. As a result, by Terminal-Bench 2.1 the advantage had compressed to about 3 points in eight weeks.

The ecosystem numbers say the same thing. For instance, the MCP SDK is downloaded about 196M times a month on npm (tracked independently). That puts it ahead of the OpenAI SDK at 131M and the Anthropic SDK at 116M. So builders are standing on the protocol that connects models to tools, not on any single vendor’s client.

Why the harness is the product now

That is the real lesson: the labs are taking the harness back, because that is where the score was. The harness is the code on the user’s side of the model. It also includes orchestration, tools and context, memory, sandboxes, evals, permissions, payments, and now training loops too. In the same way as the browser in the 2000s, it is where the contest between owners and renters restarts.

Two layers in that stack are still unsolved, and they are where the next fights will be:

• Permission and identity on the write surface. Reading is easy to allow. Writing (spending, sending, deleting, committing), however, needs authorization, and there is no standard for it yet.
• Portable adapter formats for fine-tuned weights, so a customization is not locked to one host.

What it means for the agentic product manager: the model is becoming a swappable part. Instead, the product is the harness: your tools, your context, your evals and your guardrails on what the agent may write. That is product design work, although most of it has no owner yet.

6. Ships easy. Deploys hard.

79% of developers use open models. But open models reach production 12 points less often than closed ones, and about half run a hybrid of open and closed models side by side. In short, trying an open model is now the default. Keeping one in production, however, is not.

Specifically, the report names three reasons teams fall into that gap, and none of them is model quality:

Churn driver	What breaks	What the PM owns
Maintenance	Weights, serving stacks and quantizations keep moving, and upgrades have no owner	An upgrade cadence and a named owner for every model in production
Integration	Tool calling, auth and observability that a closed API ships in the box have to be built	A gateway, plus the integration backlog budgeted like platform work
Eval quality	Without evals that match the workload, nobody can prove a switch is safe	Task-level evals written before the migration, not after it

What it means for the agentic product manager: the production gap is an operations problem. That makes it a product problem too. After all, each of those three drivers is a decision about ownership, budget or acceptance criteria. Engineering can build the gateway. However, someone has to decide that it exists, who maintains it, and what “safe to switch” means.

7. Owners are buying the layer

Two deals in 2026 show where the people with the most money think the value went. First of all, NVIDIA paid $12.93B for Hugging Face. That gives it the hub where open weights are published, right next to the chips that run them. Then, on August 19, 2026, Stripe bought OpenRouter. That gives it the router that sends tokens across providers, as well as the meter and the bill on top.

Neither buyer makes frontier models. Instead, both bought a piece of distribution: where developers pick a model, and where model traffic gets routed and billed. When the model itself commoditizes, value collects at the chokepoints around it: the shelf, the switchboard and the till.

What it means for the agentic product manager: your dependency map now has more than one vendor on it. Think of the hub you pull weights from, the router you send traffic through and the meter you bill on. Each one is owned by someone with their own strategy. Therefore, treat them as platforms you may need to leave. In short, it is the same argument for a gateway as in section 6.

Where the value went

When you put the six findings together, you get a map of where value moved and who owns each layer.

Layer	What it is	Who owns it
Model weights	The thing everyone benchmarks	Commoditized, roughly 60× cheaper
Harness	The loop around the model	Being claimed by the labs
State	Memory and cache	Nobody. No portability standard exists
Router	Which model plays which task	Nobody. Usually decided once and never revisited
Write surface	What agents may do	Nobody. The only layer with essentially zero products

The bottom three rows are the opportunity. They are unowned, even though they are where the cost and risk now live. Above all, they are product decisions before they are engineering ones.

Connecting the dots: PM work splits

Every finding above lowers the cost of building something. For example, tokens and open weights got cheaper, and harnesses now move scores by double digits. In other words, this is the Jevons story again, applied to software itself. When building gets cheaper, organizations build far more: more agents, more features, more experiments.

So the honest answer to “will AI replace PMs?” is that it depends which half of the job you mean. The agentic product manager and the traditional product manager are drifting apart. However, more things being built does not mean more of every kind of PM work. Instead, the work splits.

• Elastic work expands. Its demand grows as building gets cheaper. After all, every new agent needs someone to define what “working” means and design its loop. It also needs someone to pick its models, own its unit cost and run it safely. So more agents means more of this work.
• Inelastic work contracts. It stays the same size while tools absorb it. Status reporting, ticket-writing and light analysis do not grow when there are more agents. In fact, dashboards and agents already do much of it.

Each finding creates a job

The six findings tell you exactly which work expands, because each one created a job with no clear owner:

Finding	The job it creates	Discipline
Open wins tokens, closed wins money	Decide which workload plays which game, and re-sort as prices move	Routing
Cheap tokens, way more tokens	Cap cost per task and limit runaway loops	Cost
Cost moved to memory	Design prompts and context for the cache, and own the hit rate	Cost
Price per token lies	Measure and report cost per solved task	Cost
The harness decides the score	Own tools, context and the loop as product surfaces	Harness
Ships easy, deploys hard	Write the evals that define “safe to switch” and “working”	Evals
Owners buy the layer	Own the gateway, fallbacks, upgrade cadence and vendor exposure	Ops

Consider the spreadsheet. It did not kill finance. Instead, it sorted it. Fewer people were needed to type numbers into ledgers. Meanwhile, the people who built models on top of the spreadsheet became the function. Similarly, AI will not kill product management. It will sort it.

The five disciplines of the agentic product manager

The expanding half of the job, the work of the agentic product manager, comes down to five disciplines. However, they are not five separate roles. Instead, they sit on one loop that every agent runs, from a user’s task to a solved task.

First, a task gets routed to a model and runs inside a harness. Then it passes or fails an eval, and either solves the task or loops back to fix the harness. Meanwhile, cost is measured across the whole run, and ops wraps all of it.

What each discipline owns

Discipline	The question you answer	The metric you own	The artifact you write
Routing	Which model plays which task, and when do we re-sort?	Share of traffic on the cheapest capable model	The routing table and its review cadence
Harness	What tools, context, memory and retries does the agent get?	Success rate per harness change	The loop spec: tools, context order, guardrails
Evals	What does “working” mean for this task, and how do we know?	Task success rate on your own eval set	The eval suite, written before the build
Cost	What does one solved task cost, and what moves it?	Cost per solved task; cache hit rate	The unit-economics model behind the business case
Ops	What happens when a model, vendor or tool fails or changes?	Failover time; upgrade lag; incidents per agent	The runbook: fallbacks, upgrades, permissions

Start with evals, because they are the new spec. After all, you cannot route, cost or operate something you cannot measure. Moreover, section 6 showed that weak evals are one of the three reasons open-model deployments fail.

A note on routing in particular: the line between “stakes” work and “volume” work is not fixed. Stakes work belongs on a closed frontier model, while volume work belongs on open weights. My working estimate is that it slides every few months as open models improve and prices move. That is why routing is a discipline with a review cadence, not a decision you make once at launch.

The Leverage Audit: three moves in 90 days

Knowing which half of the job is growing is useless unless you can see which half your own week is in. That is why the Leverage Audit has three moves, and the first takes twenty minutes.

Move 1: Map your actual week. Use your calendar rather than your job description. First, list last week’s tasks and tag each one Expand or Contract. Then compute the share of hours that went to elastic work.

• Under 30%: Exposed. Your week commoditizes first.
• 30–60%: Split. The most common result, and the most dangerous, because it feels fine.
• Over 60%: Positioned. You are already standing where the demand lands.

Move 2: Convert toward the five disciplines. In fact, almost every contracting task has an expanding twin:

Contracting task	Its expanding twin	The shift
Status reports	Evals	From “what happened” to “what changed, and did it still work?”
Ticket-writing	Harness	Spec the loop, not the ticket
Coordination	Ops	Design the gate and own the fallback
Analysis-lite	Routing	Decide which model plays which task
Budget tracking	Cost	Cost per task, per outcome

The trap is doing both: keeping the contracting task and adding the new work on top. As a result, your hours grow but your position does not move. Instead, the move is conversion. So hand the old column to an agent and claim the new column as yours.

Move 3: Reposition your title before it gets repositioned for you. Job postings are already sorting upward into “agentic PM,” “AI PM” and “forward-deployed PM” roles. These roles ask for evals, specs and judgment. Meanwhile, the contracting column reads like “stakeholder management and sprint ceremonies.” You do not have to change jobs. However, you do have to change which column your week bills to.

How to run it with the workbook

Paid subscribers get the Leverage Audit workbook. You fill in the yellow cells, and then everything else calculates. Overall, the first pass takes about twenty minutes.

1. Start on Start Here. Then read the verdict bands and the five conversions.
2. Clear the example. My Week opens with a sample week labelled EXAMPLE. So overwrite or delete those yellow cells.
3. Log last week from your calendar. Pick each task from the dropdown or type your own, then enter the hours. The tag, discipline and twin task fill in by themselves.
4. Tag anything marked UNTAGGED. Choose Expand or Contract in the Override column. Untagged hours are left out of your score until you do.
5. Read your Dashboard. Your elastic %, your verdict, the hours you need to convert to reach 60%, and three charts. Above all, this is the page to show your lead.
6. Build your 90-day plan. Each contracting area is matched to its new discipline, with what to hand to an agent. By default it moves 75% of each area’s hours. However, you can change any yellow cell to set your own target. Finally, the plan projects your score at days 30, 60 and 90.
7. Do the conversion rather than both.
8. Then re-score every 30 days and compare against the projection.
9. Product leads: roll up the team on the Team Rollup tab for each PM’s verdict and the org-wide elastic share.

Six moves for product teams

The audit is for your career. By contrast, these six moves are for your team’s roadmap, one per finding:

1. Route by workload. Frontier models for high-stakes reasoning at modest volume; open weights for high-volume routine work and sensitive data. Re-sort every quarter, because prices move faster than roadmaps.
2. Design for the cache. Static content first, no volatile data at the top of the prompt, hit rate on the dashboard.
3. Price per solved task. Instead of price per token, use cost per outcome in every business case.
4. Own the harness. Treat tools, context, retries and guardrails as the product, and the model as a part you can swap.
5. Write evals before migrating. Task-level evals are what make a model switch safe, and their absence is a top reason deployments churn.
6. Plan for hybrid behind a gateway. One routing layer you control lets each workload move between open and closed models. It also lets you switch vendors when prices and owners change.

None of these moves requires beating the frontier. After all, the frontier race belongs to a handful of labs. In contrast, routing, unit cost and operations belong to every product team, and that is where most of the value now sits.

Three questions for Monday

Ask these in your next product review:

• What is our cost per completed task? When the answer is per-token, that is gap number one.
• When did we last re-sort which tasks play which model? If the answer is “at launch,” you are probably overpaying or under-serving.
• Who owns what our agents may do? When the answer is “the vendor default,” that is gap number two.

What to watch next

• Does revenue follow tokens? If closed providers cut mid-tier prices to defend share, the 96% starts to move.
• Does memory stay scarce? Cache economics depend on DRAM prices. If they ease, the 10× penalty shrinks, but it does not disappear.
• Who solves the write surface? Permission and identity for agents that act, not just read, is still the harness layer with no clear winner.
• Do the new owners stay neutral? A hub owned by a chipmaker and a router owned by a payments company each have reasons to tilt the field.
• Does cost per solved task become a standard metric? The first widely used benchmark that reports it alongside accuracy will change how teams pick models.

The one-line version

The model is rented. However, everything around it is up for grabs: the evals, the harness, the state, the permission surface, and the discipline to re-route every quarter. The agentic product manager who moves toward that work will have more of it than ever. Meanwhile, the ones who stay in the contracting column will find their week quietly automated around them.

Get the next issue

If this was useful, the newsletter goes deeper every week. Each issue brings agentic AI playbooks and field reports for product people, plus a file you can use on Monday. No jargon, no hype. So join on Substack.

---

Sources

• Mozilla, State of Open Source AI v1.1 (September 2026; full PDF): adoption and the production gap, operational drivers, the 96% revenue split, the token price decline, DRAM, KV cache, prefill and cache economics, cost per solved task, Terminal-Bench, SDK downloads, the OpenRouter top 10, NVIDIA–Hugging Face and Stripe–OpenRouter.
• OpenRouter with a16z, “State of AI: An Empirical 100 Trillion Token Study” (December 2025; a16z summary): open-weight share of routed tokens, programming share, reasoning share.
• OpenAI API pricing: output vs input token prices.
• Mozilla’s announcement: “Mozilla’s Inaugural State of Open Source AI Report Is Here” (July 14, 2026).

The work split, the five disciplines, the Leverage Audit, the six moves and the readings of the two acquisitions are Product Mindset analysis, not findings from the reports.