Your next customer may send an AI. Can your business serve it?

A hypothetical, not a case study: a customer asks their AI assistant to find insured movers for the 14th, within budget, and hold the best option. The agent tries three companies.

The first offers a contact form and a callback within a day. The second has a quote calculator, but booking requires an account and a phone call. The third returns a priced quote with two open slots, places a hold within the limits the customer approved and confirms it.

That doesn't mean the third company wins; it may still lose on price or reviews. But the customer delegated to avoid forms and calls, and only one company sent the agent back with a firm answer.

The gap comes down to three capabilities: receive a request as a clear intent, verify who authorized it and for what, and complete it in the systems that hold prices, availability and accounts.

What was announced. On 29 September, OpenAI introduced dots, agents that act for their user, with rules for when to act alone and when to ask first. OpenAI's examples are mostly about work, not shopping: a signal of direction, not proof of agents at your checkout.

On 1 October, Decagon, which builds customer-service AI agents, announced its Personal Agent Gateway. It flags likely personal agents in chat and voice, gives self-identified agents a dedicated channel with separate workflows, and limits each to permissions the business defines and the customer grants.

Decagon also introduced PACT (Personal Agent Consent & Trust), a protocol built on the open Agent2Agent (A2A) standard that adds delegated authorization based on OAuth 2.0, the standard behind “allow this app to access your account” screens. Decagon says the specification is available and still evolving. Neither announcement links to it or gives pricing, adoption figures or results, and neither points to an integration with dots. (I don't work for Decagon and haven't used the Gateway.)

My read. Decagon frames the problem well: the hard part isn't the conversation but knowing who is on the other end, what they may do and which policy applies. Blocking agents, it argues, risks losing customers and teaches agents to look more human.

Two caveats for a buyer. A protocol only helps if your customers' agents speak it, and PACT is one vendor's specification, shaped with unnamed partners. And a gateway is a front door: it can't create a quoting engine, a bookable calendar or a refund rule a machine can apply. Most of the value, and the work, sits behind it, whichever vendor you choose.

• Sales: quotes, availability, comparison and reservations. An agent shopping for someone favors the business that answers with a firm price and a real slot. If agents compare offers, being easy to compare may matter as much as being persuasive.
• Service: status checks, changes, cancellations and returns: rule-based requests customers rarely enjoy making, and good candidates for delegation if the rules are explicit.
• Operations: scheduling, holds, refunds and fulfillment sit behind both. A request that ends in “someone will call you” has moved the work, not removed it.
• Economics: less friction can mean more demand. Decagon expects people to contact businesses more often, and for more reasons, once an agent does the asking. That's opportunity and cost at once: a cheaper interaction doesn't mean a lower total bill if volume rises.

None of this means these journeys work end to end today, with Decagon or anyone else.

The trap is counting automated conversations; a conversation is not a business result. Measure the journey against your current channels, with integration, monitoring and human review in the cost:

On that last row: Decagon notes that exception policies assume human patience, while an agent may keep pressing, with new arguments, for a refund or waiver. If your margins quietly depend on customers giving up, model that before opening a channel.

The announcements contain no outcome numbers; your own baseline is the benchmark.

• Two identities. You need to know the customer and the agent acting for them. Decagon says most agents today use the same phone lines and chat windows as people. Some can sign in as the customer: dots can use saved passwords on supported websites without the model seeing them. Your systems then see the customer, with all the customer's permissions.
• Permissions per operation. Permission to view a booking is not permission to change it. Define scopes per action, let the customer grant them and enforce them where the action executes, not in a prompt.
• Systems behind the channel. Catalog, pricing, availability, CRM and booking systems need interfaces an agent can call with predictable results. If a person reads a form to produce a quote, no channel will make it instant.
• Records. Log who asked, on whose behalf, which permission was granted, what was executed and which policy applied. When a customer says “I never approved that,” this is your answer.
• Escalation in both directions. Your side may need a person; theirs may need its owner. Set stop conditions too, because two agents can loop indefinitely.

On protocols: A2A already covers authentication and authorization, including OAuth 2.0 and OpenID Connect, and leaves what each client may do to the implementation's own policies. PACT targets one slice: a person delegating specific permissions to their agent. Don't adopt a protocol because it's new; design scopes and records you could expose through whichever one your customers' agents use.

Not a transformation program: one journey, one pilot. Pick one with clear rules and real volume: rescheduling an appointment, starting a return, quoting a standard service. Before building anything, write down:

• Current process: steps, systems and who touches it.
• Allowed actions: what an agent may do, and which actions need the customer's explicit grant.
• Human intervention: where a person steps in, and how fast.
• Success criteria: agreed before launch.

Run it alongside the existing channel. Compare completion, cost per resolved request, errors (wrong action, customer or policy) and customer experience, including how often the customer had to step in. Measure in your own systems, not a vendor's dashboard. A good pilot ends in a decision: expand, fix or stop.

If a customer delegated this to their agent tomorrow, at which step would it get stuck with our company?

If the honest answer is “we don't know,” start there. It's the kind of work I do with teams: map one journey end to end, mark where an agent would stall, design the identity, permission and integration work the fix needs, and set up the evaluation that shows whether a pilot paid off. Vendor-neutral, one journey at a time. If you want a second read, write to me at n@nickcerutti.com with the journey you'd test first.