A customer may soon arrive at an online store without opening the store themselves.

Their personal AI agent could check whether an item is available, read the returns policy, sign in with permission, change an order or eventually complete a purchase on their behalf.

Meta and Sierra are now working on a standard for that kind of interaction.

The Personal Agent Protocol, announced on 6 October, is being developed with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart.

The specification is not finished. Sierra says version 0.1 is due later in October.

That makes this a bad time to write an implementation guide.

It is a good time for merchants to work out what they would actually allow an outside agent to do.

What Personal Agent Protocol is trying to solve

Personal agents can already use websites much like people do.

They can load pages, fill out forms, open chat windows or call support lines. That works for some tasks, but it is slow and unreliable when the agent has to imitate a human user at every step.

Personal Agent Protocol is intended to give businesses a more direct way to recognise and work with those agents.

Sierra says the standard is being designed around three parties:

  • the customer;
  • the customer’s personal agent;
  • the business the agent is trying to deal with.

The customer decides what access the agent receives.

The business decides which actions it will allow.

The agent gets a consistent way to connect.

That sounds simple, but it changes several parts of the merchant experience at once.

A visit could begin before the customer signs in

One useful detail in Sierra’s description is that an agent may start as a guest.

That could be enough for tasks such as:

  • checking whether an item is in stock;
  • reading a returns policy;
  • finding delivery information;
  • comparing public product details.

If the task later needs account access, the customer can authenticate.

Sierra says the customer may sign in on the company’s own page or use credentials already established with the personal agent.

The customer can then decide whether the agent receives read-only or write access.

That distinction will matter.

Reading an order status is very different from cancelling the order.

Checking a loyalty balance is different from redeeming it.

A merchant that has never clearly separated those actions in its own systems may find agent access difficult to control.

OAuth sits at the centre of the proposed model

Sierra says Personal Agent Protocol sessions are built around OAuth, the widely used authorisation standard.

The aim is to let a customer grant an agent access without simply handing over account credentials.

A session can also continue across different routes.

The same interaction could start on a public website, continue after sign-in and then use an API or the company’s own agent to finish the job.

Sierra currently describes three ways a personal agent could work with a business:

  1. through the company’s normal website;
  2. through APIs using standards such as MCP or OpenAPI;
  3. through an agent operated by the company.

The merchant chooses what it exposes.

That is why there is useful preparation work to do even before version 0.1 is published.

Start by listing what an agent should be allowed to do

Most businesses already have permissions scattered across websites, apps, APIs and customer-service systems.

Personal agents make those inconsistencies harder to ignore.

Create a simple task list.

For an ecommerce business it might look like this:

Customer task Guest Read access Write access
Check stock Yes Yes No
Read returns policy Yes Yes No
View order status No Yes No
Change delivery address No No Yes
Cancel order No No Yes
Start return No No Yes
View loyalty balance No Yes No
Redeem credit No No Yes

This table does not depend on the final protocol specification.

It answers a more basic business question first.

Which actions should another system ever be able to perform for a customer?

Clean up product and policy information

An agent cannot reliably help a customer if the merchant’s own information is contradictory.

Check the public information most likely to be used before authentication:

  • product availability;
  • price;
  • delivery estimates;
  • return windows;
  • cancellation rules;
  • warranty terms;
  • store locations;
  • service availability.

If the returns page says 30 days while the help centre says 14, an agent has no clean answer to give.

The same applies to product feeds and inventory.

Agent commerce will make basic data quality more visible, not less important.

For European merchants selling across several countries, run the check by market.

Delivery, returns, VAT wording and customer rights can vary.

Do not assume one English policy page represents every market correctly.

Audit the APIs you already expose

Many merchants already have APIs that could eventually support agent activity.

The problem is that those APIs may have been built for internal apps or trusted partners rather than an outside agent acting for a consumer.

Inventory the endpoints that touch customer actions.

Record:

  • what the endpoint does;
  • whether it reads or changes data;
  • how authentication works;
  • which customer records it can reach;
  • whether rate limits exist;
  • whether the action is logged;
  • whether it can be reversed;
  • what happens when it fails.

Sierra specifically names MCP and OpenAPI as standards that could be used for API connections.

That does not mean every MCP server or OpenAPI endpoint will automatically work with Personal Agent Protocol.

The v0.1 specification has not been published yet.

Treat existing API readiness as preparation, not compatibility.

Logging will matter as much as access

If an agent changes an order, the business should be able to tell what happened.

A useful transaction record should distinguish between:

  • the customer;
  • the customer’s authorised agent;
  • the merchant system that accepted the action;
  • the action performed;
  • the permission granted;
  • the time;
  • the result.

This becomes especially important when something goes wrong.

A customer may say they asked their agent to check a booking, not cancel it.

A merchant may need to know whether the agent was given write access at the time.

The protocol is still being designed, so we do not yet know what the final audit fields will look like.

Businesses can still review whether their current systems produce enough evidence to reconstruct an automated action.

Do not confuse the protocol with a new checkout standard

Shopify and Stripe are participating in the project, and Sierra says future payment extensions could allow an agent to complete purchases without exposing credit card information.

That is important.

It is also future-looking.

Personal Agent Protocol v0.1 is not public yet, and the announcement does not establish a universal agent checkout system.

The same caution applies to Europe.

The project is an open standard intended for broad implementation. Sierra has not announced a special European launch date or a completed European merchant rollout.

Any use involving European customers would still have to fit the merchant’s existing privacy, security, consumer-protection and payment obligations.

The protocol does not replace those requirements.

Seven things merchants can do before v0.1 arrives

There is no reason to wait for the specification to do basic preparation.

1. Map customer tasks

List what people currently do through the website, app and support team.

2. Mark every task read or write

Treat account viewing and account changes differently.

3. Identify guest actions

Decide what an unauthenticated agent could safely access.

4. Check public information

Remove contradictions in product, stock, delivery and policy data.

5. Inventory APIs

Record which systems could eventually support agent requests.

6. Review authorisation and logging

Make sure sensitive actions require clear permission and leave a usable audit trail.

7. Wait for the actual specification before building to it

Sierra says v0.1 is due later in October.

Until then, do not turn an announcement into an implementation standard.

What to watch when the specification lands

The first version should answer several questions that are still open.

NEMO will look for:

  • how a website advertises support for the protocol;
  • the exact discovery method;
  • permission scopes;
  • authentication flows;
  • merchant controls;
  • logging requirements;
  • error handling;
  • payment extensions;
  • reference implementation details;
  • how MCP and OpenAPI connections are described.

European merchants should also watch for real implementation examples from Shopify, Stripe or other participating companies.

A partner name is not the same as a live merchant feature.

The bigger change is who shows up at the storefront

Most ecommerce sites still assume the visitor is a person using a browser.

Personal agents challenge that assumption.

A customer may send software to research, compare, ask questions and eventually act.

The merchant then needs to know who that agent represents, what the customer allowed it to do and which actions the business is willing to accept.

Personal Agent Protocol is one attempt to standardise that exchange.

It is too early to call it the standard for agentic commerce.

But the merchant preparation work is already clear.

Fix the underlying permissions, product information, APIs and logs now.

When version 0.1 arrives, the technical questions will be much easier to answer.

For related developments, follow NEMO’s Ecommerce coverage and Search & AI coverage.

Primary source

Sierra, “Introducing Personal Agent Protocol”, 6 October 2026: https://sierra.ai/blog/introducing-personal-agent-protocol