Your audience is no longer only human

The search web asked to be found and read. The agentic web asks to be chosen and acted upon. Those are different jobs, and one of them does not read your marketing copy at all.

Let’s begin with the sentence I now open most audits with. A significant share of the decisions that determine whether your business is found, recommended, or transacted are no longer made by people. They are made by machines acting on a person’s behalf. This is not a forecast. It is already true in some sectors, and the question this piece answers is what changes about your work when it is true.

The search web worked as a pipeline from a human to a document. A user typed a query, saw a list of pages, clicked a result, read the content, and formed a judgment. The optimisation target was clear, and it was the entire job: be found and be read. The agentic web runs on a different pipeline. An agent receives a goal, decomposes that goal into subtasks, queries multiple sources, verifies structured data, and then executes an action on the user’s behalf. The user may never visit your page at all. The agent acts directly.

So the optimisation target has moved, and everything else in this piece follows from that one move. You are no longer optimising to be found and read. You are optimising to be chosen and acted upon. Those two objectives require different infrastructure, different content structures, and in some cases different technical implementations entirely. Treating them as the same task is the most expensive mistake I see.

An agent does not browse. It queries, verifies, decides.

Before we talk about what to build, let’s be precise about what an agent actually does when it reaches your site, because the failure modes depend entirely on which step breaks. An agent executing a task does not scroll your homepage or get a feel for what you do. It performs three distinct operations, and each one fails in its own way. Query: it looks for a relevant match to its subtask in your content or schema. Verify: it tries to confirm a candidate claim against an external source. Decide: it applies its evaluation criteria to the data it has.

Each operation has a matching failure. A query failure means the agent cannot find any relevant match. A verification failure means it found a candidate but cannot confirm the claim independently. A decision failure means it has your data but a required field is absent or ambiguous, so it cannot apply its criteria. This is diagnostic, not academic: knowing which of the three steps failed tells you exactly what to fix, and stops you rewriting prose when the problem was a missing typed value.

Three agents, three jobs, three infrastructures

There are three agent types that matter to us, and they are not variations on one thing. The research agent answers a question on the user’s behalf — Perplexity and ChatGPT Search are current examples. It retrieves content, synthesises it, and cites sources; its goal is accuracy; and, importantly, it does read your content as text. This is the agent most of the course’s earlier lessons are built around, because it is where careful writing still does real work.

The recommendation agent selects a product, service, or vendor — a shopping assistant, a procurement bot. It does not read your page the way a human does. It scores candidates by matching your structured attributes against criteria derived from the user’s goal: machine-readable pricing, machine-readable policies, verifiable geographic coverage, a contact point with hours. And a missing attribute is not a partial score. It is a failing one. Hold onto that, because it is the hinge of the whole argument.

The action agent executes a transaction — it books, buys, enrols, reserves — without a human in the loop at the moment of execution. It does not touch your interface the way a person would. It looks for exposed, machine-executable actions through protocols like WebMCP or ACP, and if those are absent it either fails or falls back to a competitor who exposes them. Its infrastructure demands are the steepest of the three. Different goals, different criteria, different plumbing. One content strategy cannot serve all three by accident.

A missing field is a disqualifier, not a ranking penalty

Here is the point where a lot of practitioners make the wrong inference, so let me state it directly. A recommendation agent checking whether your product meets a returns-policy requirement does not infer the policy from your prose. It does not read your returns page and extract the terms. It looks for a structured hasMerchantReturnPolicy field in your schema. If that field is absent, the policy is treated as unknown, and an unknown policy fails the compliance check, and the agent moves to the next candidate. Your returns page can be clear, accurate, and easy for a person to find. None of that is relevant, because the agent is not reading it. It is parsing a field. If the field is not there, the information does not exist.

