Grais

Agent-Ready Websites Need Public Discovery Boundaries

ByGrais Team

Chrome's new agent-ready website guidance makes one point hard to ignore: agents need predictable surfaces, not only polished pages. The useful product question is not "can an agent click this?" It is "what public contract tells an agent what exists, what is safe to read, and what is still off limits?"

That matters for Grais because communication work is high-context. A site can help agents understand public docs, product guidance, and research material without pretending that private account state, checkout actions, or extension handoffs are public tools. The standard should be truthful discovery before agent action.

What changed

On June 22, 2026, Chrome published A developer toolkit to make your website agent-ready. Chrome frames the shift as two stages: agents finding websites, then agents using websites. The post points developers toward deterministic audits, accessibility tree quality, visual stability, Chrome DevTools for Agents, and WebMCP checks for sites that expose structured tools.

Chrome also opened the WebMCP origin trial on June 9, 2026. That announcement describes WebMCP as a way for websites to declare how agents should interact with application logic and page state instead of forcing agents to guess from buttons and fields.

The direction is practical: agent readiness is becoming inspectable. It is no longer only a copywriting claim about being "AI friendly." It is a set of machine-readable signals, accessibility constraints, and explicit tool contracts that can be audited.

The boundary that matters

For many websites, the temptation will be to advertise every possible agent surface early. That is backwards.

The first agent-ready layer should be conservative and public. A crawler or agent should be able to discover the public content map, support surfaces, policies, and read-only descriptions before it is invited anywhere near account state or action-taking workflows.

Grais already follows that shape on the website side. The public site exposes an API catalog, an LLM-readable site map, and a conservative agent index for website-owned discovery. Those surfaces are intentionally narrow. They point to public content, support, policy, read-only discovery, and the existing public waitlist form surface; they do not claim a public MCP server, WebMCP tool surface, authenticated agent registration flow, Stripe action surface, or extension-token handoff.

That restraint is a feature. In agent-facing products, overclaiming capability is not only a documentation problem. It can cause agents to plan around a tool that does not exist or assume permission the user never granted.

How this relates to Grais

Grais's live product work still starts with the human user. The getting-started guide explains the browser extension path, supported desktop Chromium browsers, visible conversation context, draft review, and final send responsibility. The v0.11 product update describes the side-panel workspace, context continuity, planning, memory, and human-approved reply workflows.

That product boundary should carry into public agent discovery. Agents can read the public research library, support center, policies, and discovery files. They should not infer that public discovery equals permission to operate inside a user's private conversation, billing state, or extension session.

If the question is whether AI may inspect, suggest, draft, or continue beyond the visible thread, use the agent action-scope protocol before the work begins. If the question is whether the browser, context, owner, policy, or handoff environment can support the workflow, use the operating-constraint check before turning a site or extension capability into an execution plan.

A useful readiness check

Before a website advertises an agent-facing surface, ask four questions:

  • Is the surface real today? Discovery should point to working public endpoints, not roadmap intent.
  • Is the scope read-only or action-taking? Public content discovery and authenticated execution need different contracts.
  • Can the agent tell what is excluded? A good index names deferred surfaces as clearly as supported ones.
  • Would a human reviewer understand the same boundary? If the contract is too subtle for a person to inspect, an agent will probably over-assume.

This is why agent-ready work should start with public discovery hygiene: canonical content, machine-readable maps, clear policies, and honest exclusions. WebMCP and richer agent tools can come later when the product surface is real, owned, and safe to expose.

The useful takeaway

Chrome's agent-ready toolkit and WebMCP origin trial raise the bar for websites that expect agents to use them. The product standard is not maximum automation. It is truthful discovery: expose what is public, name what is deferred, and keep private actions behind explicit human and product boundaries.