An agent is software that carries out a task rather than answering a question about it. It browses, reads pages, compares against constraints and comes back with a shortlist. When it evaluates your product it behaves nothing like a human visitor, and almost everything you have built for the human is invisible to it.
Most commentary on this is either breathless or dismissive. The useful position is narrower. Autonomous purchasing in B2B is not imminent, because procurement and contracting are human processes with legal requirements attached. Autonomous research is already happening, and the research stage is where shortlists get made.
What is actually shipping
Three layers exist today and they are worth telling apart, because they have different implications for you.
Browsing agents. Assistants that visit pages, read them and act. Operator-style browsing agents are the visible version. They are slow, they fail on interactive interfaces, and they read the rendered page much as a careful, impatient reader would.
Tool protocols. Rather than scraping a page, an agent calls a structured interface. The Model Context Protocol has become the common way to expose tools and data to an assistant, and the shape of it matters to you because it turns your product from a website into something an agent can operate.
Agent-to-agent communication. Work on letting agents built by different vendors talk to each other, such as the A2A interoperability effort. Early, but the direction is a buyer’s agent negotiating with a vendor’s agent, and that is a different commercial world from the one you currently sell into.
None of that requires you to do anything exotic yet. What it requires is that the facts about your product are legible to software, which is the same thing retrieval already needed and most companies still have not done.
The whole readiness question in one line. Can a program that will not click anything, wait for anything or log into anything find out what you cost, what you integrate with, and what you do not do? If not, you are not agent-ready, and you were not retrieval-ready either.
How an agent differs from a human visitor
| Human visitor | Agent | |
|---|---|---|
| Patience for interactions | Will click and scroll | Usually will not, and may not be able to |
| Client-side rendering | Waits for it | Often captures the page before or without it |
| PDFs and gated assets | Will download if motivated | Treats as absent |
| Marketing framing | Partly persuaded by it | Skips it looking for values |
| Ambiguity | Infers from context | Records the ambiguity or drops the option |
| Comparison | Two or three vendors | Twenty, mechanically, against stated constraints |
That final point deserves emphasis because it inverts a familiar instinct. In a human evaluation, ambiguity is sometimes useful. You can leave pricing vague to force a conversation, describe capabilities generously and resolve details in a call. An agent does not call. It records what it can verify and discards what it cannot, and a discarded option is not a lost deal you get to hear about.
The practical test is simply whether the facts are in your HTML. Fetch your own pricing page with JavaScript disabled and see what survives. If you would rather have that checked across every page an agent would look at, alongside how engines currently describe you, our free AI visibility check covers both and costs nothing.
The four things worth doing now
All four are useful whether or not agentic buying ever arrives, which is the test any preparation should pass.
- Put your facts in the initial HTML. Price, unit, billing period, minimum commitment, what is included, what is not. As text, server rendered, not in an image or a chart. The argument in full is in why your pricing page is the page AI reads most.
- Document integrations properly, one page each. A logo grid tells an agent nothing. A page saying what syncs, in which direction, how often, and what breaks is a page an agent can use to include or exclude you correctly.
- Publish your limits. Rate limits, data residency, seat minimums, supported regions, what you do not do. Constraints are how agents filter, and an unstated constraint is read as a missing capability.
- Keep an honest public API description. If you have an API, publish a current OpenAPI description at a stable URL. It is the most machine-legible thing you can publish about what your product actually does.
Notice that none of these is speculative infrastructure. They are all things that improve ordinary retrieval today and happen to be exactly what an agent needs. That is the right shape for preparation in a field moving this fast.
What not to build yet
Resist building agent-specific endpoints, bot-only content or a separate machine-readable version of your site. Serving different content to software than to people is a well-established way to be penalised, and the standards here are moving quickly enough that anything custom you build now will likely be wrong within a year.
Also resist the temptation to treat this as a reason to gate less or gate more. The gating question is a commercial one and it has not changed. What has changed is that anything behind a gate is now invisible to a much larger share of your evaluation traffic, so gate deliberately rather than by habit.
A second-order effect matters here too. If agents compare twenty vendors against stated constraints, the value of being the best-known name in a category falls and the value of being the most precisely described one rises. Fame helps a human shortlist. It does very little for a filter that is checking whether you support a particular data residency requirement.
That is the first mechanism we have seen in this field that structurally favours smaller vendors, and it is a reason to get the unglamorous documentation right now rather than when it becomes urgent.
A sensible way to think about the timing
Agentic research is here and improving. Agentic shortlisting is emerging. Agentic purchasing in B2B is far off and may never fully arrive for considered purchases, because the approval chain is a human institution rather than a technical obstacle.
So prepare for the first two and ignore the third. The first two are served entirely by making your facts plain, current and server-rendered, which is work you should be doing regardless. If agentic buying stalls completely, you will have spent the time on better retrieval and a clearer site. That is an acceptable worst case, and it is the only preparation strategy here with one.
Related reading
- Where AI search is going for B2B SaaS. The wider trajectory this sits inside.
- How retrieval picks sources. The mechanism underneath both agents and assistants.
- Training data versus live retrieval. Why an agent reading your site today can know things a model does not.
- What AEO is. The foundation, if this is your first piece of ours.
Shaban runs answer engine optimisation for B2B SaaS companies at Uncited Brands. He works the unglamorous end of the problem, mostly crawler access, retrieval diagnostics and measurement baselines, and publishes the tests that do not go his way alongside the ones that do.