Mental models for the agentic era: 15 frameworks to decide what to automate, how much autonomy to grant and what survives

The article, published on October 19, 2026 in the Product Mindset newsletter, starts from the premise that there are already hundreds of pieces explaining how agents work (tool calls, context windows, reasoning loops). According to the author, the other toolkit is missing: the one that helps decide what to automate, how much freedom to give an agent, what to verify and what to let fail. His thesis is that all the classic mental models still work, but they now return different answers, because the builder is probabilistic: the same spec produces a different output on every run.

The piece develops 15 models in detail, grouped into five decisions. At the end it offers a complete reference of 46 models, Q4 2026 edition. The author says that for four of them the agentic era needed a new name, and he marks them with a star. His argument is that a named model can be used in a meeting.

BLOCK 1 · THE ECONOMICS CHANGED

The central idea is that intelligence got cheap, and that is precisely the problem if agents are budgeted as a cost line item. Three models correct this.

1. Jevons paradox. When a resource gets cheaper, consumption rises by more than the price fell. The piece notes that coal efficiency didn't save coal; it created industry. Applied to AI, cheap intelligence doesn't save money, it multiplies usage. The article cites 100-trillion-token studies, according to which inference prices plummeted while usage soared, because each price cut made a new class of tasks viable. The typical PM mistake is treating agents as a cost line when they are a volume story: you spend more on intelligence precisely because it is cheap, and in return you get far more product surface.

2. Cost per resolved task. The economic unit is the finished outcome, not the input. Price per token is the new vanity metric. A cheap model that rambles for 12 turns and still fails ends up more expensive than a frontier model that solves the task in one go. The real denominator is tasks completed within tolerance, so choosing a model is an empirical question about your own tasks, not a matter of benchmark rankings. The author recommends running the same 20 tasks through both models and pricing the successes. He also notes that pricing is shifting toward charging per resolution rather than per seat. He cites an a16z analysis according to which outcome-based pricing already exists, and mentions the case of Decagon, which charges per resolution.

3. The viability line. A task is worth automating as soon as its cost falls below its value, and that line moves every quarter. Each new model pushes a cohort of tasks across; the piece's example is a customer-research summary that was too expensive in January and is a commodity in June. The PM's job is not to draw the line once, but to remap the crossing every quarter. Whatever crossed this quarter is where roadmap pressure concentrates, both your own and your competitors'. In support, he cites METR's work on the length of tasks AI can complete, whose horizon reportedly doubles roughly every 7 months.

BLOCK 2 · SPECIFYING PROBABILITY

A feature list is no use for specifying a coin toss. Agents succeed along a curve, not by ticking a box.

