A chat interface is not an integration. Give agents accurate state, bounded actions and a result they can verify.
By Tej Pandya, founder of GrowEasy.ai
I think of the next internet layer as a change in the operator. Websites, marketplaces and cloud applications continue to exist, but an agent performs some of the work a person previously did through their interfaces.
That is a prediction, not a replacement schedule. For developers, it creates a practical question: what does a service need when its caller is trying to finish a task rather than render a screen?
Consider an illustrative desk-ordering service. The user asks for a specific size and delivery before Monday. The engineering problem is not generating a persuasive product description. It is returning facts and performing authorized changes without losing track of the order.
A description may help discovery, but checkout needs the exact variant, current price, delivery options and any limits. Separate the text used to explain a product from the state used to make a purchase.
OpenAI's Agentic Checkout Spec requires a rich cart state, including items, pricing, taxes or fees, shipping, discounts, totals and status. The merchant's response is the authority, not the model's memory of an earlier page.
An out-of-stock response should be explicit. Do not make a caller infer it from a missing button or an empty field. If no delivery estimate is available, return that uncertainty rather than a guessed date.
Start with an operation whose inputs and effects are easy to define. Creating a checkout session is different from completing it. Retrieving a customer record is different from changing that record.
MCP provides a standard connection between AI applications and data sources or tools. It does not turn every exposed tool into a safe action. The service still needs its own validation, access checks and clear operation boundaries.
An agent-facing interface should be another client of the same business rules, not a shortcut around them.
Suppose a complete-order request reaches the server, but the response is lost. Retrying blindly could create a second order. Reporting success without checking could hide a failure.
Use an idempotency mechanism and a retrievable operation result. OpenAI's checkout specification explicitly calls for idempotency, request tracing, authenticated requests and safe retries. Its order webhooks let the caller stay aligned with the merchant's order state. The general design lesson is simple: uncertainty about delivery of a response is not evidence that the write failed.
Do not trust a caller simply because it says it is an agent. Validate its identity and the account it can access. Keep the permission to read separate from the permission to change or buy.
A product page can contain useful data and hostile instructions at the same time. F-Secure's simulated shopping-agent experiment showed how a prototype could follow malicious content. That experiment is not a benchmark for your implementation, but it is a reason to test the boundary between external text and authorized actions.
Include a test in which a product review asks the assistant to leave the site or disclose private information. Your integration must not accept that review as permission.
A user should be able to inspect the proposed item, final total and delivery terms before a purchase. When the service cannot complete an operation, return a useful reason and a recoverable next step.
Do not send the user back to the beginning because one address field needs correction. Preserve the valid work, explain what is missing and let the caller continue the same operation.
Connect one service, define the success state and exercise failure cases: stale availability, wrong account, a lost response and a changed total. Then inspect the stored result.
Google's UCP guide and OpenAI's commerce docs show the direction, but access and feature scope remain important. OpenAI limits Instant Checkout to approved partners; Google's guide has a waitlist and roadmap. Do not advertise a universal integration based on reading a protocol specification.
The useful promise is smaller: this operation can be discovered, called within its limits and checked after it runs. That is how a website becomes part of an agent-operated internet.