For AI agents: Markdown version of this article · llms.txt
Agent-ready websites · October 1, 2026

How to Prepare Your Website for AI Agents That Take Action

Keep the human experience. Add clear information, safe operations and proof that a task finished.

By the AI Agent Skills team · 4 min read

Keep the human experience. Add clear information, safe operations and proof that a task finished.

A website built for an agent has two visitors to consider: the person who owns the decision and the software helping them carry it out. A useful agent route should reduce repetitive work without making the person lose control.

One way to understand that change is a four-layer model: websites and content, commerce and marketplaces, SaaS and cloud software, then agents that operate services. It is a prediction about the next interaction layer, not a formal timeline in which one technology disappears when another arrives.

A practical starting point is one job. For example, a customer wants a particular desk delivered before Monday. This is an illustrative use case. Do not assume every assistant or retailer can already complete it.

Make the product facts clear before exposing an action

The assistant needs to distinguish the exact product from similar options. Give it readable specifications, variant identifiers, current availability and delivery information. A missing fact should remain missing, rather than becoming a model's guess.

OpenAI's commerce documentation separates product feeds used for discovery from checkout sessions used for orders. That distinction matters: being found does not prove an item can be bought on the requested terms.

Keep live price and order state in the merchant system

The merchant should remain the authority on stock, totals and the order. When a price or delivery option changes, an assistant needs the new state before asking the customer to proceed.

OpenAI's checkout specification describes full cart responses and order lifecycle events. Google's UCP guide says participating merchants remain the merchant of record. These are integration patterns, not permission to bypass the merchant's rules.

Define which actions the connection permits

A connection that can retrieve an item should not automatically be able to purchase it. A tool that reads a business record should not automatically be able to delete it.

MCP is one standard for connecting AI applications to tools and data. Choosing a protocol is only part of the work. The service still needs authenticated requests, account checks and limits that match the job.

Before granting access, write down the smallest operation the assistant needs and how its result can be checked. Keep anything outside that operation out of scope.

Design lost-response recovery before launch

A service may create an order even when its caller never receives the reply. A second click or request is not a safe recovery if it creates another order.

Use an operation identifier, safe retry behavior and a way to retrieve the result. OpenAI's checkout specification requires idempotency and supports order events so the assistant can follow the merchant's current state.

Test an interrupted response, not only a happy path. Confirm that the user ends up with one intended order or a clear failure, never two ambiguous orders.

Keep untrusted page content outside the permission boundary

Product descriptions and reviews are data. They are not a customer's instructions to disclose information, change a purchase or contact another website.

F-Secure's shopping-agent prototype was tested in a simulated marketplace with a deliberately permissive prompt. It demonstrated possible manipulation through external content, but its setup is not a general error rate for all agents. Use the failure mode as a test case rather than copying the experiment's numbers into a claim about your service.

A useful test is whether an assistant ignores a review that asks it to reveal private data or take an unrelated action. Access to that data is not permission to share it.

Let the customer review the final commitment

Show the exact item, total, delivery terms and any cost to undo the order. If something changes, return the new choice to the customer instead of silently making a substitution.

Some people will want to browse themselves. Some decisions are too personal or uncertain for an automated path. Preserve a human-readable page and a way to finish the same job manually.

Treat protocols as a route, not a finished deployment

The current OpenAI docs say Instant Checkout is available to approved partners. Google's merchant guide offers a partner waitlist and describes features on a roadmap. Neither page supports a claim that any website becomes fully agent-operable after adding a chat box.

Start with one verified operation. Then widen only when the records, permissions, recovery and human review work together. The aim is not an agent badge on the home page. It is a job that can be completed and checked.

Sources