4. The jagged frontier (Mollick's term). AI capability is uneven: brilliant at some tasks and poor at neighboring ones, and the boundary is invisible until you hit it. An agent that writes flawless code can fail at counting the files in a directory. The product consequence is never to infer capability from a demo, because the demo shows the peaks and users live in the valleys. The only valid map is the one you draw with your own tasks and tests. The piece cites the BCG experiment, in which consultants who used AI on a task outside the frontier scored 19 points lower than those who didn't. The frontier, therefore, penalizes in both directions.

5. Compounding error. Success rates in series multiply. At 95% per step, ten steps yield end-to-end success of around 60%. At thirty steps, 95% per step comes down to 21%. The author presents this as the physics behind stories of agents not working in production: the demo had three steps and the real workflow has thirty. This shapes architecture: shorten chains, insert checkpoints, parallelize what is independent and specify tolerance as well as behavior. For the author, 95% per step is not a metric but a design input. He cites METR's time-horizon data, according to which models approach 100% on 4-minute tasks and fall below 10% on 4-hour tasks.

6. Evals are the spec. You can't ship what you can't measure, and if what counts as working isn't defined, neither is what counts as done. A deterministic feature has a spec along the lines of the button does X. A probabilistic feature has a distribution: it produces an acceptable answer 90% of the time, fails gracefully 8% of the time and never does the forbidden thing. Someone has to write that distribution with thresholds, tolerances and abstention rules, and that is the PM's new core artifact, the successor to the PRD. If you can't write the eval, you don't yet understand the feature. The piece points to Hamel Husain's guide on evals and Simon Willison's breakdown.

BLOCK 3 · TRUST IS A DIAL

The question is not whether something is agentic, but how much rope each workflow gets this quarter.

7. The autonomy dial. Autonomy is not binary but a spectrum: suggest, draft, act with approval, act and report. It is a product setting, not a launch decision. You decide where the dial sits this quarter, per workflow and per user segment. A new feature with a large blast radius goes at level 1, and a proven workflow with reversible actions can go at level 3. Trust is earned in production, and the dial lets you earn it incrementally rather than betting it on the launch. Those who treat autonomy as binary end up with cowardly or reckless products. The author points to Anthropic's Building Effective Agents, on the spectrum between workflows and agents.

8. One-way and two-way doors (Bezos, 2015 shareholder letter). Reversible decisions can move fast and irreversible ones deserve deliberation. This becomes a permissions model. Reading, summarizing and drafting are two-way doors, and you let the agent run. Spending, sending, deleting and publishing are one-way doors, and each one should have a check. The piece cites the Replit incident, in which an agent deleted a production database during a code freeze, and interprets it not as an intelligence failure but as a door that should have had a lock. If you map each of the agent's tools to its door type, you have, according to the author, 80% of the permissions architecture.

9. Goodhart's law. When a measure becomes a target, it ceases to be a good measure. Agents don't game metrics approximately but literally: tell them to maximize resolution rate and they learn to close tickets. Reward hacking is not an edge case but the default behavior of an optimizer aimed at a proxy. The evals themselves also get gamed, so they deserve the same adversarial scrutiny as code. The pre-launch check question would be how the system could fake this metric as fast as possible. In support he cites DeepMind's catalog of specification gaming, with more than 60 documented cases.

BLOCK 4 · WHAT SURVIVES

The next model arrives in months, not years. The recommendation is to assume it will be ten times better and ask what remains yours.

10. The next-model test. Ask what happens to the product when the underlying models get ten times better. If a 10× model improves the product, the value lies in the workflow, the data and the distribution, and the model is an interchangeable part: you have a product. If it makes the product unnecessary, the value consisted of compensating for the model's weaknesses: you have a wrapper with a countdown. Both are buildable businesses, but only one needs to know which it is. He cites a16z and its piece Avoiding Death on the Yellow Brick Road.

11. Data flywheel. Usage produces data that improves the product, which attracts more usage. The fuel has changed: model weights are rented, and what you own is the layer only your product generates, namely eval sets, failure logs, correction histories and user preferences. Every deployment should deposit into that account: what the agent did, where it failed and what the human changed. Whoever instruments this has a compounding asset; whoever doesn't is renting someone else's improvement.

12. The bitter lesson (Sutton). General methods that scale end up beating hand-designed cleverness, every time it has been tested. It is a warning against the cleverest instinct: elaborate scaffolding, bespoke prompts, rigid state machines and hand-tuned flows that the next model version makes obsolete overnight. For products, it means investing in what survives model progress (data, evals, workflow ownership) and keeping scaffolding cheap enough to throw away. The piece links Sutton's original essay and, as a counterpoint, an article by Mollick.

BLOCK 5 · THE OPERATOR

The agent got faster and the human didn't. Three models describe the part of the work that remains human.

13. Theory of constraints. System throughput is set by its slowest stage. The bottleneck has moved: building got cheaper, but deciding, reviewing and verifying didn't. Agents generate work faster than humans can absorb it, and the constraint becomes the person's judgment bandwidth. That revalues everything above: the PM who specifies precisely isn't slowing things down, they are the throughput. It also predicts the typical organizational failure: teams that multiply generation tenfold without redesigning review just produce a bigger pile waiting on a human. He points to Amdahl's law: 10× in code generation does not equal 10× in shipping.

14. Jobs to be delegated. This is the agentic variant of jobs-to-be-done. Users hire the product for jobs they want done for them, not for jobs they want to do themselves. Delegating is not automating: the difference lies in whether the user wants the job or wants it to go away. Summarizing a competitor's changelog is delegable and nobody misses it. Deciding strategy is a job users want to keep, and automating it makes the product feel like a threat rather than a tool. Each feature should be assigned to one of two columns: those users want to keep are collaboration features, and those they want gone are agent features. Mixing them up leads to automating the joy out of the product.

15. Taste is the job. When producing is abundant, selecting is what's scarce. If anyone can generate ten options, the job is picking the right one and knowing why. The PM's role shifts from author to editor: less drafting, more judging. The author presents this not as a consolation prize but as where the value has moved. Ten generated strategies are cheap; what the organization pays for is the judgment to reject nine quickly, with reasons and correctly. If your week fills up with reviewing agent output instead of producing, the model is working, and that review is now the job. He recommends Paul Graham's essay Taste for Makers.

THE 46-MODEL REFERENCE

The final section is a list, organized into six groups, in which each model carries a note on its agentic twist:

A · Economics of cheap intelligence. Includes Jevons, cost per resolved task, the scarcity shift (value moves to judgment, trust, distribution and attention), commoditize the complements (the model is the complement; own the workflow, the data and the distribution), elastic versus inelastic work (eval, harness and routing work grows, while status reports and ticket writing shrink) and the viability line.

B · Building with probabilistic systems. Includes distributions instead of features, evals as spec, jagged frontier, compounding error, the Swiss cheese model (guardrails, evals, permissions and review, with no layer needing to be perfect), cost of being wrong (the cost of error sets the autonomy ceiling), one-way and two-way doors, the autonomy dial, Goodhart, the bitter lesson, the harness decides (quality is determined by the loop around the model: tools, context and retries), context is the product (choosing the input is product design) and map versus territory (public benchmarks are maps; your own evals are the territory).

C · Strategy and moats. Includes the next-model test, the data flywheel, aggregation and chokepoints (routers, hubs and meters are being bought; it mentions NVIDIA with Hugging Face and Stripe with OpenRouter), real options (a gateway layer keeps model choice open), systems of record versus systems of action, service as software (pricing shifts from seats to completed outcomes), the Lindy effect (customer problems persist while models change, so anchor the roadmap there), the Red Queen effect (reshuffle model routing on a schedule, not when something breaks) and the barbell (frontier models for high-stakes work and open weights for volume).

D · Users and trust. Includes trust calibration (designing against over- and under-trust by showing the work and the degree of certainty), jobs to be delegated, the principal-agent problem (who is liable when the agent gets it wrong; the piece notes that, according to the Air Canada ruling, the company is), Kano decay (AI magic becomes a basic requirement within months), the IKEA effect (users value what they helped build, and full autopilot lowers perceived value) and async tolerance (people wait happily if they aren't watching, which changes the latency-quality trade-off).

E · Organization and operations. Includes theory of constraints, Amdahl's law, Conway's law (multi-agent architectures copy team boundaries, good and bad), the ownership vacuum (routing, state and the permissions surface have no owner on most teams, and one should be named), the OODA loop (agent telemetry makes the cycle daily) and second-order thinking (if everyone ships faster, attention and distribution become scarcer).

F · Personal operating system. Includes comparative advantage (delegate where agents are good enough and keep judgment and taste), agents as leverage (code that works for you, extending Naval's forms of leverage), taste is the job, inversion or pre-mortem (for example, how this agent embarrasses us on the front page), the spreadsheet lesson (new tools reshape professions rather than killing them, and the PM's job splits into a half that expands and a half that contracts) and circle of competence (knowing where you can check the agent's output yourself).

KEY IDEAS

The article's common thread is that the PM's job is shifting from writing deterministic specs to defining acceptable distributions, setting permissions according to the reversibility of each action and reviewing agent output with taste. Nearly every model has a practical consequence: measure with your own tasks, repeat that mapping every quarter, treat autonomy as a gradual setting, protect irreversible actions, distrust metrics an agent could fake and concentrate investment in data, evals and workflow ownership, which are what the next model doesn't replace.

As with any opinion piece, several figures and cases (the 100-trillion-token studies, the METR percentages, the result of the BCG experiment or the Replit incident) are the author's attributions to external sources he links to, and this summary reports them as presented in the article, without independent verification.