Decagon Personal Agent Gateway: how it handles AI agents that call your support

What Decagon actually launched

Decagon announced the gateway at its Dialogues 2026 event as one of four releases, next to Decagon Voice 3, Agent Modules and Duet Apprentice.

The launch post, written by co-founders Jesse Zhang and Ashwin Sreenivas, opens with the reason: in a single month, Meta launched Muse, OpenAI introduced dots, and Instinct started placing phone calls for its users.

Those are personal agents. They work for a consumer, not for a business, and they "book, buy, cancel, and negotiate" on their owner's behalf. When they hit a support queue, they usually land on the brand's own AI agent for customer service. So now there's an agent on both ends of the conversation. And it's already happening on real phone lines:

"This week, Muse called customer service on my behalf. It navigated the phone tree, waited on hold, spoke with a human rep, and resolved the issue (worked great!)."

Ravid Shwartz Ziv, X

The gateway is two features and a protocol:

I build integrations for a living at eesel, and my first read was that this is mostly an authorization product wearing a detection costume. That's a compliment. Detection gets the headlines, but the scopes are what you'd actually ship.

Why personal agents break support policies

Here's the line from Decagon's post I keep coming back to. A person denied a refund "might ask once more and let it go." A personal agent "might ask for a refund once, or keep trying different approaches to maximize the concession."

That's the whole problem in two sentences. Most refund and exception policies quietly lean on human patience. The customer who'd need four tries to get an exception usually stops at two. An agent doesn't get tired, doesn't feel awkward and doesn't have anywhere else to be. The most-shared take on this on X put the economics bluntly:

"AI agents reduce the cost of complaints/requests to ~ zero. Anything free is consumed at much higher rates, so we should expect the total volume of this category to explode."

The Mind Scourge, X

I see the same pattern from the other side on the eesel queues I work with. One support admin on eesel spent a session teaching eesel's Zendesk agent a single rule, which they put better than I could:

"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."

A digital-media support admin encoding a "troubleshoot before you cancel" policy into a Zendesk AI agent

That rule works on a human because a human accepts troubleshooting. A personal agent instructed to "get me a refund" will try to route around it. If your AI support agent can be argued out of a rule on the fifth attempt, it never really had the rule. That's why AI for refund requests lives or dies on what the agent is allowed to do, not on how nicely it says no.

There's a second problem Decagon calls out: permission. "Permission to check a balance doesn't necessarily mean permission to move money." Today, if someone's agent calls in with the right account details, most support stacks can't tell what the customer actually approved.

How the Personal Agent Gateway works

Decagon frames the design around four things an enterprise needs to get right: identification, access, authorization and resolution. Here's how each one maps to the product.

Identification: detection plus self-identification

Most agents today call in or open a chat like anyone else. Decagon says detection combines signals from the business, like device fingerprints and account history, with signals from the support platform, like conversational patterns and request cadence. The flag works in live chat and voice. What happens next is the business's call.

The nuance worth noticing: Decagon doesn't pitch detection as the main gate. It says detection "works best alongside an easy way for agents to identify themselves upfront," so it only has to catch the ones that don't. Detection is the fallback. The channel is the plan. My read: it's the same logic that pushed checkout toward an agentic commerce protocol. A front door for agents scales better than guessing who's a bot.

Access: a channel just for agents

Agents that identify themselves get the personal agent channel. It sits next to chat, email and voice, with separate AOPs. AOPs are Decagon's workflows for its AI agent, and I've covered them in more depth in the Decagon review.

The practical upshot is that the same request can follow different logic depending on who's asking. A refund request from a person can go one way; from an agent, another. Less sensitive requests can reuse existing workflows without extra setup, which matters, because nobody wants to maintain two copies of every policy. Decagon's other point here is easy to miss: one channel for every agent provider means you're not building a separate integration for Muse, another for dots and another for Instinct.

Authorization: scopes inside the AOPs

