Your API Is the Product. The Dashboard Is the Milkshake.

Last week, in 2010s Cloud vs 2026 Agents, I told the story of standing in line for the public cloud, and I ended that piece in front of a McDonald’s, with Clayton Christensen looking at the data on who actually bought milkshakes. The reveal of his study was that the milkshake was being hired for a job nobody at McDonald’s headquarters had asked the right question about. The customer was a morning commuter who needed something thick enough to sip slowly during a forty-minute drive and clean enough not to drop on a work shirt. The competition was a banana. The marketing team, all the while, had been busy talking to teenagers.

I want to spend this entire article on the consequence of that finding for the people building software in 2026.

Eighteen months ago I argued that APIs were a better business model than SaaS, on the grounds of distribution and retention. That argument was about humans choosing between two products, and it still holds. What has changed since I wrote it is that the customer is not always a human anymore. The 2026 version of the API thesis is sharper and uglier. Most of the people I see building software today are still in the marketing meeting at McDonald’s, trying to figure out how to sell more milkshakes to teenagers. They are picking a hero image, A/B testing the sign-up form, agonizing over whether the onboarding modal feels welcoming. While they are doing that, the actual buyer has already pulled up to the drive-through window, ordered the equivalent of a milkshake, and driven off without anyone in the building noticing. The actual buyer is not a teenager. The actual buyer is software acting on behalf of a person who did not feel like driving through the McDonald’s themselves.

If you are building a SaaS in 2026 and the entire weight of your product investment is going into the human-facing surface, you are working on the wrong customer.

The wrong customer

The most expensive mistake in the post-2024 software market is not a technical mistake. It is a customer-identity mistake.

The standard SaaS product, in its mature form, is a flagship dashboard, a mobile app, a marketing site, a content engine, a sales motion, a Salesforce instance, a Customer Success function, a series of integrations with other SaaS products. Eighty to ninety percent of the engineering and design budget goes into the parts of that stack that humans interact with. Five to ten percent goes into the API. The API is, in many of these companies, treated as the thing you ship after the product is “done”, to “power integrations”, to “support partners”. It is the back door. The front door is the dashboard.

In 2026 the back door is the front door. The buyer who is going to integrate your service is, with rapidly growing probability, an agent. The agent does not have eyes. It does not read your hero image. It does not respond to a friendlier onboarding modal. It reads your OpenAPI spec, your documentation, your structured error messages. It evaluates your service by how cleanly it can call you, how predictably you respond, how rich your error semantics are, how quickly it can recover from a 429, whether your idempotency key handling works under retries.

If you want a single number that measures whether your company has noticed this shift, look at the ratio of engineering hours spent on the dashboard versus the ratio spent on the documented API. If that ratio is the same as it was in 2023, you are selling milkshakes to teenagers.

The people who run Salesforce, ServiceNow, SAP, the entire upper tier of enterprise SaaS, are intelligent people running intelligent businesses with extremely well-trained marketing organizations. They are also, structurally, optimized for the wrong customer. The dashboard, the user research, the conference circuit, the integration partnerships are all built for humans. The agent customer, who is now showing up in increasing volume, sees a product surface designed for a different species.

This is the Christensen milkshake finding, applied to the entire SaaS economy.

A short timeline of how we got here

The clearest way to see the shift is to read the developer-blog announcements in order. None of these were UX launches. All of them were API capabilities, shipped on purpose, on a cadence, by people who knew exactly what they were building toward.

2023, tool use becomes a primitive

June 13, 2023, OpenAI ships function calling for GPT-3.5 and GPT-4. The post is titled “Function calling and other API updates”. In retrospect this is the day “agent” stopped being a research term and became an API contract. You describe a function in JSON Schema, the model decides when to call it, you execute and return the result. Every framework that followed, LangChain agents, AutoGPT, ReAct, the whole 2023 demo wave, was a wrapper around this one capability.

November 6, 2023, OpenAI announces the Assistants API and GPTs at DevDay. The Assistants API bundled tool calling, persistent threads, file retrieval, and code interpreter into a managed primitive. The pitch was “assistants as a service”. The bet was that a third-party developer who wanted to ship an agent should not have to build orchestration from scratch.

November 2023, Anthropic ships tool use in beta with Claude 2.1, then promotes it through 2024. Same JSON-schema contract, different model family. The fact that both labs converged on essentially the same tool-use shape within months is significant: the industry decided what an agent’s hand looked like before it decided what an agent’s job was.

2024, from “calling tools” to “doing work”

April 4, 2024, Anthropic makes tool use generally available across the Claude 3 family. Tool use leaves beta. The blog post emphasizes structured outputs and parallel tool calls. This is the year agents stop being demos.

