Your Next Customer May Arrive as an AI Agent

In September 2026, people who asked Meta’s Muse agent to shop on Amazon started getting a popup instead. “Continued access by an unauthorized AI agent violates Amazon’s Conditions of Use, to which our customers have agreed,” it read, according to Adweek’s reporting. Amazon said it had asked Meta to remove Amazon from the experience.

On October 6, 2026, Meta and the AI company Sierra announced a different answer: the Personal Agent Protocol, an open standard, since published in draft, for how a customer’s AI agent and a business deal with each other. Meta, which builds Muse and has its own interest in the answer, put its case in one line, quoted by TechCrunch from its announcement: “Turning away a personal agent means turning away the customer behind it.”

One company turned the agent away, and the company that built it proposed rules for letting it in. A company that sells, books or serves anything online will need its own answer.

Two answers to the same visitor

A personal agent is an AI assistant a person sends to do an errand: book the flight, reorder the groceries, change the delivery address. It reads what the person wants, works out on its own which steps get there, and clicks through the company’s site, or calls its systems, to take them.

Amazon’s objections, as it told Adweek, were specific. It hadn’t been told in advance or asked for permission, the agent didn’t identify itself, it appeared to capture and store customer credentials, and it bypassed the personalization built into Amazon’s shopping experience. Meta didn’t comment to Adweek.

Other companies sit at different points. A Walmart spokesperson told TechCrunch that the blocks Muse users ran into weren’t intentional, and Walmart partners with Muse. Delta told TechCrunch it has no partnership for outside agents to book its flights and is still evaluating. United pointed TechCrunch to its terms of use, which bar robots and other automatic devices used to copy the site, or for any other unauthorized purpose, without United’s prior written permission. Yelp told TechCrunch it allows non-human traffic only if it’s paid for through its data licensing program.

What’s new is that the question now has a structure, and it gives a company more choices than yes or no.

What the protocol puts on the table

In Sierra’s announcement, written by Bret Taylor and Clay Bavor, an agent “can start as a guest, which may be enough to check product availability or ask about a returns policy.” When the task needs the customer’s account, the customer signs in and decides “whether the agent has read-only or write access.” Companies, in turn, “set parameters for what those agents can do.”

The draft specification, published as version 0.1, fills in the rest. Every request tells the company it comes from a personal agent and which one, and once the customer signs in, on whose behalf, so an agent that uses the protocol doesn’t arrive unannounced. It’s the outside version of something we argued for inside the company, giving every AI agent its own badge. The company decides which operations need which permission, and it can offer narrower permissions of its own or leave an action out entirely. The customer can disconnect the agent from their account settings.

The protocol’s roadmap lists the companies that have agreed to appear as design partners. OpenAI, Meta and Instinct, which all make personal agents, are there on the agent side, and among the businesses are Walmart, Target, Bank of America and United Airlines. A listing isn’t a deployment, though. United is on that list, and its terms still require written permission for automatic devices, which tells you how early this is: being in the room where the rules are written doesn’t mean the door is open.

One task, three decisions

Say a customer tells their agent: swap the jacket I bought last month for a warmer one, and don’t spend more than $80 extra.

The agent has to read that goal, search the catalog, decide which jacket counts as warmer and fits the budget, and propose the exchange. Making that judgment is the AI part, and it’s exactly what a company is being asked to accept or check. The specification’s own illustration runs almost the same errand, with fictional companies: an exchange for an insulated jacket at $70 more, charged to the card on the original order.

So the useful question isn’t whether an agent like that may come in. It’s which task you’d let it do, and on what terms. We’d answer it in three steps, and the order matters: the value of the task decides everything after it.

1. Choose one customer task worth handing to an agent. Look for something your customers already find tedious and do often: tracking an order, rebooking, reordering, an exchange. Your support contacts are the best evidence you have, because a task that fills the inbox is a task people would gladly hand off. Then weigh what Amazon itself raised: an agent shopping for a customer bypasses your pages and your recommendations. If those pages are where a task makes its money, say so before anyone builds anything.

2. Set its boundaries. Three questions, answered for that one task.

• What may the agent see? Use the phone test. Would your call center tell anyone who calls, like stock, price or the returns policy? Then an agent can get it without the customer signing in. Is it something you’d tell only the verified customer, like their order history or address? Then only after the customer signs in and grants read access. The phone test only sorts information. Changes are the next question.
• What may it change, and who approves? For each change, and explicitly for anything that charges, refunds or commits the customer, decide whether the customer must approve the exact terms every time, or whether an earlier permission with a stated limit can cover it. The specification supports both, and lets a company insist on fresh approval. The customer gives that approval inside the agent’s own app, though, so you’re relying on the agent’s report. If an agent misuses the protocol, the specification lets you cut it off. In the jacket case, you might let a standing permission cover a same-price size swap and require the customer’s approval of the exact terms for anything that costs more.
• What happens when it goes wrong? Name the fallback for a failed or disputed change: which person picks it up, and how the customer reaches them. It’s the test we suggested for AI in customer service: where a bad interaction would cost you the customer, keep a person within reach.

Anything you’re not ready to offer stays off the menu. The specification allows that, and a short menu is easier to check when something goes wrong.

3. Pilot or monitor. A pilot means opening that one task to agents on the terms you just set. Run one when three things are true: the task shows up often in your support contacts, your platform vendor or your own team can support it (Shopify and Stripe are among the protocol’s technology partners), and you can live with the failure path you just named. Before the pilot, have whoever runs your site try the task with an agent available today, such as Meta’s Muse, on a test account, and report what actually happens, since Walmart’s experience suggests a site can block agents nobody decided to block. If any of the three is missing, monitor instead, with one owner and a trigger that reopens the decision, such as the specification moving past its draft or your platform shipping support.

What you’re left with fits on one card, one per task:

• Customer task and its benefit: exchange a jacket for a different size or model, which saves the customer a return trip and a support call.
• Access: signed out to browse the catalog, read access for the original order, write access for the exchange.
• Approval and fallback: a standing permission covers same-price size swaps, the customer approves the exact terms for anything that costs more, like the warmer jacket, and a failed exchange goes to a named person in support.
• Pilot or monitor: pilot once step 3’s three conditions hold, otherwise monitor.
• Owner and review trigger: the head of e-commerce, with a review when the specification leaves draft.

What a draft standard can’t promise yet

The specification calls itself a draft, and says any part of it can change before a stable version, including in ways that break earlier drafts. The card is the durable part. The protocol’s details should be checked again before anyone builds against them.

None of these sources says how many customers use agents today, so this is a decision about being ready, with no measure of demand behind it. The cases come mostly from shopping and travel, and a business customer sending a purchasing agent is our extrapolation. Payments are still an open topic on the roadmap, even though a change can carry a charge, which is why step 2 asks about charges on their own. And if your business earns its money from people browsing your pages, the card won’t settle that trade-off, and only you can price it for your business.

The decisions the card leaves you with are concrete: which task, what an agent may see and change, who approves and who catches the failures, and whether you pilot now or watch with a trigger set. For years the question at a company’s digital door was whether the visitor was a person or a bot. There’s now a third kind of visitor, a bot carrying a person’s permission, and the rules for how much that permission is worth are still being written.