This is the part I'd read twice. Decagon puts permissions inside the AOPs: a business defines the scopes an agent can request and marks which sections need each one. Without the scope, "those sections are never exposed to the agent." It's the OAuth model you already know from connecting an app to your Google account, applied to a support conversation. If you've set up Zendesk API scopes, the shape will feel familiar.

Decagon's own example is an airline:

The traveler grants viewing but not rebooking. The airline's agent shares earlier options but can't make the change, so the personal agent goes back to its owner for the missing permission. Decagon also says the grant "creates a record of what the customer authorized," so the business can prove it later. For a support lead who's ever had to untangle a disputed change, that audit trail is the real feature.

It also answers the worry consumers have from their side. On Reddit, a Muse user asked how this could work when their insurer and telecom always demand personal details first:

"...for that to all I have to hand those info (social, address, DOB, etc.) directly into Muse memory as plain text without a secure credential layer, or the customer service might just hand off knowing it's an AI calling?"

u/maraluke, Reddit

Scoped, customer-granted permissions are the "secure credential layer" that user is asking for.

Resolution: stopping two agents from looping

"Two agents can loop forever if neither is built to stop." Decagon's answer is that the business agent holds its position on policy while staying helpful, and escalation runs both ways: the business agent may need a human, and the personal agent may need its owner. If you've tuned AI escalation rules before, this is the same muscle with a second exit added. It also changes how you measure things: containment and escalation quality now include handing a request back to someone else's agent.

What PACT adds on top of A2A

PACT is short for Personal Agent Consent & Trust. Per Decagon, it "builds on the Agent2Agent protocol," which handles how agents find each other and exchange messages, and adds "delegated authorization built on OAuth 2.0." In plain words: A2A gets the two agents talking, and PACT lets the personal agent prove whose customer it is and what it may do. It's a different job from MCP for customer support, which connects an AI to tools rather than to another agent.

That split makes sense once you read the A2A spec. Agents advertise themselves with an agent card at /.well-known/agent-card.json, but the A2A specification leaves authorization implementation-specific. Something has to fill that gap for consumer-to-business requests, and PACT is Decagon's bid. A2A itself has real backing: it became a Growth Stage project at the Agentic AI Foundation on August 27, 2026, with over 150 organizations behind it.

Two things to keep straight before you go hunting for docs:

• PACT the name is taken twice. Cloudflare announced a different PACT, Private Access Control Tokens, with Mozilla, Google, Microsoft and Shopify in June 2026. It's about proving personhood on the web, not support consent.
• The spec isn't easy to find. Decagon's Dialogues recap says "the specification is available today," but as of October 6 neither launch post links to it and I couldn't find a public copy. So I can't tell you field names, endpoints or how grant records are stored. Decagon says it's "working with personal agent providers" to shape it.

Decagon isn't alone in this lane. On September 30, Mastercard announced a score for how likely a payment was started by an AI agent, in US testing. That's detection at the payment layer. Decagon is the first I've seen aim the same idea at the support conversation itself. Rivals like Sierra haven't announced anything comparable as of this writing, which makes this a real point of difference in the Decagon vs Sierra comparison.

What isn't known yet

Decagon is clear on the design and quiet on the details a buyer would ask about. Here's the honest state of play as of October 6, 2026:

None of that is unusual for a launch-day feature from an enterprise vendor, and the Decagon pricing story has always been sales-led. But it does mean the gateway is a direction, not a product you can size today, and it feeds straight into the bigger is Decagon worth it question. The self-identifying channel in particular only pays off once the agent makers adopt the protocol, and none have publicly said they will.

What people are saying

Public reaction to the gateway itself is thin so far, which makes sense five days after launch. The bigger debate it's stepping into is loud, though. On Hacker News, the launch thread for OpenAI dots turned into an argument about exactly this:

"All this outsourcing of human interaction to agents is going to get locked down. Customer service relies on people not overabusing it, and that trust is getting abused by agents."

