AI agent protocol adoption: we analyzed 8 agents in 2026

AI agent protocol adoption has a strange gap in 2026. The standards are arriving faster than the runtime behavior. MCP is real. A2A is specified. llms.txt is being published by serious agent projects. Web Bot Auth is moving into production. Still, when agents browse the live web, the public evidence points somewhere more ordinary: screenshots, accessibility trees, DOM snapshots, CDP, Playwright, and manually configured tool servers.

For platform teams, "agent ready" now means two different things. One version is about manifests, cards, and machine-readable docs. The other is about whether today's agents can get through the product without getting lost. The second version is less tidy, but it is where the evidence keeps pointing.

This research extends our guides to agent skills discovery, A2A vs MCP architecture, AI agent API design, signed agent access, and llms.txt vs robots.txt.

Key Takeaways

• CanAgentUse Research reviewed 8 agent systems in June 2026 and found 0 confirmed cases of live general-purpose web agents consuming target-site manifests during ordinary browsing.
• In a preliminary 2,000-page form test with Hermes and OpenClaw, agents performed better on semantic, accessible pages and struggled on JavaScript-only controls.
• Agents usually tried browser automation first, even when OpenAPI existed. They switched to OpenAPI after failure when the spec was visible in page context.

Methodology

In June 2026, CanAgentUse Research reviewed 8 agent systems across official docs, public repos, issue threads, and credible third-party technical analysis. We classified evidence as Use, Pub, Manual, Discussed, Closed, or None. A claim only counted as Use if public evidence showed runtime consumption, not just support language or a marketing mention.

The reviewed sample included OpenAI ChatGPT agent and Operator, OpenAI Computer Use API, Anthropic Claude Computer Use, Perplexity Comet, Browser Use, OpenClaw, Hermes Agent, and OpenAI Agents SDK. We removed browser infrastructure projects and MCP servers from the agent sample. This is not the whole market. It is a grounded slice of the agents site owners are most likely to encounter or benchmark against.

Original Data

Our main measurement was intentionally strict: does a real general-purpose agent automatically discover and consume a target website's llms.txt, llms-full.txt, auth.md, WebMCP endpoint, A2A Agent Card, /.well-known/agent.json, UCP file, ai.txt, sitemap.xml, or robots.txt during normal live website use? In this 8-agent sample, the answer was 0 confirmed cases.

We separated tool interoperability from website discovery. MCP, configured OpenAPI, and remote tool servers can be good integration paths, but a developer or operator usually wires them up. Website discovery is a different claim: the agent lands on a normal site and discovers a capability from the site itself.

CanAgentUse Research reviewed 8 agent systems in June 2026 and found 0 confirmed public cases of general-purpose live web agents consuming target-site llms.txt, A2A Agent Cards, WebMCP, UCP, ai.txt, robots.txt, or sitemap.xml as runtime instructions during ordinary browsing.

What did agents actually use in 2026?

In the 8-agent sample, every system with enough public technical detail pointed toward browser control, screenshot-based interaction, accessibility snapshots, DOM-derived mappings, CDP, browser automation, or a configured tool path. The short answer is that agents use the web the way automation tools use the web: they inspect what the browser exposes, then act through a controlled browser session.

For OpenAI's Computer Use API, the official guide describes a model that inspects screenshots and returns UI actions. It also mentions optional harnesses such as Playwright for DOM-based workflows, which makes DOM access a harness choice rather than a discovered website standard. Anthropic's Computer Use docs follow a similar screenshot and action pattern, with domain controls and operational safety guidance.

Open agent systems are often more explicit about their browser stack. Browser Use, OpenClaw, and Hermes all describe some combination of accessibility trees, refs, DOM maps, CDP, browser sessions, or screenshots. Perplexity Comet is less transparent officially, but public third-party technical analysis points toward DOM, accessibility-tree, and Chrome-debugger style control rather than target-site protocol discovery.

This is the unglamorous part, but it is where teams get the fastest return. If a checkout button has no accessible name, a static manifesto will not rescue the flow. If a dashboard hides important state in a canvas with no semantic fallback, the agent may have to guess from pixels. A clean accessibility tree is now part of agent infrastructure.

