A Customer's AI Coworker Is Coming to Your Business. What Should It Be Allowed to Do?

A Customer's AI Coworker Will Soon Be at Your Digital Front Door

On October 6, 2026, Sierra announced the Personal Agent Protocol, an open standard it is developing with Meta and partners including Shopify, Stripe, and Walmart. The proposal addresses a situation that already exists: a customer's AI coworker may visit your website, ask about a product, or try to change an order on the customer's behalf. Your business may not know who—or what—is making the request.

The proposed answer is a recognizable session that starts with public, guest-level access and can progress, with the customer's authorization, to read-only or write access. The company decides whether the interaction happens through its website, an API, or its own customer-facing AI. The first specification is planned for later in October; the announcement is not evidence that these controls are already deployed everywhere.

For a small business, the important question is not whether to adopt this particular protocol today. It is whether your customer service operation knows the difference between answering a public question, revealing account information, and making a change with consequences. Those are three different jobs. If they all flow through one chat box with the same permissions, the arrival of customer-directed AI will expose a boundary you never had to draw clearly before.

Think of the customer who sends an AI coworker to find out whether a replacement part is available. That is a useful new route into your business. Now imagine the same coworker asks to redirect an order to a different address. A helpful interface cannot treat those requests as equivalent simply because they arrive in one conversation. The business needs an operating model for the visitor on the other side of the screen.

Public Information, Private Records, and Changes Are Different Lanes

The Sierra proposal describes a progression: a guest session for matters such as availability or a returns policy, followed by customer-authorized account access. It uses OAuth for the session, and says the customer chooses read-only or write access while the business chooses the surfaces it exposes. This is a useful framework for designing your own boundaries even if you never implement the eventual specification.

Lane one: answer without knowing who is asking

Opening hours, service areas, standard lead times, public pricing, and published policies should be available without access to a customer account. Treat a customer-directed AI coworker like any other visitor at this stage. Make the answer current, cite the policy version where necessary, and distinguish a general estimate from a promise about a particular order.

A common failure is to hide basic information behind a login or an unrestricted support assistant. That forces either unnecessary disclosure or an answer improvised from stale knowledge. Publish the canonical public answer in a form both people and software can find. An AI coworker should not need a privileged connection to learn that your shop is closed on Sunday.

Lane two: read only what this customer may see

Order status, a service appointment, an invoice, or a warranty record belongs to a named customer relationship. Authenticate the customer, then scope the session to that customer's records and the specific task. An authorized read does not authorize a change. It also does not authorize a full export of every record merely because the caller can phrase a broad request.

If your business serves families, teams, or multiple companies under one login, the scope has to be narrower than the account name. A property manager may have permission to see one building's work orders but not the landlord's payment details. A buyer may see shipping status but not change the billing address. The boundary should come from your underlying system of record, not from a sentence instructing an AI to be careful.

Lane three: prepare a change, then commit it deliberately

A write request can create costs, legal commitments, or unhappy customers. Changing a delivery address, canceling an appointment, issuing a refund, or accepting a revised quote requires more than proof that a session exists. Identify the exact record, the exact action, and the person empowered to authorize it. Where risk warrants it, stage a proposed change for review before committing it.

The announcement lists more detailed permissions and payments as future extensions. Do not read that as a promise that a guest/read/write label already covers every edge case. A single blanket “write” grant is too coarse for many real businesses. An order update and a payment are not interchangeable; a proposed protocol does not replace your existing verification, fraud, or financial controls.

The principle is least authority by task. Give the visiting coworker enough access to complete the customer's current request, not an open-ended role inside your company. OAuth's current security best practice explicitly calls for restricting tokens to the minimum needed resources and actions; a business still has to enforce those restrictions on every request. If a task crosses a boundary, stop and obtain a new authorization rather than silently carrying old permission forward.

What a Good Customer-AI Handoff Looks Like

Picture a local appliance-repair company. A customer's AI coworker asks whether the company services a specific refrigerator model, checks the earliest appointment, and then asks to move an existing visit. The first question is public. The second may be public if it is a generic opening; the customer's own reservation is private. Moving that reservation is a change.

What bad looks like: the company's support assistant sees a plausible account number in a message, returns the customer's address, and changes tomorrow's booking to Friday. It assumes that conversational fluency proves authority. The owner discovers the problem only when the technician arrives at the wrong time. There is no durable record of which identity requested the change or what the customer actually approved.

What good looks like: the public channel answers the service-model question and offers available windows without disclosing anyone's booking. To inspect the reservation, the customer completes the company's account sign-in. The system issues a task-scoped read session; the visitor can see the existing time but not unrelated customer records. To move the booking, the visitor submits a specific proposed time and receives a summary of the consequences, including any fee or cutoff. The authorized customer confirms through the company's own channel. The system writes the change once, returns a receipt, and records the original request, authorization, change, and final outcome.

That process is not a claim that every reschedule must require a person at the company to click a button. Low-risk changes can be automatically committed after a properly authenticated customer confirmation. High-risk exceptions—same-day cancellations with fees, a conflicting authorization, a request to change someone else's booking—go to a human with the context intact. The seam is designed around the decision's consequence, not around whether the requester is human or software.