kelseydh, Hacker News

And the reply that gets at why consumers will send agents anyway:

"The solution for both sides is for the companies to implement support bots that have more power to address my problem than the humans they replaced were ever given. I have a feeling it's not going to work out that way, though."

CamperBob2, Hacker News

Blocking is the other instinct, and it has a cost. As Ryan Sarver put it after Amazon blocked Muse from its retail site, "Nobody asked the person whose agent stopped working" (Ryan Sarver, X).

Those comments together are the gateway's whole design brief. Businesses need to stop abuse, customers want their agent to actually get things done, and scoped permissions are the only version where both sides get something. If the business agent can say yes to more, safely, the customer's agent has less reason to grind.

How to prepare your support team, with or without Decagon

Most support teams reading this aren't on Decagon, and won't be for a 2026 budget cycle. The good news: the hard part of the gateway is a permissions exercise you can do on any stack. Agents like Instinct and Meta Muse will reach your queue through the same email, chat and phone lines people use, whether you've bought anything or not. If you run support on WhatsApp or Messenger, Meta Muse for customer support covers what Meta's own business tools do.

Pick a request type below to see how I'd gate it.

Here's the short version as a checklist:

1. Inventory your actions. List every action in your AI customer service workflow, and sort each into read, reversible write, money-moving or account control. Most teams have never written this down.
2. Gate by tier, not by channel. A refund is a refund whether it came from a person, a bot or a phone call. Put approvals on the money-moving tier first. The Zendesk advanced AI actions and Gorgias AI actions guides show what's configurable natively.
3. Write policies that survive repetition. Read each exception rule and ask: would this hold on the fifth ask? If the honest answer is "it depends who's asking," tighten it.
4. Give escalation two exits. Your AI should hand off to a person cleanly, and say plainly what it needs from the customer when an agent lacks permission. See best practices for human handoff for the person side.
5. Test against past tickets before go-live. Replay real refund and cancellation tickets and check where your AI bends. That's cheaper than finding out from an agent that won't stop.

The fourth point has a scar attached for me. I once watched an autonomous drafting setup break its own escalation path at a digital media customer: the escalation email got auto-closed, so no person ever saw it. Nothing got escalated, and nobody knew. Two agents talking to each other will find gaps like that faster than any customer ever has, which is why every eesel rollout now gets simulated on historical tickets first.

Where eesel fits

I'll be straight about the limits first. eesel doesn't detect personal agents, and it doesn't implement Agent2Agent or PACT. If you need an enterprise agent-to-agent channel with customer-granted scopes today, Decagon is the vendor building it, and the Decagon alternatives roundup covers who else is close.

What eesel does is the permission layer underneath, on the helpdesk you already run. The AI helpdesk teammate joins Zendesk, Freshdesk or Gorgias like a new hire, next to or instead of native Zendesk AI. Every action it can take, from adding a tag to issuing a refund, is set to Auto, Needs approval or Disabled, grouped into Read and Write, per eesel's actions docs.

That's the same read-versus-write split Decagon's scopes enforce, just aimed at your own AI instead of the customer's. So whoever is on the other end of a ticket, a person or their agent, you can let eesel look up the order on its own and still make it wait for a human before money moves. You can set it in plain words, like "look things up on your own, but ask me before any refund," and approve held actions from the dashboard, Slack or the eesel CLI with eesel approvals.

Try eesel

If personal agents are about to start asking your queue for refunds, the first job is deciding what your own AI is allowed to say yes to. eesel's AI helpdesk teammate plugs into Zendesk, Freshdesk or Gorgias, learns from your past tickets and help center, and keeps refunds and cancellations behind an approval until you've seen it hold the line. You can run it on your past tickets in a simulation before it touches a customer.

The free plan includes 100 credits and every integration, and paid plans start at $299 a month for 500 credits on the eesel pricing page. Try eesel on your own queue.