Unique Insight

The adoption story is almost backwards from the protocol conversation. The most used "agent protocol" for websites is not a new file format. It is the accessibility tree plus browser automation. That is a little annoying, because it means old web quality problems are still the agent-readiness problem.

For practical implementation guidance, see our AI agent API design guide and agent readiness guide.

In the CanAgentUse 2026 review, browser perception and control had the broadest visible adoption. Across 8 reviewed agent systems, public evidence pointed to screenshots, accessibility snapshots, DOM mappings, CDP, browser automation, or configured tools, while target-site protocol consumption had 0 confirmed runtime cases.

Is MCP adopted by real agents?

In June 2026, MCP showed clear adoption across several reviewed systems, but mostly as a manually configured integration layer. The Model Context Protocol tools specification defines how servers expose tools for models to list and call. That is real infrastructure, but it is not the same thing as a browser agent discovering an arbitrary website's hidden capability endpoint.

OpenAI's Agents SDK documents configured MCP servers. Anthropic documents MCP connectors and Claude Code integrations. Browser Use ships MCP server support. OpenClaw can act as an MCP server and manage saved MCP servers. Hermes has extensive MCP docs. Those signals matter, but they belong to configured tool paths rather than automatic site-side discovery.

The question is who configures the connection. In the public evidence we reviewed, MCP usually enters through a developer, operator, app setting, local server, remote server URL, or explicit connector. That makes it useful for product integrations and internal tooling. It does not yet prove broad website-side discovery.

That should shape the roadmap. If you want agents to operate your product reliably, an MCP server can be worth building. It can expose stable tools like search_orders, get_inventory, create_ticket, or export_report. If the plan depends on agents discovering that server automatically from a marketing site, the public evidence is not there yet.

The architecture rule is simple: use MCP for dependable tool paths, not as a replacement for a usable web UI. For deeper planning, our A2A vs MCP guide, MCP server SEO guide, and OpenAPI to MCP guide cover where tool surfaces fit.

MCP adoption is visible in 2026, but the CanAgentUse review found it mainly in manually configured tool and server integrations. OpenAI, Anthropic, Browser Use, OpenClaw, and Hermes expose or document MCP paths, while automatic target-site MCP discovery was not publicly confirmed.

Do llms.txt and llms-full.txt get consumed by browser agents?

In the 8-agent sample, 3 projects were confirmed publishers of llms.txt or llms-full.txt: Browser Use, OpenClaw, and Hermes. Publication matters, especially for documentation and coding assistants. Still, the review found 0 confirmed cases where a general-purpose browser agent consumed a target site's llms.txt file during ordinary live browsing.

Browser Use publishes llms.txt and llms-full.txt, and its llms.txt links to its own OpenAPI spec. OpenClaw publishes both files and links its sitemap and robots policy. Hermes publishes both files and documents them as machine-readable entry points. Those are real publishing records.

Hermes gave the clearest caution. A public issue stated that the project's published llms.txt and llms-full.txt files were "not wired into the agent itself." That is the gap in one sentence. A project can believe in machine-readable docs, publish them, and still leave them outside the runtime agent loop.

This does not make llms.txt useless. It means the use case is narrower than some people imply. For docs-heavy products, SDKs, API references, pricing pages, integration guides, and support content, llms.txt can help retrieval systems and coding agents find the right material. It should sit beside sitemap, docs navigation, OpenAPI, and clean markdown content. It should not become your only agent-readiness bet.

For implementation details, start with llms.txt vs robots.txt, then connect it to agent skills discovery if your product exposes reusable actions or instructions.

CanAgentUse Research found 3 confirmed llms.txt or llms-full.txt publishers in the reviewed sample, but 0 confirmed browser-agent consumption cases. Browser Use, OpenClaw, and Hermes publish files, while Hermes publicly noted that its files were not wired into the agent runtime.

What did our form testing show?

