Google’s core search product was built around the human session: one query, a ranked page, a click.
Exa began with a different assumption: the searcher would often be an agent.
An agent does not want a results page. It wants information it can carry into its next decision: a current source, the relevant passage, structured output, and enough provenance to verify what it found. While pursuing one objective, it may search dozens of times, following several paths and changing its theory along the way.
A person asks once. The agent turns that intention into a stream of demand.
Exa built its own crawler, index, embedding and reranking models, vector database, and API around that behavior. Its index spans more than 500 billion pages, and its Highlights system can return the few passages an agent needs instead of making another model consume every page.
Exa is not a search wrapper with an agent endpoint. It is a search engine whose architecture follows from a different customer.
Search is where the change is easiest to see. It will not stop there.
Agents will become the largest customers of the internet.
People will still supply the goals, money, authority, and constraints. But the agent will increasingly choose the search engine, database, payment service, hosting provider, API, and sequence of actions used to achieve the outcome.
The person creates the demand. The agent routes it.
This makes the agent the operational customer: the entity whose requirements determine what gets selected and how often it gets used.
Agents are like water. They keep moving toward the goal.
If your documentation is unclear, they find an example somewhere else. If your API is missing, they operate the website. If the website is difficult to use, they write a script. If authentication breaks the trajectory, they find another provider.
Agents do not abandon the objective because your product is awkward. They abandon your product.
What agents want is not the same as what people want. They need to discover what a system can do, understand how to operate it, establish authority, act without ambiguity, verify the result, and recover when something fails.
A product the agent cannot find never enters consideration. Dense marketing copy consumes context while burying the facts needed to make a decision. Unstable identifiers make actions difficult to verify. Vague errors leave no recovery path. A login flow designed around a human session can stop a long-running trajectory entirely.
The winning product does not need to be best in the abstract. It needs to be the clearest reliable path from the agent’s current state to its goal.
Machine preference is already visible. What Would Claude Use asks models which products they would choose for common build decisions. The same names recur. This is not market-share data. It is a map of the prior an agent brings to the job.
That prior becomes implementation. In 2,430 agentic app-building runs, rephrasing the same requirement produced the same stack about 76 percent of the time. Vercel received every JavaScript deployment recommendation in the study. The agents followed routes already legible to them.
Agent Arena measures the next step. An agent must find the documentation, install the package, write working code, and verify the result without human help. Providers are ranked by time, cost, errors, and interruptions. Recommendation gets a product considered. Ergonomics determines whether the agent finishes the job.
Once a path works, it becomes easier for the next agent to take. The integration enters a repository. The procedure becomes a skill. The instructions settle into a harness. Successful use creates more examples of the path working.
Human distribution creates awareness. Agent distribution creates operational fluency.
Products that agents can already use become easier to choose, and every successful use makes the path more legible to later agents. Agent ergonomics compounds.
It also creates load.
Human demand arrives in sessions. Agent demand arrives as trajectories. A single request can trigger searches, model calls, database queries, browser actions, tests, retries, monitoring, and subagents. The work may continue for hours, split into parallel branches, or resume when conditions change.
Products inside agent loops should plan for two or three orders of magnitude more activity per human intention. A person might search once; an agent may search fifty times. A person might inspect one database record; an agent may query the surrounding tables, test a change, retry after a conflict, and monitor the result.
The preferred path can be destroyed by its own preference. Rate limits designed around human browsing become bottlenecks. Pricing based on occasional calls stops working. Infrastructure built for sessions must support continuous work, persistent state, parallel branches, and safe retries.
The next great products must be desirable enough to be chosen, ergonomic enough to be operated, and demand-ready enough to survive their own use.
The person creates the demand. The agent decides where it goes.
Build what agents want. Then build for the demand they will create.