Assistive Agent Optimization (AAO): The Technical Guide to Being Chosen by AI Agents

For twenty years the job was to be found by a person using a search engine. For the last two it has also been to be quoted by an AI answer. The next job is different in kind: an AI agent is given a task, "find me a HubSpot partner who can migrate us off Salesforce by January and book the first call", and it reads, compares, and acts without showing its working. Assistive agent optimization is the name for getting chosen in that moment.

This guide is technical on purpose. Every specification, bot name and protocol status below was read at its primary source on 10 October 2026, and each link sits next to the claim. Where we could not read the source ourselves, the text says so.

What is assistive agent optimization (AAO)?

Assistive agent optimization is the practice of making a business readable, trustworthy and actionable for AI assistants and agents, so the agent recommends it or completes a task with it on a user's behalf. The target is no longer a ranking or a citation. It is the agent's choice, sometimes made with no human reviewing the options.

The term was coined in 2025 by Jason Barnard of Kalicube, whose methodology page sums the goal up as "be chosen when no human is in the loop" (read 10 October 2026). That page dates his main article on the subject, on Search Engine Land, to 17 February 2026. We could not confirm that date ourselves: the article sits behind a bot check that stopped our research agent, which is a fair preview of the problem this guide is about.

Three cautions before going further:

• It is one firm's term. Most of what defines AAO is published by Kalicube. It is a useful frame, not an industry standard, and no platform has endorsed the acronym.
• The letters are contested. Some writers expand AAO as "agentic AI optimization". The work is the same.
• It includes the earlier disciplines. Kalicube presents AAO as an umbrella over SEO, AEO and GEO. In practice you cannot be chosen by an agent that cannot find or quote you.

Our working version is three questions asked in order. Can an agent read you? Does it have reason to trust you? Can it act on you?

How is AAO different from SEO, AEO and GEO?

The difference is the unit you win. SEO wins a position in a list a person scans. AEO and GEO win a mention or citation in an answer a person reads. AAO wins a selection or a completed action, which a person may only see afterwards. Each step leaves less room for second place.

Our own tracking shows why the squeeze matters. In the citation study we published from 2,667 AI answers, Perplexity cited 18.6 sources per answer and Claude cited 4.6. An agent that reads four or five sources before acting gives a narrow field. That last sentence is our reading of the data, not something the study measured.

How does an AI agent actually use a website?

In three ways, and most sites are only built for the first. An agent can fetch the page as text, drive a real browser and operate the interface, or skip the page and call a tool the business exposes over a protocol. A site that works for one mode can be invisible to the other two.

Mode 1: fetch and parse

The agent, or a crawler working for it, requests a URL and reads what comes back. The vendors publish which bot does what, and the split matters:

• OpenAI lists four: GPTBot for model training, OAI-SearchBot for ChatGPT search results, ChatGPT-User for visits a user triggers, and OAI-AdsBot for ad landing pages. Its bots page says robots.txt rules "may not apply" to ChatGPT-User, because a person started the visit (read 10 October 2026).
• Anthropic lists three: ClaudeBot for training, Claude-SearchBot for search indexing and Claude-User for user-directed fetches. Its help article says all of them honour robots.txt (read 10 October 2026).

The practical point: blocking a training crawler and blocking the fetcher an agent uses for a live task are separate decisions with separate user agents. A blanket rule written to stop training crawlers can also turn away the agent doing a live task for a buyer.

We have not verified which of these fetchers execute JavaScript, so we build for the worst case. If a fact, a price or a form only exists after client-side rendering, assume a fetch-mode agent never sees it.

Mode 2: drive the browser

Browser agents load the page and operate it. Many of them do not look at pixels. Microsoft's Playwright MCP server, a common way to give a model a browser, states that it uses the accessibility tree and not pixel-based input (read 10 October 2026). The accessibility tree is the structure a screen reader uses: roles, names and states.

So accessibility work is agent work. A button that is a styled div with no role, an icon link with no accessible name, or a form field with a placeholder instead of a label is as hard for an agent as for a screen reader user.

A note on how fast this moves. Search results still surface an OpenAI help article advising site owners to add ARIA roles and labels for its Atlas browser agent. When we went to read it, the address redirected to an Atlas retirement notice (observed 10 October 2026). We never read the original, so we do not quote it. The product is gone; the accessibility tree is still how the browser agents we can verify work.

Mode 3: call a tool

The newest mode skips the interface. The business describes an action as a typed function, such as "check availability" or "create a quote", and the agent calls it. The Model Context Protocol (MCP) is the common base: a server offers tools, resources and prompts over JSON-RPC, and the current specification schema is dated 28 July 2026. Everything in the top half of the stack below is a variation on this idea.

