Building for Agents and Humans: The Two-Audience Web

A meaningful share of the traffic hitting our clients' sites is no longer a person with a mouse. It is an assistant summarizing a product page, an agent comparing prices across five retailers, or a shopping tool checking stock before it recommends anything. On one retail property we maintain, agent-shaped traffic passed fifteen percent of sessions in December, and the trendline is not subtle.

You can treat this as a nuisance and rate-limit it, or you can treat it as a second audience and build for it deliberately. We think the second option is the only defensible one, because those agents are increasingly the layer through which humans decide anything.

The principle: one source of truth, two renderings

The mistake we see most often is teams bolting on a parallel "AI version" of their content: a separate feed, a separate FAQ dump, a hidden endpoint that drifts out of sync with the real site within a quarter. Divergence is death here. When an agent quotes a price that the page contradicts, the user blames the brand, not the agent.

Our rule is that the canonical data renders both experiences. The human gets the designed page. The agent gets structured data generated from the same source at build time, never hand-maintained.

{
  "@type": "Product",
  "name": "Møller Aster Lounge Chair",
  "offers": {
    "@type": "Offer",
    "price": "1290.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Boring, ten-year-old schema.org markup, emitted from the same product record that hydrates the React component. The unglamorous stuff is what agents actually parse reliably. We validated this the tedious way, by watching what the major assistants get right and wrong across our clients' catalogs.

What agents punish

A few patterns that quietly wreck your machine legibility.

• Content that only exists after client-side interaction. If the spec sheet lives behind a tab that renders on click with no addressable URL, many agents never see it.
• Ambiguous state. "Only a few left!" is a human nudge and a machine mystery. Pair the marketing string with a structured availability value.
• PDF-only information. Warranty terms, dimensions, materials. If it matters to a purchase decision, it needs to exist as HTML.
• Inconsistent entity naming. The same product called three slightly different names across the site makes an agent hedge, and hedging agents recommend your competitor, who was unambiguous.

None of this requires exotic infrastructure. It requires the discipline to treat information architecture as a contract.

What humans still get

Here is the part I want to be loud about, because the discourse has gotten weird. Building for agents does not mean flattening the human experience into a database with a logo. The opposite. As agents commoditize the informational layer, the humans who do land on your site arrive with the facts already gathered. What is left to do is make them feel something.

That means the designed experience should get more distinctive, not less. More motion where it earns its keep, more editorial voice, more of the texture that no synthesis can carry. The agent handles the spec sheet. The site handles the desire.

Where this goes next

The speculative frontier is agent-to-agent commerce: your client's selling agent negotiating with a customer's buying agent, no page render involved. We are watching the early protocol work closely, and we are building clients' data foundations so that when transactional agent interfaces standardize, exposing one is a sprint, not a replatform.

But you do not need to bet on the speculation to act. The two-audience web is already here, it is measurable in your logs today, and the sites that serve both audiences well are pulling ahead in ways that compound. Build one source of truth. Render it twice. Sweat both renderings.