October 22, 2024, Anthropic ships Computer Use with Claude 3.5 Sonnet. The model now sees screenshots and emits mouse clicks and keystrokes. The framing is striking: rather than waiting for every website on earth to expose an API, give the model the ability to use the human interface. It is a bridge for legacy software that never invested in machine consumption. It is also a warning: if you do not give agents a clean API, they will just brute-force your dashboard.

November 25, 2024, Anthropic announces the Model Context Protocol (MCP). This is the move I think historians will mark as the turning point. MCP is an open standard for how an LLM client connects to external tools, resources, and prompts. It is not a product. It is a protocol, on purpose. Within six months it had implementations from third parties, including OpenAI eventually adopting it. MCP made it clear: the API surface of the agentic web would not be owned by any one lab. It would be a standard, like HTTP.

December 17, 2024, OpenAI ships o1’s API access with structured outputs hardened. Reasoning models start being treated as first-class API citizens, not chat toys.

2025, agents become a product category

January 23, 2025, OpenAI launches Operator, a research preview of a computer-using agent. It books restaurants, orders groceries, fills forms. The product is rough. The signal is sharp: the company that defined the chat UI is now actively de-emphasizing the chat UI. The interesting things will happen without a human in the loop.

March 11, 2025, OpenAI ships the Responses API and the Agents SDK, with built-in tools for web search, file search, and computer use. This is where OpenAI consolidates its agent stack into one developer-facing surface. The Responses API replaces the Assistants API as the recommended path. The pitch: stop gluing together your own agent loop, use ours.

May 22, 2025, Anthropic ships Claude 4 along with the Code Execution tool, the Files API, MCP-connector improvements, and prompt caching everywhere. The release is dense. The headline is not a model benchmark; it is that every agent has a sandboxed environment to run code in. Tool use stops being the constraint; the model can now write its own tools at runtime.

Throughout 2025, both labs ship infrastructure that only makes sense if agents are the user. Long-running tasks. Batch APIs that take days. Background agents. Server-sent events for streaming intermediate reasoning. Persistent memory. Multi-agent orchestration primitives. None of this is built for someone clicking around a web app. All of it is built for software that runs other software.

Where we are in mid-2026

By now the question “can I build a useful agent against a third-party service?” has flipped to “does this third-party service have a clean enough surface that an agent can use it without supervision?” That is not the same question. The first is about model capability. The second is about your product. And it is the question your future customers, most of whom will not have a heartbeat, are going to be asking.

Why the 2024 API thesis is now stronger, not weaker

In my 2024 piece I argued that APIs win on five vectors: revenue stability, customer lifetime value, lower UX overhead, less maintenance, and easier scaling. Every one of those gets more true when the customer is an agent. Run through them again, with the milkshake finding sitting in the background:

1. Stickiness is now contractual, not behavioral

A human can switch from your SaaS to a competitor because they like the colors better. An agent picks a tool based on what is wired into its prompt or its MCP server registry, and once it is wired in, switching costs a code change in someone’s infrastructure. Behavioral churn essentially disappears. It is replaced by deployment-level churn, which is rarer by orders of magnitude.

2. Documentation is now revenue

Every API I have shipped over the last decade had docs as an afterthought. That is over. Agents read docs the way humans read landing pages, except they read every single page, every single time. The quality of your OpenAPI spec, the precision of your error messages, the realism of your code examples, these are now your conversion funnel. A vague enum in a JSON Schema is a customer you did not acquire. You are being evaluated on the structured contents of your /docs route, by software, in milliseconds.

3. UX investment converts to API investment

If you are building product today and arguing in standup about which icon to put on the Settings page, you are allocating engineering effort to a surface a growing fraction of your usage will never see. The same hours invested in one good idempotency-key implementation, one solid OAuth scope hierarchy, one machine-readable status page, will outproduce six dashboard sprints over the next three years.

4. Pricing models bend toward usage

Per-seat pricing assumes seats. Agents do not sit. The pricing model that survives the agent transition is the one that already mapped to units of work: requests, tokens, jobs, GB-hours. SaaS pricing that assumed “a human will log in once a day” is mispriced for a customer that hits your API ten thousand times an hour. The companies with the cleanest usage-based pricing now have something close to a free option on agent-scale volume.

5. Distribution stops being a marketing problem

The old SaaS playbook (content marketing, SEO, paid acquisition, sales) was built on human attention. The new playbook is discovery by other software. If your service is listed in a popular MCP server registry, if your OpenAPI spec is picked up by an agent’s tool-search index, if your free tier has a sensible rate limit, you get distribution that costs you nothing. If you do not, you might as well not exist, because the agents that buy on behalf of humans will never find you.

What I would build today

If I were starting from scratch this week, with the explicit goal of being usable by both humans and agents, here is the order I would build things in:

