Customers' AI Agents Are at Your Door. Block or Allow?

A customer asks their AI agent to book a table, a cleaner, or a repair visit. The agent opens your website. A box says "verify you are human." The agent can't tick it, so it quits. The customer never learns why. They book somebody else. Tha

A customer asks their AI agent to book a table, a cleaner, or a repair visit. The agent opens your website. A box says "verify you are human." The agent can't tick it, so it quits.

The customer never learns why. They book somebody else.

That is the failure TechCrunch documented on October 6, when users of Meta's Muse agent complained it could not finish purchases on Walmart's site. Walmart told TechCrunch the blocks were not intentional, and that it is a Muse partner. The same week, Meta, Sierra, Stripe and others began writing a standard for how customers' agents are allowed in, and your business needs a position on it before the spec arrives.

Most blocked agents were not blocked on purpose

TechCrunch splits the blocks into two kinds. Some are deliberate. Others are "traditional anti-bot measures designed to protect against spam and malicious activity" that catch an agent by accident.

The deliberate ones are the famous names. Amazon stopped Muse from shopping its catalog. Delta told TechCrunch it does not currently have an integration that lets a third-party AI agent book its flights, and that opening up would have to be done "with security and the customer experience in mind." United pointed to the line in its Terms of Use that bars robots and automatic devices. Yelp says non-human traffic is not permitted unless the agent has paid for access through its data licensing program.

Those are companies with security teams and a reason to say no. You have a booking plugin somebody installed in 2022 and a spam filter you forgot about.

That is the group most at risk: the accidental blockers. The customer can't tell the difference between a policy and a glitch, so they blame both the agent and your business.

One front door instead of a thousand CAPTCHAs

Sierra's announcement describes what Meta and Sierra want to build. Today, Sierra says, most personal agents use websites the way people do, loading pages and clicking through forms, and when that fails they may call the support line or open the web chat. A direct connection could finish the same task securely in seconds.

The design is simple to say. The agent starts on your website and can begin as a guest, which may be enough to check availability or read a returns policy. When the job needs a customer's account, the customer signs in on your page, or with credentials they already set up with their agent. The customer decides whether the agent gets read-only or write access.

Sessions run on OAuth, the same standard behind "sign in with Google," and they carry across channels. A question asked before sign-in and a change made after it belong to one visit. From there the agent works through whichever route you offer: your normal pages, an interface built on MCP or OpenAPI, or a conversation with an agent of your own, which Sierra suggests for something like a warranty claim.

Sierra's summary line is the one to remember: "The company decides what it makes available, the personal agent gets a consistent way to connect, and the customer gets a faster way to get things done."

Decagon has a second draft on the table

Decagon, which sells customer support agents, joined the working group and also published its own protocol, PACT, co-developed with the personal agent Instinct. It is built on the Agent2Agent protocol and OAuth 2.0.

The part worth borrowing is the vocabulary. In PACT a business defines its own scopes, with names like orders:read or orders:cancel, and the customer approves only the ones they choose. The agent proves which platform it is, which is a separate question from what the customer allowed it to do. Replies under delegated authority carry signed receipts that record the scopes used and the actions taken.

Decagon's companion post makes the argument that matters for owners. It says personal agents are already contacting customer support, often reaching a brand's own AI agent, and mentions Instinct placing phone calls for its users. Then it says this:

Blocking these agents risks losing customers to competitors and pushes agents to get better at passing as human.

— Decagon, Personal agents are here. Meet them on your terms.

Decagon sells the product that answers those agents, so read it as a vendor's view. But the logic holds without the sales pitch. An agent that can't get in through the front will try the phone, then the chat widget, then a form, and it will look more like a person each time.

Three decisions to make before any spec arrives

Every version of this standard, whatever its name, will ask you the same three questions. Answer them now, in a document, and the rest is plumbing.

What can an agent read as a guest? Hours, prices or price bands, service area, availability, cancellation and refund terms. Put them in plain text on a public page, not in a PDF and not behind a login. If a human has to phone you to learn your call-out fee, so does their agent.

What can an agent request, and what changes need a human? Booking a slot is low risk. Cancelling a deposit, issuing a refund or changing an order's address is where you want a person or an explicit approval step. Our default is read-open, write-gated, and every action logged. It is the same rule we put on always-on agents inside the business, and it works from the other side of the door too.

Who answers when the question is not on the menu? A warranty edge case, an odd date, a customer who changed their mind. Either a person gets paged, or an agent of yours answers within rules you wrote. The phone is part of this answer: Google already dials local businesses for customers, as we covered in Google's AI is calling your business, and Decagon says Instinct places calls too. Your phone line will meet more machine callers than it did last year.

Here is how that looks on a small scale. Take a two-van cleaning company (an invented example, not a client). A guest agent can read the service area, the price per room band and the cancellation window. It can request a Thursday slot, which lands in the calendar as pending. It cannot cancel a paid booking or change the address on a job that starts tomorrow, because those routes require the customer to sign in and a person to confirm. Nothing about that is clever. It is a policy written down once, then enforced the same way for every agent that shows up.

Test your own site the way a customer's agent would

Do this before you read another article about protocols. Point any personal agent you have access to at your own booking page and ask it to book a slot for next Tuesday. Then watch where it stalls.

The usual suspects, none of them exotic:

• A human-verification box on the booking or contact form.
• Prices that only appear after you hand over an email address.
• Availability that loads only after a script runs a calendar widget the agent can't operate.
• A booking flow that sends a verification code to an inbox mid-way.
• A phone-only path for anything that is not the simplest service.

If your site sits behind a CDN or firewall with bot rules, check them too. We walked through one such setting, and the surprise it can cause, in should you block AI crawlers from your website. That post is about crawlers reading your pages; agents acting on them are a related but different case, so check what your rules say about both.

Keep the screenshots. If the stall is a plugin setting, it is a ten-minute fix. If the stall is the architecture of your booking tool, you have learned something worth knowing before a competitor with a cleaner flow gets the customer.

Blocking is a fair answer for some businesses

Not everyone should roll out the welcome mat. Yelp's product is its data, so it licenses access. An airline faces account takeover and fraud at a scale you will never see. A clinic or law firm with sensitive records has good reasons to keep write access firmly closed.

For a plumber, a salon, a bakery, a physio clinic or a small online store, the math runs the other way. Your margin comes from a customer reaching you, and a customer using an agent is a customer who has decided not to spend an hour comparing five websites. Turning that person away to stop a risk you can control with a read-only default is a bad trade.

Either way, make it a decision. A CAPTCHA you added for form spam in 2023 is not a policy.

What we would build now, and what we would wait for

We sell automation work, so discount this accordingly. Our view is that nobody should build to a v0.1 spec the week it appears. Standards in this phase change, and early implementers rebuild.

What survives any version is the layer under it. A public page of facts in plain text. A booking path that works without an account. A short, written permission table: read, request, needs a human. A log of what agents asked for and what happened. An answering route for the questions that don't fit, whether that is a person, a receptionist, or an agent of your own.

If that is the work you want taken off your plate, we build it for you: the facts page, the booking path, the approval rules and the log, tested against real agents before it goes live. Then when the spec lands, adopting it is a configuration change instead of a rebuild.