How agents are changing the way products get discovered
A developer asks their coding agent to add transactional email to a project. The agent does not open a browser, read a comparison post, and weigh three options. It picks something — from its training data, from a search it ran, or from a tool one of its connected servers exposed — and writes the integration.
That is a discovery event. Nobody visited a landing page. Nobody read a tagline. The decision that would once have involved a Google search, two blog posts and a pricing page happened inside a single turn, and the only thing that influenced it was what the agent could reach.
This is not a prediction. It is how a meaningful amount of tooling selection already works for anyone using a coding agent daily. The question worth asking is what it changes about being discoverable.
Three things change
The unit of discovery is a fact, not a page. A person browsing a directory absorbs a card: logo, name, tagline, a sense of design quality. An agent reads text. It cannot be impressed by your gradient. What it can do is extract "supports webhooks", "has a free tier", "Python SDK exists" and use those to decide. If those facts are only expressible as an image or a video, they are invisible.
Comparison is cheap. A person comparing five tools does it badly, because reading five pricing pages is tedious and they will stop at three. An agent asked to compare five tools will actually compare five. This is good for products that are genuinely better on the axis being compared, and bad for products that win on brand recall.
The intermediary is machine-readable or it is skipped. A directory that only exists as rendered HTML behind a JavaScript app is a directory an agent has to work to read. One that exposes a JSON API, or an MCP server, is a directory an agent can query in one call. Over time, the second kind gets asked and the first kind does not.
What this does not change
Agents do not have taste and mostly do not pretend to. They are good at satisfying stated constraints and bad at the judgement call about whether a tool is pleasant to live with six months in. A developer who asks for "a queue library" and accepts the first suggestion is not making a considered choice, and often knows it.
So the human evaluation layer does not disappear — it moves. It happens after the shortlist rather than during it. Which means being on the shortlist is now the hard part, and being the most attractive option on the shortlist is comparatively easier than it was.
It also means the old signals still work, they just work at a different stage. Testimonials, screenshots and a well-designed page still convert. They convert the person reviewing what the agent proposed.
What to actually do about it
Most of the advice here is unglamorous and overlaps with things you should have been doing anyway.
State facts in text. Your pricing should be readable without executing JavaScript. Your integrations should be listed, not shown as a logo wall with no alt text. Your limits — rate limits, file size caps, supported regions — should exist as sentences somewhere on your site. An agent asked "does this support X" will find the sentence or conclude it does not.
Have documentation an agent can read end to end. A docs site that requires clicking through forty pages is worse, for this purpose, than one long page. Several projects now publish an llms.txt or a single concatenated docs file for exactly this reason. It is a small amount of work and it removes a whole class of "the agent got it wrong" problem.
Be present where agents look. That means search, still — agents run searches. It also increasingly means directories and registries with structured output, because a single query there returns twenty candidates with comparable fields, which is a much better use of a turn than twenty page fetches.
Consider exposing an MCP server yourself. If your product has an API, wrapping the useful parts in an MCP server means an agent can use your product rather than merely read about it. That is a stronger position than being findable. It is also less work than it sounds — the protocol is deliberately small. We wrote up what an MCP server actually is for people shipping products rather than for protocol authors.
Directories have to change too
We built this one on the assumption that both kinds of visitor matter, which is why every read on our side is available three ways: as a page, as a REST endpoint, and as an MCP tool. Reads need no key and no account. An agent asked "what AI tools handle transcription" can call search_tools and get structured results back in one turn, rather than parsing a listing page.
Submission works the same way. A developer can point their agent at our MCP server and say "submit this project"; the agent audits the page, drafts the listing and opens it. What the agent cannot do is publish it, choose a launch date, or pay for anything — those stay with a person, deliberately. An agent that could publish on its own behalf would turn any directory into a spam target within a week.
That split is the interesting design question for anyone building an agent-facing surface. Not "can an agent do this" but "which parts should it be allowed to finish". Our answer: agents do the tedious, reversible work — reading pages, filling forms, checking for duplicates. People do the parts that are public and permanent.
The honest uncertainty
Nobody knows how much product discovery will end up running through agents versus search versus recommendation. Anyone who gives you a percentage is guessing. What seems safe is that the share is not going to zero, and that the work required to be legible to an agent is nearly the same work required to be legible to a search crawler or a careful human reader.
Which is the useful part of this whole shift: the preparation is not speculative. Writing your facts down in plain text, publishing an API, keeping your documentation crawlable — these were already good ideas. They now have a second audience.
If you want to see what the agent-facing version looks like in practice, the API and MCP page has the connection string and the full tool list, and our catalogue is the same data rendered for humans.