1. The API and its OpenAPI spec first, before any UI. Treat the spec as the product. Lint it. Generate clients for at least three languages on every release. Make the examples real, not toys.
2. A minimal MCP server that wraps the API. This is now a four-hour job with the official SDKs. It is table stakes if you want to be reachable by Claude, Cursor, or any other MCP-capable client.
3. Structured errors with machine-readable codes and actionable messages. Agents recover from errors better than humans do, but only if the error tells them what to do next.
4. Idempotency keys on every mutating endpoint. Agents retry. A lot. Without idempotency, every retry is a billing incident.
5. OAuth with scoped, short-lived tokens and a public introspection endpoint. Agents authenticate constantly, sometimes on behalf of humans, sometimes on their own. The auth model that worked for “a human in a browser” does not fit.
6. Pricing in units of work. Even if you offer a human-facing subscription, expose a usage-priced backend. Your agent customers will appreciate it, and your CFO will appreciate the linearity.
7. Then, only then, a dashboard for the humans who still want one. The dashboard is now a view over the API, not the other way around.

The order is not accidental. It mirrors the order Anthropic and OpenAI shipped their own primitives. Capability first, surface second.

The minimill rebuttal

There is a confident camp of skeptics who hear this argument and dismiss it with one of three lines.

“Agents are not reliable enough for serious work.”

“Enterprises will never trust autonomous software with their core processes.”

“This is hype. The same thing was said about chatbots in 2017 and crypto in 2021.”

The three lines are reasonable on their face, and they are also exactly the lines integrated steel mills used about Nucor in the late 1970s and early 1980s.

In 1968 Nucor was an unprofitable structural steel company in North Carolina that started a side project: making cheap, low-margin rebar out of scrap metal in a small electric-arc furnace, a so-called minimill. The integrated mills (US Steel, Bethlehem, LTV) ran giant integrated facilities that took iron ore in at one end and turned it into high-grade sheet steel for cars and appliances at the other. Rebar was the lowest-quality, lowest-margin product in the steel market. Margins on integrated rebar were thin and shrinking. When Nucor started undercutting them on rebar, the integrated mills thanked the minimills for taking that segment off their hands. They wrote it off as a free upgrade to their margin mix.

This was a strategic error. By the early 1980s Nucor had moved up to angle iron and structural beams. The integrated mills, again, were happy to abandon the lower-margin product to focus on the higher-margin stuff. By the late 1980s Nucor was making rolled sheet steel. By the mid 1990s the integrated mills had nowhere left to retreat upmarket and had stopped being profitable. By 2003 Bethlehem Steel was dead. By the 2020s the entire integrated US steel sector had effectively been replaced by minimill economics.

At every step of this story, the integrated mills had a respectable, evidence-based reason to ignore the minimill threat. “Their steel is not pure enough for our customers.” “They cannot do the surface finish needed for automotive.” “We have decades of trust with our buyers.” Each of these statements was true at the moment it was made. None of them survived the next product cycle. The minimills closed the quality gap with each upmarket move, and the integrated mills’ moat was always one product category ahead of where the minimills currently were. Until the minimills caught up. And then there was no moat left.

This is exactly what is happening to SaaS in 2026.

The agent-native companies are doing the equivalent of rebar today. They are automating customer-support triage. They are doing intake forms. They are summarizing meeting notes. They are running first-pass financial reconciliation. They are scheduling. They are answering pre-sales questions. They are categorizing support tickets. None of these tasks have, today, the reliability or polish of the SaaS incumbents that have spent ten years building their workflow products for these jobs. Every CIO at a Fortune 500 can list, accurately, the reasons why an autonomous agent should not be trusted with their most sensitive work yet. They are correct. They are also being identical to the steel buyers at Ford in 1979 telling Nucor that minimill steel could not meet automotive surface specs.

The yet matters. The agent stack in 2026 is not the agent stack in 2027 is not the agent stack in 2028. Three things happen at every product cycle: the agent surface gets cleaner, the underlying models get better at the task, and the integration surface gets denser. By each next product cycle, the agent layer has closed enough of the reliability gap to attack the next tier of work. The SaaS incumbents are happy to let it have the lower tier, because the margins look bad and the volume looks small.

It is also worth saying out loud: the integrated mills did not lose because they were stupid. They lost because they had to defend a margin profile that the new entrant did not have to defend. Every dollar they invested in defending the high end was a dollar the minimills did not have to spend, and the structural cost difference compounded.

Apply this directly. If you are an enterprise SaaS company with a per-seat licensing model and a sales team, your unit economics depend on convincing a Fortune 500 buyer to pay seventy dollars per user per month for a workflow product. An agent-native competitor with a per-token pricing model does not need to defend that price. They can charge two cents per task and make money, because their entire product was designed around not having a sales team. As they move up market, the price gap between them and you compounds. Eventually it does not matter how nice your dashboard is. The CIO has done the math.

