Would you trust an assistant to change an important booking if you could not tell whether the change happened?
A person asks an assistant to return a jacket. The assistant reads the retailer's policy, finds the order and starts the return. A human might do the same steps in a browser. The difference is that the retailer now needs to know which customer authorized the assistant, what it may see, which actions need confirmation and how to describe the result.
In October 2026, Sierra and its partners introduced the Personal Agent Protocol, also called Poppy. Its draft specification, updated on 9 October, explores how personal agents can identify themselves, obtain limited customer permission and interact through a company's website, API or own agent. It is a proposal under development, not a requirement every business already follows. The proposed approach makes several familiar customer-service questions more concrete.
Reading a policy is different from changing an order
A visitor should be able to ask about a returns policy without handing over account credentials. To see an order, the business needs to establish who the customer is and what the assistant has been authorized to access. To start a return or change a booking, it may need a narrower permission or an explicit confirmation.
The customer's approval should refer to a clear action and its terms. A general instruction to “help me” should not quietly permit changing payment details. The business sets its own boundaries; the customer decides what access to grant within them. Sierra's draft specification describes one possible technical design for that exchange.
Started and completed are different states
Suppose the assistant submits a change and the connection times out. Was the action accepted? Would a retry repeat it? Should the customer expect a confirmation? Uncertainty at this point can create duplicate requests and conflicting explanations. Sierra's optional operations extension explores proposed actions, confirmation and a trackable result across channels. The details can change as the draft evolves; the need for an accurate account of an action is already here.
A business should distinguish a suggestion, a request awaiting permission, a submitted action, a completed change and an unresolved outcome. The assistant should not tell someone their appointment changed when the business has only offered an available time.
A person may still need to take over
Not every request fits the normal route. A jacket may be outside the return period; a booking may have special terms; the customer may disagree with the available alternative. A staff member who takes over needs to know the original request, what the assistant checked, what the customer approved and what remains open.
Many teams already struggle to carry that context from a form to an inbox and then to another colleague. An agent does not remove the handoff problem. It makes the consequences of a weak handoff more visible.
What a small business can test now
Choose one recurring task: a return, appointment change or service enquiry. Walk it from the first question to a confirmed result using fictional records. Mark what can be answered publicly, when identity becomes necessary, where a customer must approve an action, what evidence confirms completion and how a person would intervene.
Then add a failure. The assigned colleague is away, the customer changes their mind, or a system returns no clear response. Can the team tell what happened without guessing? That test is useful whether or not the company ever adopts Poppy.
I build workflows that preserve context and make the next action visible. The ClientFlow prototype explores related intake and handoff questions with fictional data. It does not claim to support personal-agent transactions today.
Work with Massoda
If your customer journey breaks when a request crosses from a person to a system or between teams, email hello@massoda.me. We can begin by mapping one task before choosing an integration.