When customers send AI agents

Sierra and Meta are developing a way for personal agents to deal with businesses. The difficult part starts when an agent asks to change something.

Nikolay Zuykov · Agenticum · 15 October 2026

"Move my appointment to Thursday afternoon."

Imagine asking your AI assistant to arrange that with your utility company. You would expect it to find a slot, make the change and tell you when to be home. You probably wouldn't think about which system holds the booking or what happens if the connection drops halfway through.

The utility company has to.

On 6 October, Sierra announced Personal Agent Protocol, developed with Meta and partners including Shopify, Stripe and Walmart. It proposes a common way for a person's AI agent to interact with a business. The customer gives the agent permission; the business decides which actions it will accept. Sierra's announcement

An agent may understand the customer perfectly and still leave them waiting at home on the wrong day.

What the protocol actually does

Personal Agent Protocol, or Poppy, lets a company describe how agents can connect to it. The options include its website, APIs and its own conversational agent. It uses existing standards such as OAuth for authorisation, alongside OpenAPI and MCP for supported interfaces. Protocol introduction

The published specification is Draft 0.1. It describes discovery and authorised sessions across these channels. A company advertises its connection options in a file called poppy.json. Compatibility can still break as the draft changes. Draft specification

Payments, push notifications and attachments remain open topics on the roadmap. There is enough here to examine and experiment with, but the standard is still being worked out. Path to 1.0

If customers start service requests in the assistant they already use, the company will have to recognise that assistant's authority and give it a reliable route to the requested service.

The booking changed. The reply never arrived.

Take the appointment example. This is a hypothetical service design, not a deployment described by the protocol's authors.

The agent finds a Thursday slot. The customer approves it. The scheduling system moves the booking, but the connection drops before confirmation reaches the agent.

Now the company has one version of events and the agent has another. Sending the change again might create a duplicate request. Reporting a failure would also be wrong: the booking has moved.

The service needs a way to look up what happened to that request. If it succeeded, it should return the existing confirmation. If the result is still uncertain, it should say so and provide a recovery path. The language model should never have to invent an answer to fill that gap.

This is the kind of case we would put in a pilot early. The team needs to agree how the service recovers and who takes over if the result cannot be retrieved.

The rest of the journey needs equally explicit rules:

Permission has to survive the conversation

"Find me another slot" gives an agent a different job from "Book it, even if there's a fee." A business needs to preserve that distinction when a conversation becomes a system action.

For each action, write down whose approval is required and what it covers. A read permission should not quietly become permission to cancel a visit. A permission that has expired should fail at the point of execution, even if the agent started the conversation while it was valid.

Enforce those rules in the service that changes the booking. A prompt asking the model to be careful cannot replace an account check. Keeping the rules there also makes changing models less disruptive: a new model still has to use the same controlled service.

Then consider the support colleague who receives a failed request. They need to see what the customer wanted and what has already happened. Otherwise they ask the customer to explain everything again, then spend several minutes discovering that the booking was changed after all.

Bring that colleague into the design review. They can tell you which missing details turn a handover into another complaint.

Count the work that comes back

A pilot can look successful if its report counts completed conversations and ignores the work they create elsewhere. The appointment may be wrong. The customer may call to check. Someone in operations may have to remove a duplicate.

Measure the result in the scheduling system and the confirmation the customer receives. Track how often staff have to intervene, how often customers repeat a request and how long an uncertain booking takes to resolve. Keep failed and abandoned attempts in the denominator.

Test the uncomfortable cases deliberately: an expired permission, a slot that disappears before booking, a customer who changes their mind, a fee the agent wasn't authorised to accept. Include the lost-confirmation case described above.

For the economics, use cost per correctly completed task. Include the human time spent fixing mistakes. A cheaper model that generates more recovery work can make the service more expensive; a costlier model has to earn its place through better results. Run both against the same cases before deciding.

A useful first assignment

Ask the service owner and an integration engineer to work through one frequent customer request together. Pick one with a result they can verify in the underlying system. Give them the normal case, then ask what happens when the last reply never arrives.

That conversation should produce concrete decisions: where permission is checked, how a repeated request is handled, and who resolves a result that cannot be confirmed. Use those decisions to assess the protocol and the agent products you are considering.

There is no need to commit the whole customer experience to a draft standard. Build a small trial around an existing service, check what the participating agents actually support, and keep the connection code separate from the booking rules.

The first deliverable could be modest: one appointment changed correctly, with a confirmation that still holds up after a dropped connection. Then repeat it with a different agent and check that the same booking rules still hold.

Sources checked on 15 October 2026. The appointment example is illustrative; the recommendations are our analysis at Agenticum.