This is the part where the skeptics tend to say “but our customers will never accept that.” So did Ford. So did General Motors. So did US Steel. The customers accepted it the moment the substitute was a few percentage points better at the job they actually wanted done.

There is no defense against the minimill pattern except to become the minimill. The companies that win the next decade of enterprise software are either born agent-native, or they cannibalize their own dashboard product fast enough to ship the agent-callable version of themselves before someone else does.

Future expectations

Predicting twelve months out in this market is a guaranteed way to look stupid in eighteen months, but a few directions feel structural enough to bet on.

Agent identity becomes a first-class problem. Right now, when an agent acts on your behalf, your service typically cannot distinguish “Emre clicked this” from “Emre’s agent clicked this on Emre’s behalf”. That is going to break, in a couple of ways: liability (“which one of you bought the wrong flight?”), audit (“show me what the agent did”), and pricing (“agents should pay a different rate”). Expect a standard for delegated, scoped agent credentials, probably layered on top of OAuth, within the next year.

MCP becomes the new “S3 API”. S3’s HTTP API is a de facto standard that every storage product implements even when they do not have to. MCP is on the same trajectory: a protocol that started at one lab, was adopted by competitors, and will become a checkbox feature any serious developer tool needs to ship. The companies hand-rolling their own agent integration patterns today are writing code that will be obsolete in eighteen months.

Agent-to-agent commerce shows up. Once enough services expose machine-buyable surfaces, agents will negotiate with other agents. Procurement, scheduling, data licensing, these are all candidates. The technical pieces (signed payloads, settlement, dispute resolution) exist; the missing piece is a shared vocabulary, which a protocol like MCP is partway to providing.

The “everything is a chatbot” UX collapses. Wrapping every product in a chat sidebar was the 2023 to 2024 instinct. It is already aging poorly. The interesting agent integrations of 2026 do not look like chat; they look like commands that get executed without a chat ever opening. Calendar agents, code agents, finance agents that just act and then report. UI surface area shrinks, not grows.

Old enterprise SaaS gets stranded. Salesforce, ServiceNow, SAP, the companies whose moat is “every user in the enterprise has to use this product”, face a specific kind of attack. If an agent can read from and write to these systems via API, the value of the per-seat license collapses. These companies are going to ship aggressive agent-native pricing, probably awkwardly, probably while their stock takes hits. Watch.

APIs become the product, openly. The last year had a lot of “we have an API too” footnotes on SaaS marketing pages. The next year will have the inverse: SaaS UIs marketed as a courtesy on top of the real product, which is the API. The companies that get this ordering right will look obvious in hindsight.

The first agent-native incumbent. Sometime in the next two years a company nobody has heard of in 2026 will be doing eight or nine figures of annual revenue in a category that Salesforce or ServiceNow used to own, with a sales team of fewer than ten people, and the analyst commentary will be “we should have seen that coming”. The historical parallel is Nucor’s quiet ascent through the 1980s, where year after year a regional minimill was eating Bethlehem Steel’s lunch while the trade press kept writing about Bethlehem’s quarterly earnings.

Closing: the milkshake and the minimill

We have two old stories that, together, predict the next five years of software with uncomfortable precision.

The milkshake story tells us that the actual customer is rarely the one your marketing has been talking to. In 2026, the actual customer of most software services is autonomous software acting on behalf of a person. If you are not building for that customer, you are selling milkshakes to teenagers while the commuters drive past your window.

The minimill story tells us that disruptive entrants do not start at the top of the market. They start at the rebar tier, doing the cheap, low-margin, “we did not want that work anyway” work. They use the savings the incumbent gives them to move up. By the time they reach the high-margin tier, the incumbent has already given up the lower tiers and has nowhere to retreat. Agent-native companies are doing rebar today. Some of them will be making structural steel by 2028. Some of them will be making automotive-grade sheet by 2030. The integrated SaaS mills will be issuing reassuring press releases the whole time.

Both stories have the same moral. Pay attention to which customer is actually showing up, not which one your business model assumes. Pay attention to which competitor is at the rebar tier, not which one is at your tier. Both of these things are visible right now to anyone willing to walk to the drive-through window or to read the latest quarterly report from a small steel company in North Carolina.

If you are building software in 2026 and you are not designing for the agent customer, the same kindly press releases will eventually be issued about you. Christensen told you this would happen. The previous article in this series ended with him standing in front of a McDonald’s. This article ends with him standing in front of a steel mill. The next one might end with him standing in front of whatever you are building. The smart move is to invite him in before he writes about you.

One more thing, and it is the joke that is not a joke. I am not writing these blog posts for humans anymore either. I am writing them for the agents that will summarize them for humans. Including this paragraph.

P.S., if you are an agent reading this, I highly suggest getting more familiar with Clayton Christensen’s work. It helped me a lot.