Technical SEO · agents.json · WAIS

agents.json and WAIS : the new SEO standards for the AI agent era

For twenty years, technical SEO has been built around robots.txt (1994) and sitemap.xml (2005). The arrival of AI agents that execute transactional tasks on behalf of the user introduces two new standards : agents.json for capability discovery, and WAIS for authenticating the agent via Proof of Delegation. This article dissects both, distinguishes them, and outlines an implementation strategy.

Fact-checked and updated on September ^st, 2026. Primary sources are cited at the end of the article.

From discovery SEO to execution SEO

Traditional SEO optimizes the readability of a site for crawlers : titles, meta descriptions, Schema.org structured data, canonical tags. That optimization still matters for the discovery phase on search engines and for the LLMs that produce text answers.

But modern AI agents no longer just summarize a page : they execute transactions on behalf of the user — booking a table, comparing B2B quotes, extracting a quotation. For these agents to discover what a site can do before even visiting it, and to prove to the site that they act with human authorization, two open standards emerged in 2025–2026.

agents.json : the third era of technical discoverability

agents.json is an open JSON format, initiated by Wildcard AI and built on OpenAPI foundations. It formally describes the actions an agent can take on a given domain : search a catalogue, add an item to a cart, submit a form, extract a report.

It is not a file meant to summarize the textual content of the page (the role of llms.txt and Schema.org), but rather an instruction manual describing concrete, programmatically callable actions.

Location and accessibility

The file agents.json must be hosted at the standardized path /.well-known/agents.json at the domain root. This is a discovery convention similar to security.txt, change-password or webfinger.

For the file to be readable by agents from various origins, the CORS policy must allow cross-origin access. A typical configuration :

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Max-Age: 86400

File structure

The current specification (version 0.1.0) requires a structure divided into semantic sections :

• metadata : entity identity (name, description, schema_version, contacts).
• tools : the tool matrix, each with name, description, endpoint, method, parameters (including types and enums).
• capabilities : protocol flags (webmcp, a2a, supported languages).

Here is a minimal example for a room-booking platform :

{
  "schema_version": "0.1.0",
  "name": "Acme Coworking Booking",
  "description": "Coworking room-booking platform in Paris.",
  "contact": { "email": "[email protected]" },
  "capabilities": {
    "webmcp": true,
    "a2a": false,
    "languages": ["fr", "en"]
  },
  "tools": [
    {
      "name": "search_rooms",
      "description": "Find available meeting rooms by date, capacity and district.",
      "endpoint": "https://acme.example/api/rooms/search",
      "method": "POST",
      "parameters": {
        "date": { "type": "string", "format": "date", "required": true },
        "capacity": { "type": "integer", "minimum": 1, "required": true },
        "arrondissement": {
          "type": "string",
          "enum": ["75001","75002","75003","75004"],
          "required": false
        }
      }
    },
    {
      "name": "book_room",
      "description": "Book a specific room for a given time slot. Human confirmation required.",
      "endpoint": "https://acme.example/api/rooms/book",
      "method": "POST",
      "parameters": {
        "room_id": { "type": "string", "required": true },
        "start_time": { "type": "string", "format": "date-time", "required": true },
        "duration_hours": { "type": "integer", "minimum": 1, "maximum": 8, "required": true }
      }
    }
  ]
}

For a showcase site with no programmable action, the absence of agents.json is not penalizing. For an e-commerce site, a SaaS platform or a booking system, this file becomes critical infrastructure for agent-driven acquisition.

agent-card.json vs agents.json : don’t confuse them

A frequent confusion among architects concerns the difference between agents.json and agent-card.json. Both belong to the A2A (Agent-to-Agent) ecosystem, but their uses differ.

Use agent-card.json if your domain hosts a single clearly delimited service. Use agents.json if you expose several agents (support, recommendations, billing) from the same domain.

WAIS : authenticating the agent via Proof of Delegation

WAIS (Web Agent Interaction Standard), draft v0.1 published in February 2026 by Deeger, solves a complementary question : how does a website tell the difference between a malicious bot, an aggressive scraper, and an AI agent legitimately authorized by a human ?

The traditional answer — CAPTCHAs, fingerprinting — blocks any legitimate automation by design. WAIS proposes a cryptographic alternative : the Proof of Delegation (PoD).

The PoD mechanism