This is also where the internal AI coworker matters. A customer-directed coworker is acting for the customer; your own Teammate is acting within your business's assigned role. Those are not the same identity and should not inherit one another's permissions. Your service Teammate might assemble a decision packet for an employee: original appointment, proposed change, policy, customer authorization, and next available slot. It should not treat the external coworker's confident explanation as a verified instruction.

The distinction resembles the difference between an AI connector and a coworker with an operating role. A connection gets the visitor to the door. Ownership, scope, memory, and a recoverable handoff determine whether the interaction is safe once it gets inside. It also follows the same rule as human-in-the-loop execution: put the human at the genuine judgment point, with enough evidence to decide, rather than asking someone to approve an opaque result.

A Seven-Step Access Plan for Small Businesses

You do not need to wait for a standard's first draft to improve your customer-facing boundary. Start with the requests you already receive by email, phone, web chat, and self-service. An AI coworker is another caller, not a reason to discard the controls that protect the customer today.

1. Inventory customer tasks by consequence. List your ten most common requests. Mark each as public information, private account read, reversible change, or high-impact change. An availability question, an order lookup, a booking move, and a refund should land in different rows. This simple classification reveals where a generic support integration has quietly been granted too much authority.

2. Name the system of record. For each private fact or change, record which application owns the truth. A support-chat transcript is not the authoritative address on an order; a remembered answer is not the current cancellation policy. Route reads and writes through the appropriate source, and decide what happens if that source is unavailable. “I can't verify that right now” is a better answer than an invented status.

3. Separate visitor identity from customer authority. You may know that a request comes from a particular AI product without knowing whether this customer authorized this task. Conversely, a customer might be authenticated while the visiting software is unidentified. Require both checks where the action calls for them. Use short-lived, task-scoped authorization and avoid sharing a customer's password or a staff service account with a visitor.

4. Limit the accessible data. Expose only fields needed to answer the request. Mask sensitive details when a yes/no or status answer will do. Check multi-tenant and shared-account rules explicitly, especially if one operator manages records for many clients. Never let a query for one customer's booking become a search across your entire customer base.

5. Design the write boundary. Decide which actions are self-service, which require explicit customer confirmation, and which require a named staff member's judgment. Preserve existing return, payment, and identity checks. For irreversible actions, generate a preview with the record, old value, proposed new value, fees, and time limits before commitment. A generic “the customer authorized writes” is not a decision record.

6. Make retries and disputes recoverable. Software may repeat a request after a timeout. Give change requests an idempotency key or equivalent duplicate guard so one attempted refund cannot become two. Keep an audit trail that joins the initiating session, customer authorization, proposed action, actual system write, and notification. Define who can reverse an error and how the customer will reach them.

7. Run a boundary test with realistic requests. Simulate a visitor that asks for opening hours, reads its own appointment, requests another customer's appointment, changes a delivery address, and retries a confirmed change. Check that the public answer works, the cross-account read fails, the write stops at the correct authorization point, and the repeat does not duplicate the change. Re-run the test whenever you add a new channel or integration.

A practical first week might end with no new API at all: a cleaner public policy page, a narrower account lookup, and a documented escalation path for order changes. That is progress. The protocol announcement makes the coming interaction model visible, but the actual value lies in making your existing decisions explicit. For a business that already serves customers through multiple channels, that work also improves human support.

The longer-term opportunity is a respectful conversation between two sides of a transaction: the customer's AI coworker carrying the customer's intent, and your business systems carrying your policies and commitments. Neither side should have to pretend the other is a person. Both sides need a way to identify the task, constrain access, record what happened, and ask for human judgment when the seam appears. That is trust architecture expressed as customer service, not as a vague promise that software will behave.

FAQ

Q: What is the Personal Agent Protocol?

A: It is an open standard Sierra and Meta announced on October 6, 2026, with partners, for interactions between customer-directed AI and businesses. The proposal describes discovery, OAuth-based sessions, and guest, read-only, and write access. Its first specification was planned for later in October at the time of the announcement; the proposal should not be mistaken for a universally deployed standard.

Q: Does my small business have to implement a new protocol now?

A: No. Start by separating public answers, customer-account reads, and consequential writes in the channels you already operate. Review any eventual specification and implementation against your systems, legal obligations, and customers' actual needs before adopting it.

Q: Is identifying an AI coworker enough to let it change an order?

A: No. Identification tells you what is calling; authorization tells you what the customer permitted it to do. The business still has to enforce record-level scope, validate the requested action, and apply its ordinary rules for fees, fraud, and confirmation.

Q: What if a customer's AI coworker asks to see someone else's data?

A: Deny the read at the data-access layer, not only in a conversational instruction. Log the attempt without leaking the other person's details, and offer a legitimate route to access if the requester has an appropriate delegated relationship.

Q: Where should a human make the decision?

A: Put a named person at the point where the request needs judgment: an exception to policy, an ambiguous identity, a disputed charge, or a change with material consequences. Provide the original request, source records, proposed action, and authorization so the reviewer can decide without reconstructing the conversation.

Associates AI provides managed OpenClaw hosting for businesses that want their own persistent AI coworkers, with defined roles, governed access, and clear human handoffs, without running the servers themselves.