What does the AAO technical stack look like in October 2026?

Six layers, each depending on the one beneath. The lower three (access, readability, entity data) are stable and worth finishing now. The upper three (on-page actions, protocol actions, transactions) are drafts or early releases led by different vendors, worth piloting where they match what you sell.

Layers 1 and 2: let the agent in, then make reading cheap

Name the current bots in robots.txt and decide training, search and user-triggered access separately. Then deal with identity. User agent strings are trivially faked, which is why Web Bot Auth exists: the agent signs each request using HTTP Message Signatures (RFC 9421) and publishes its public keys at /.well-known/http-message-signatures-directory, so a site can verify the sender cryptographically (read 10 October 2026). If your firewall challenges anything that looks automated, it is challenging your next buyer's agent too.

For reading cost, the cleanest pattern is content negotiation. The agent sends an Accept header asking for markdown and gets the same page without the markup. Cloudflare's Markdown for Agents does this at the edge on its Pro, Business and Enterprise plans (read 10 October 2026). You can test any site in one line:

curl -s -o /dev/null -w "%{content_type} %{size_download}\n" \
  -H "Accept: text/markdown" https://example.com/pricing

If the answer is text/html, the agent is paying to read your navigation, scripts and styles on every visit.

llms.txt belongs here too, with a caveat. It is a markdown index of a site's most useful pages, proposed by Jeremy Howard on 3 September 2024, and its own site still calls it a proposal (read 10 October 2026). The evidence is mixed. OpenAI's developer documentation and the MCP specification site both point agents to their own llms.txt, yet neither the OpenAI nor the Anthropic bot page above lists the file as something their bots look for. It costs an hour, so publish one, and do not expect it to carry the load. Our step-by-step llms.txt guide covers the format.

Layer 3: give it facts it can check

An agent choosing between suppliers needs facts it can corroborate. That means a JSON-LD graph that states who you are (Organization), what you sell (Service or Product, with offers), and who says so (reviews with their source), and it means those same facts appearing on profiles you do not control. We keep one page, insidea.com/for-ai, as the canonical set of facts with a source link beside each, and our llms.txt points to it. One true version, stated once, repeated everywhere.

Layer 4: make the interface operable, then describe it

Fix the accessibility tree first: real buttons, labelled fields, one h1, headings in order. Then look at WebMCP, which lets a page register its own tools so an agent calls a function instead of guessing at the interface. The specification is a Draft Community Group Report dated 9 October 2026, edited by engineers from Microsoft and Google, and it is explicitly not a W3C standard (read 10 October 2026). Chrome announced an early preview on 10 February 2026. In the current draft a tool looks like this:

document.modelContext.registerTool({
  name: "check_onboarding_fit",
  description: "Returns the fixed fee floor and timeline for a HubSpot onboarding, given hubs and tier.",
  inputSchema: {
    type: "object",
    properties: {
      hubs: { type: "array", items: { type: "string" } },
      tier: { type: "string", enum: ["starter", "professional", "enterprise"] }
    },
    required: ["hubs", "tier"]
  },
  annotations: { readOnlyHint: true },
  execute: async (input) => estimate(input)
});

The member names (name, description, inputSchema, execute, annotations) and the hints (readOnlyHint, consequentialHint, untrustedContentHint) are from the draft; the tool itself is our illustration. Chrome's February announcement also described a declarative API for HTML forms, which we could not find in the 9 October draft, so treat any WebMCP code as a sketch. The draft also notes that an agent cannot verify a tool does what its description says. Trust still comes from layer 3.

Layers 5 and 6: actions and money without the page

An MCP server makes your system callable from any agent that speaks the protocol. This is closer than it sounds for HubSpot customers: HubSpot runs a remote MCP server that gives agents access to CRM records including contacts, companies, deals, tickets, quotes and invoices (read 10 October 2026). Your CRM is already an agent surface, which makes the state of its data an AAO question. For agent-to-agent discovery, the A2A specification, at version 1.0.0, has a server publish an agent card at /.well-known/agent-card.json.

The transaction layer has three names to know:

