The Agentic Economy: Why New Platforms Will Beat Salesforce and Google

Salesforce sells seats. Google sells attention. Both models assume a human sits at a keyboard — clicking through a CRM, or scanning a results page long enough to register an ad. An AI agent does neither. It calls an API, completes a task, and moves on. The gap between how incumbents earn money and how agents actually work is the reason the agentic economy is unlikely to be won by the companies that won the SaaS and search eras.

This matters for what you build next. If you are deciding where to point an agent-infrastructure startup or an agent-native feature inside an existing product, the incumbents’ weak spots are a map of the open ground.

Why seat-based and ad-based models break

Salesforce revenue is roughly named users multiplied by price per seat. An agent that drafts follow-up emails, updates opportunity records, and routes leads is not a named user — it is one process doing the work that used to need several. If that agent runs well, the customer needs fewer seats, not more. Salesforce’s own answer, Agentforce, is priced per conversation and per action rather than per seat. That pricing change is the tell: the company is hedging against its own core model.

Google’s exposure is structurally similar. Search advertising depends on a human reading a results page and choosing what to click. An agent asked to find the cheapest flight under four hours does not browse — it queries, compares, and returns one answer. The ad slot never gets seen. Every task an agent completes end to end is a query that produced no impression. Google can build capable agents, but each one it ships erodes the surface its revenue depends on.

This is the innovator’s dilemma in textbook form. The incumbents are not technically behind — both ship strong models. They are financially constrained from leaning all the way into the shift, because the agentic pattern cannibalizes the revenue line that funds everything else. A startup with no seat revenue and no ad inventory to protect carries no such conflict.

The primitives agents actually need

The SaaS era optimized for human screens: dashboards, drag-and-drop builders, onboarding tours. None of that helps an agent. An agent needs machine-shaped primitives, and most of them are either missing or owned by no one yet. That is the opportunity surface.

Identity and authorization. An agent acting on your behalf needs its own credential, not your password. It needs scoped, revocable, auditable tokens, so you can grant read-only calendar access, send-email permission, and a $50 spend ceiling — and nothing beyond that. Human SSO products were not designed for a non-human principal that should be sandboxed by default.

Tool and protocol layers. Agents reach the world through tool calls. The Model Context Protocol has become a common way to expose tools, but the layer above it is thin: discovery, versioning, rate limiting, schema validation, and a registry of tools you can actually trust. Whoever makes that layer reliable becomes infrastructure.

Observability and evaluation. When an agent takes twelve steps and the eighth one is wrong, you need traces, replay, and regression evals. Traditional APM watches request latency; it does not tell you that an agent reasoned itself into a bad branch. Agent-native observability is its own product category.

Memory and state. Agents need durable memory that survives a session and stays consistent across runs. A vector store is part of it. The harder parts are write policy, conflict resolution, and deciding what to forget.

Metering and payments. If the unit of value is an action, something has to count actions, attribute cost, enforce budgets, and bill for them. Seat-based billing systems cannot express a fact like: this agent spent $3.40 across 90 tool calls this afternoon.

Each item on that list is a product, not a feature. None is a natural extension of a CRM or a search index, and each is a category a focused team can own before an incumbent decides it is worth the revenue risk.

What to build, and how to charge for it

Two decisions separate an agent-native product from a GUI product with a chatbot stapled on.

First, treat the agent as the primary user. Design the API, the error messages, and the permission model for a program, not a person. If your product is only usable through a human-facing UI, an agent has to screen-scrape it — and you have shipped a competitor’s integration headache instead of a product. Ship a typed API and a tool schema before you ship a dashboard.

Second, charge for consumption or outcomes, not seats. Pricing is not a billing detail here; it decides whether you grow or shrink as agents improve. If your revenue rises when agents do more work, you are aligned with the trend. If it falls, you have rebuilt Salesforce’s seat problem on a smaller balance sheet. Meter actions, tokens, or completed tasks from day one, even when the public price still looks like a flat tier.

The agentic economy will have its own incumbents — but most of them do not exist yet. The teams that will own agent identity, the tool layer, observability, and metering five years from now are, today, small groups shipping unglamorous infrastructure. That is where to aim.

Common questions