In a preliminary CanAgentUse Research test across 2,000 public and purpose-built web pages, Hermes and OpenClaw behaved like browser operators first. The tested agents were asked to complete different form flows across semantic pages, accessible pages, JavaScript-heavy pages, pages with OpenAPI references, and pages with weak success or failure signals.

HTML quality was the clearest pattern. Agents struggled most when inputs were fully JavaScript-driven and did not expose useful semantic HTML tags. They performed better when pages used normal form elements, labels, accessible names, clear button text, and visible submission states. This matches the desk research: the accessibility tree and browser state are not side details. They are often the working interface.

Original Data

The OpenAPI behavior surprised us more. Agents preferred browser automation even when an OpenAPI document was available. They usually tried to fill and submit the form first. When that attempt failed, they almost always switched to openapi.json quickly if the spec was visible through a meta tag or mentioned in the body near the form. We did not see the same behavior for standard OpenAPI discovery paths.

Agents can use API contracts when the page puts the contract into the task context. They did not reliably go hunting through standard discovery locations before interacting with the page. "We have OpenAPI" is weaker than "this exact workflow tells the agent where the relevant OpenAPI contract is."

Two failure modes kept showing up outside the protocol conversation. Agents still struggled with website firewalls and captchas. They also struggled to know whether they had succeeded when the submission page gave weak signals. If success and failure states looked similar, or if validation errors were subtle, agents got confused and sometimes repeated the wrong action.

These findings are preliminary. We are preparing a full research paper with the page taxonomy, prompts, task setup, scoring rubric, success criteria, and failure examples. For this article, the takeaway is already clear: agent readiness is not just protocol publication. It is whether a live agent can understand the page, attempt the task, recover from failure, and know when the job is done.

In a preliminary 2,000-page CanAgentUse Research test, Hermes and OpenClaw preferred browser automation first, performed better on semantic accessible forms, struggled with JavaScript-only controls, captchas, and weak result states, and switched to OpenAPI mainly after browser failure when the spec appeared in page context.

Are A2A, Agent Cards, WebMCP, UCP, and ai.txt being used on live sites?

In the reviewed materials, A2A, Agent Cards, WebMCP, UCP, /.well-known/agent.json, auth.md, navigator.modelContext, and ai.txt had 0 confirmed cases of live general-purpose browser agents consuming them from target websites. That does not make these ideas dead. It means the public runtime evidence has not caught up with the protocol discussion.

A2A is worth watching because it has a clear job: agent-to-agent delegation. The A2A specification defines Agent Cards, task state, discovery, streaming, and agent collaboration. That is different from MCP, which is better understood as a tool-calling surface. Our finding is not that A2A lacks value. Our finding is narrower: we did not find public evidence that the reviewed live browser agents consume target-site Agent Cards during normal browsing.

UCP is also worth tracking for commerce, especially because it discusses multiple transports and commerce semantics. But for ordinary shopping tasks in the reviewed agent materials, the evidence pointed to browser operation, user approvals, screenshots, forms, product pages, and sometimes APIs. We did not find public evidence that general-purpose browser agents were UCP-native buyers.

WebMCP and browser-native context ideas face a tougher proof problem. A site-side handshake sounds attractive, but the agent has to trust it, authenticate it, fit it into the browser runtime, and defend against prompt injection. Until there is native browser support or a widely adopted discovery handshake, these ideas will likely stay behind browser automation and manual integrations.

CanAgentUse should be strict here. A site can get credit for publishing emerging surfaces, but the score should distinguish "published" from "currently consumed by known agents." Otherwise, readiness reports will reward speculation as if it were adoption.

In the CanAgentUse 2026 review, A2A Agent Cards, WebMCP, UCP, /.well-known/agent.json, auth.md, navigator.modelContext, and ai.txt had 0 confirmed cases of target-site runtime consumption by the 8 reviewed agent systems.

Why is protocol adoption slower than protocol publication?

In the CanAgentUse review, 3 projects published llms.txt files, several systems used MCP manually, and 0 confirmed cases showed target-site protocol consumption during normal browsing. The main reason is practical: browser agents already have a working way to perceive and control the web.