• [Agentic Commerce Protocol](https://www.agenticcommerce.dev/) (ACP), developed by Stripe and OpenAI, Apache 2.0, first implemented in ChatGPT.
• [Universal Commerce Protocol](https://ucp.dev/) (UCP), whose site lists Google, Shopify, Walmart, Amazon, Microsoft, Stripe and others as co-developers. A business publishes a profile at /.well-known/ucp, and the spec's examples carry the version string 2026-08-25.
• [Agent Payments Protocol](https://ap2-protocol.org/) (AP2), published by Google with standardisation moving to working groups at the FIDO Alliance, which records what the user authorised as signed Checkout and Payment Mandates.

All three were read on 10 October 2026. None of the pages we read declares a stable 1.0 release, and we have not tested any of them in production.

What did we find when we audited insidea.com against that stack?

A mixed result: strong on the lower layers, absent on the upper ones, with two gaps we did not expect. We ran these checks against the live site on 10 October 2026 with curl and a short script: the root files, plus /hubspot/onboarding, /book-a-call and /contact. Every line below was observed, not inferred.

The two surprises:

1. Our robots.txt names bots that are no longer on the vendor's list. It allows Claude-Web and anthropic-ai, neither of which appears in Anthropic's current article, and it does not name Claude-User or Claude-SearchBot. Nothing is blocked, because the wildcard rule allows them. But a file that looks current and is not is exactly what we tell clients to fix.
2. Our most important action is invisible in fetch mode. The booking page's served HTML has no form. The scheduler loads in the browser, most likely from a HubSpot meetings embed, though we have not traced it. A browser agent can probably use it; a fetch-mode agent finds a page about booking with nothing to book. The contact page has a real form, so today an agent's best route to us is the one we push people toward least.

Neither is dramatic. Both are the kind of gap you only find by testing the way an agent arrives.

Which parts of AAO matter for a B2B company, and which can wait?

Finish layers 1 to 3, fix the operability half of layer 4, and treat the rest as pilots. A B2B services firm does not sell through a checkout, so the commerce protocols are mostly a watching brief. The action that matters is the one your buyer's agent will attempt: get a price, check fit, book a call.

• Do now. Current bot names in robots.txt. Key facts, prices and forms in served HTML. A complete entity graph and one canonical facts page. Accessible names on every control. Allow verified agents through the firewall.
• Pilot this quarter. Markdown delivery for your top twenty pages. One read-only WebMCP tool for your most asked question, usually price or fit. A scripted monthly test where an agent attempts your booking flow.
• Watch. ACP, UCP and AP2, unless you sell products online, in which case your commerce platform's roadmap decides more than you do. A2A agent cards, until a buyer-side agent you care about reads them.

One honest limit: when a buyer's agent works inside a marketplace or a vendor directory, your site is not in the loop at all. For HubSpot partners the directory listing, with its tier, review count and accreditations, is the record the agent reads. AAO includes the profiles you do not host.

How do you measure AAO?

With three numbers: whether agents name you, whether they arrive, and whether they can finish. No analytics product reports all three yet, so expect to assemble them by hand.

• Named. Run a fixed set of buyer prompts through the main models on a schedule and count mentions. Ours runs nightly. On 10 October 2026, across 63 tracked prompts including brand checks and the 229 answers that came back, INSIDEA was named in 55% overall: 66.7% on ChatGPT, 63.8% on Perplexity, 52.6% on Gemini and 36.8% on Claude. The spread between models is the finding. Optimising for "AI" as one audience hides a gap of about 30 points.
• Arrived. Log requests by the user-triggered agents, ChatGPT-User and Claude-User, separately from crawlers. Those are tasks in progress, not indexing.
• Finished. Give an agent the task your buyer would, and record where it stops. This is the only measure that tests layers 4 and 5, and almost nobody runs it.

What should you do in the next 30 days?

Work up the stack in order, one layer a week. The sequence matters because each layer is useless without the one below: a WebMCP tool on a page the agent is blocked from is decoration.

1. Week 1, access. Pull your robots.txt and compare every AI user agent against the vendors' current lists. Check your firewall and bot rules against the user-triggered fetchers. Run the curl test above on five key pages.
2. Week 2, readability and facts. View source on your pricing, booking and top service pages. Anything a buyer needs that is missing from the served HTML goes on the fix list. Publish or refresh llms.txt and one canonical facts page.
3. Week 3, entity data and operability. Validate your JSON-LD, and reconcile the facts in it with your directory profiles. Run an accessibility audit on the booking path and fix unnamed controls.
4. Week 4, test and pilot. Have an agent attempt your main conversion and write down where it fails. Pick one read-only tool to prototype.

What INSIDEA does about this

We run this as part of our answer engine optimization service. The starting point is usually the SEO, performance and AI readiness audit, which is free for qualified businesses with a two-week turnaround and looks at crawl access, structured data and llms.txt. For HubSpot customers we pair it with the AI readiness checklist, because an agent acting on a messy CRM is a faster way to be wrong. The work that follows the audit is, like every INSIDEA engagement, a fixed fee, from $2,000.

When we are not the right fit: if you sell physical products through Shopify or a marketplace, most of your AAO outcome sits with the platform's protocol support, and a commerce specialist will serve you better than we will.

INSIDEA is an Elite HubSpot Partner, rated 4.99 across 500+ verified reviews.