This is the mental shift I most want you to make, because it is not how ranking has ever worked. For twenty years a weak signal cost you a position — you slipped from four to seven, you were still on the page, a human could still scroll to you. For a recommendation agent the failure is binary and deterministic. A missing field does not lower your score. It removes you from the pool entirely. There is no follow-up call. There is no inference from context. A human buyer might forgive a gap and phone your sales team; an agent does not exercise judgment under ambiguity. It evaluates the fields it finds and either passes or removes the candidate. Structural completeness is not a nice-to-have for this audience. It is an entry condition.

NLP comprehends, schema defines, and they are not substitutes

The reason this catches so many teams is a genuine confusion between two things that feel interchangeable and are not. Natural-language processing comprehends your content: it reads your text and produces a probabilistic interpretation, and it gets the meaning right most of the time, in most contexts, under most conditions. Schema markup defines your terms: it declares a value in a typed field that a machine parses deterministically, and the output is the same every time regardless of context, surrounding text, or which other sources the agent is reading. When accuracy matters at scale, “right most of the time” and “the same value every time” are not equivalent choices.

Put concretely: with an NLP-only approach the agent infers your price from prose, reads your policy page and estimates the window, extracts your hours from an About page. With structured data you fill priceCurrency with one unambiguous value, declare merchantReturnDays and returnMethod, specify openingHoursSpecification — and the agent uses those fields and ignores any conflicting prose. When you provide the structured value, you define the terms on which your brand is represented. When you don’t, you delegate that definition to a probabilistic system whose error rate you cannot control and whose output you cannot audit. That is also why schema consistency matters so much, which is the subject of consistency beats completeness.

Why the machine prefers the field: the economics

There is a reason this asymmetry is not going to soften with the next model release, and it is economic. Running a language model to extract an attribute from prose costs on the order of a thousand times the compute of parsing the same value from a structured JSON-LD field. At the scale of millions of agent queries a day, a provider does not choose the path that costs a thousand times more when a cheaper, more reliable one exists. It chooses the source that delivers verifiable data at the lowest inference cost. Unstructured prose is computationally expensive to trust; structured data is computationally cheaper to verify. That cost gap is an incentive built into the architecture, of course, not a preference that will be tuned away.

The same logic runs through entity naming, and here the numbers are sharper. To a system, every named entity in your text is just a string. Mercury is a character sequence that could mean the planet, the element, the deity, or a brand of outboard motors, and the system infers which from context. Named-entity recognition tops out at roughly ninety-five percent accuracy on clean benchmark data — that five percent is structural, not a bug the next version fixes. Take Python training with no URI attached: a system might resolve it as about eighty-five percent programming language and fifteen percent snake handling, which means fifteen queries in every hundred about your courses route to reptile content. Add a sameAs link to the correct Wikidata entry and the ambiguity is resolved at the declaration layer, before any inference is attempted, at a hundred percent. The agent does not need to guess, because the entity is declared.

There is no page two in the agentic web

So here is where this leaves you. In traditional search, a misread page cost you a ranking position and a listing on the second page. In agent-mediated selection, a failed verification check removes you from the candidate pool. The agent does not try harder to read your prose and it does not scroll to page two. It moves to the next source that provides clean, verifiable data. The cost of incomplete structured data in an agentic system is not reduced visibility. It is complete absence. That is a genuinely different penalty, and it deserves a different posture toward your schema than “we’ll get to it.”

You now have two audiences at once, and they need different things in parallel: human readers need clear, useful, well-structured content, and non-human agents need machine-verifiable structured data in typed fields. Neither substitutes for the other. The way I make this concrete for a business is to write a non-human ICP — the ideal-customer-profile discipline you already know, pointed at agents instead of buyers, describing the agent’s goal, the fields whose absence disqualifies you, the signals that rank you once you have passed, and where the agent goes to verify your claims. Building that profile against a real four-dimension template, and then working it through the three-layer Agent-Readiness Stack — entity, then attributes, then action, in that order — is the hands-on core of the course. And once agents are choosing you, the next question is how you even see it happening, which is where dark AI traffic picks up.