Accessibility snapshots, DOM maps, screenshots, CDP, and Playwright are imperfect, but they work across arbitrary sites. They also preserve live state. A static file cannot tell an agent what is currently in a user's cart, whether a modal is open, which account is logged in, or which validation error just appeared after form submission.

Security is the second barrier. If an agent consumes natural-language instructions from a website, prompt injection becomes part of the protocol. Vendor safety docs and public agent reports show that browser-agent teams are already dealing with injected instructions, secret exposure risks, and user approval boundaries. Adding more text that agents are expected to trust is not free.

Authentication adds more friction. Agent tasks often cross logged-in pages, payment flows, enterprise apps, and private dashboards. A static discovery file rarely has enough context to do the job. A configured MCP server, OAuth connector, or signed agent request can handle trust more cleanly, but those systems require setup.

The last barrier is incentives. Sites will not invest heavily until agents consume the surfaces. Agent vendors will not depend on the surfaces until enough sites publish them correctly. Browser automation wins because it avoids that coordination problem. It uses the web that already exists.

Unique Insight

The blocker is not ignorance. Many agent builders know about these standards. The problem is harder: site-side discovery has to beat a messy but universal fallback, the browser itself. Until a protocol handles state, auth, trust, freshness, and interaction better than the browser loop, it will remain supplemental.

Protocol publication is ahead of protocol consumption because browser automation already works across arbitrary sites. CanAgentUse Research found 0 confirmed target-site protocol consumption cases, while accessibility snapshots, DOM maps, screenshots, CDP, and browser control appeared across the reviewed agent stack.

What should platform teams do now?

In 2026, the evidence points to a simple order: make the UI agent-usable first, expose programmable workflows second, publish supplemental discovery files third. That order matches the public adoption pattern: browser perception is widespread, manual MCP is real, and target-site protocol consumption remains unconfirmed.

Start with accessibility. Use semantic controls. Give every important button and input a stable accessible name. Make form labels explicit. Avoid icon-only critical actions unless the icon has a reliable label. Keep keyboard interaction working. If the accessibility tree is the agent's map, unlabeled UI is missing road signs.

Next, make browser interactions predictable. Keep important actions visible. Avoid brittle multi-step flows where state only appears in a canvas, animation, or custom widget. Use stable URLs for meaningful states where possible. Keep modals and validation errors legible in the DOM. Agents are better at careful interaction when the product behaves like a well-built web app.

Then expose tools for workflows where reliability matters. If agents need to query inventory, file tickets, update account records, export reports, or check order status, offer an API and consider MCP. Tool surfaces let you enforce auth, rate limits, schemas, confirmations, and audit logs more cleanly than raw browser operation.

Publish llms.txt and related docs as a supplement. They can help retrieval, coding assistants, and external documentation flows. Pair them with OpenAPI, sitemaps, clear docs, and structured pages. Do not treat them as a replacement for accessible UI or first-party APIs.

For trust and traffic control, support agent identity where vendors provide it. OpenAI's signed request and .well-known/http-message-signatures-directory path is one concrete example. For agent-facing commerce or sensitive flows, pair verification with explicit approvals, not silent autonomous writes.

For a concrete implementation path, connect this article to our signed agents guide, auth.md and DNS-AID setup guide, agent card discovery guide, and agent payments guide.

Platform teams should prioritize accessible UI, predictable browser flows, and explicit APIs or MCP tools before betting on automatic site-side protocol discovery. In CanAgentUse Research's 8-agent review, those practical surfaces had public adoption evidence, while target-site protocol consumption had 0 confirmed cases.

What should CanAgentUse measure?

In 2026, an honest agent-readiness scanner should score evidence in layers, because the 8-agent review found a sharp gap between publication and runtime consumption. CanAgentUse should reward emerging files, but it should score them differently from surfaces that agents visibly use today.

A useful scoring model has four buckets. The first bucket is browser usability: accessibility tree quality, labeled controls, forms, navigation, page state, and obvious interaction paths. The second is programmable capability: OpenAPI, MCP, action schemas, auth, rate limits, and safe write operations. The third is machine-readable discovery: llms.txt, sitemaps, robots policy, agent cards, and related well-known files. The fourth is trust: signed agent requests, bot policy, consent, and abuse controls.