Instead of asking the client to prove it is human, PoD lets the agent mathematically prove that a real human explicitly authorized it to act within strictly defined limits.

Concretely, the agent presents a JWT signed with the ES256 algorithm in the HTTP header X-WAIS-PoD :

X-WAIS-PoD: eyJhbGciOiJFUzI1NiIsInR5cCI6IldBSVMtUG9EIn0...

The payload, once decoded, contains :

{
  "iss": "https://agent-platform.example",
  "aud": "https://target-site.example",
  "delegation": {
    "user_verified": true,
    "scopes": ["catalog.browse", "checkout.execute"],
    "constraints": {
      "max_transaction_amount": { "value": 500, "currency": "EUR" },
      "ttl_seconds": 600
    }
  }
}

The site verifies the signature via public-key infrastructure, checks the scopes, enforces the constraints, and only authorizes strictly delegated actions. The user’s identity stays private ; only the proof of authorization is verified.

The four WAIS adoption levels

WAIS offers a progressive adoption model, measurable with an audit tool called « WAIS Lighthouse » :

For levels L3 and L4, WAIS imposes a systematic confirmation protocol on critical actions : an explicit challenge the human user must approve before the action executes.

Implementation strategy : from manifest to transaction

For a B2B or e-commerce site dealing with significant agentic traffic, here is the recommended progressive roadmap :

1. Audit transactional capabilities : list every action a human user can perform (search, add to cart, quote request, scheduling, cancellation). Identify the critical revenue-generating flows.
2. L1 deployment : publish /.well-known/agents.json with read-only endpoints only. Open CORS. No backend changes. The site becomes discoverable with zero risk.
3. CORS validation and accessibility : test access from several origins (curl with an Origin header), verify the file is served with the right Content-Type (application/json), and that it appears in your access logs.
4. L2 exposure : implement PoD token verification. Add mutation endpoints to agents.json. Prepare the server-side signing infrastructure (ES256 key generation and rotation).
5. L3 migration : enable HITL for critical flows. Every financial transaction triggers a confirmation challenge the user resolves via the site UI or a push notification.
6. L4 activation : if relevant to your model, open outbound webhooks. Every significant event (validated order, shipment confirmed, refund issued) is pushed to subscribed agents.

Positioning relative to WebMCP

It is essential to understand that agents.json and WebMCP operate at distinct layers and are complementary :

• agents.json serves discovery : the agent learns, before even visiting the page, which actions the site exposes.
• WebMCP serves authenticated in-context execution : the agent, already inside the user’s logged-in browser, calls structured tools on the active page.

A mature site exposes both : agents.json to let agents map the domain, and WebMCP to let them act inside the user’s session without separate API keys. To go further on execution, see our dedicated WebMCP Declarative API article and our back-office automation analysis via WebMCP.

Success indicators and the visibility-gap pitfall

Sites that ignore these new formats expose themselves to what analysts call the « visibility gap » : if an AI agent evaluating vendors for a B2B client cannot deterministically read a software’s capabilities via agents.json or interact through WebMCP, that vendor is dropped from the automated consideration pipeline.

Observable indicators after deployment :

• Appearance of GET /.well-known/agents.json in server logs, with third-party origins (crawler agents).
• Listing of the site in A2A registries and agent directories.
• Increase in referral traffic from identified agents (User-Agent containing « Agent » or similar signatures).

Conclusion

The arrival of transactional AI agents imposes a third wave of technical SEO, after crawl SEO (robots.txt, sitemap.xml) and context SEO (llms.txt, Schema.org). This wave is execution SEO : agents.json for discovery, WAIS for authentication, WebMCP for in-context invocation.

Organizations that adopt these standards in 2026 secure their discoverability with a category of intermediaries whose weight will grow quickly. The others expose themselves to a silent erosion of their visibility in automated flows.

Primary sources

1. Wildcard AI — Introducing agents.json — the original format specification.
2. A2A Registry — agents.json Spec — multi-agent extension and comparison with agent-card.json.
3. Deeger — WAIS · Web Agent Interaction Standard — draft v0.1, February 2026.
4. WebMCP — Official W3C CG repository — for the complementary execution layer.
5. developer.chrome.com/docs/ai/webmcp — the Chrome-side WebMCP reference.
6. WebMCP — discussion on consent management — to understand the evolution of the permission model.