The wording matters. A report should say "published but not known to be consumed," not "agent supported." It should say "manual MCP available," not "automatic agent discovery." That language helps teams make real product decisions instead of chasing checkboxes.

This also helps GEO. AI search systems prefer crisp, extractable claims. A page that says exactly what is confirmed, what is manual, and what is unconfirmed is easier to cite than a page that blends all protocol ideas into one optimistic category.

CanAgentUse should separate runtime consumption, manual configuration, publication, and unconfirmed proposals. The 2026 research found that collapsing those categories would overstate adoption, especially for llms.txt, A2A Agent Cards, WebMCP, UCP, and other site-side discovery ideas.

FAQ

What is AI agent protocol adoption?

AI agent protocol adoption means real agents use a protocol during operation, not merely that a spec exists. In this review, CanAgentUse Research analyzed 8 agent systems and found 0 confirmed cases of target-site manifest consumption during normal browsing, while browser perception and manual MCP integrations had visible adoption.

Is MCP the winning AI agent protocol?

MCP is one of the strongest adopted protocols in this review, but its adoption is mostly manual. Several reviewed ecosystems document or ship MCP paths, including OpenAI, Anthropic, Browser Use, OpenClaw, and Hermes. That makes MCP useful for integrations, not proof of automatic website discovery.

Should we publish llms.txt in 2026?

Yes, publish llms.txt if your site has docs, APIs, SDKs, or support pages that agents should retrieve. In this review, 3 projects published llms.txt or llms-full.txt, but 0 confirmed cases showed live browser agents consuming target-site files during ordinary browsing. Treat it as supplemental.

Are A2A Agent Cards useful yet?

A2A Agent Cards are useful for planning agent-to-agent delegation, especially when another agent owns a task, state, or policy layer. In this review, however, 0 confirmed cases showed the 8 reviewed agent systems consuming target-site Agent Cards during live browsing. Build them when delegation is real.

Can I cite this research?

Yes. Cite it as: CanAgentUse Research, "AI agent protocol adoption: we analyzed 8 agents in 2026," CanAgentUse, June 16, 2026. The core finding is that 8 agent systems were reviewed and 0 confirmed public cases showed target-site protocol consumption during ordinary live web browsing.

Source notes

• CanAgentUse Research, "Deep Technical Investigation of Whether Real General-Purpose Web Agents Consume Emerging Agent-Facing Website Standards," internal research report, reviewed 2026-06-16.
• OpenAI, "Introducing ChatGPT agent," 2026-06-16, openai.com/index/introducing-chatgpt-agent
• OpenAI, "Computer Use," 2026-06-16, platform.openai.com/docs/guides/tools-computer-use
• OpenAI, "Agents SDK MCP," 2026-06-16, openai.github.io/openai-agents-python/mcp
• Anthropic, "Computer use," 2026-06-16, docs.anthropic.com/en/docs/agents-and-tools/tool-use/computer-use-tool
• Anthropic, "Model Context Protocol connector," 2026-06-16, docs.anthropic.com/en/docs/agents-and-tools/mcp-connector
• Model Context Protocol, "Tools," 2026-06-16, modelcontextprotocol.io/specification/2025-06-18/server/tools
• A2A Protocol, "Specification," 2026-06-16, a2a-protocol.org/latest/specification
• Browser Use, "llms.txt," 2026-06-16, docs.browser-use.com/llms.txt
• Browser Use, "MCP server," 2026-06-16, docs.browser-use.com/customize/mcp-server
• OpenClaw, "llms.txt," 2026-06-16, docs.openclaw.ai/llms.txt
• OpenAI, "ChatGPT agent allowlisting," 2026-06-16, help.openai.com

Data appendix

Citation format:

CanAgentUse Research. "AI agent protocol adoption: we analyzed 8 agents in 2026." CanAgentUse, June 16, 2026. https://canagentuse.com/blog/ai-agent-protocol-adoption-research