The A2B service layer: Why enterprises need one governed interface for personal agents

On September 8, Meta launched Muse, a personal AI agent that acts on a user's behalf. It books flights through Duffel, reserves tables through OpenTable, buys tickets through Ticketmaster, and manages email and calendars. A week later, Meta expanded a beta that lets Muse place outbound calls to US businesses. Ten days after launch, it surpassed ChatGPT as the top free app in the US App Store.

Most coverage treats Muse as a consumer story: a personal AI assistant that can handle tasks for you. For enterprises, the more important question is what happens on the other end. When a customer's agent contacts a business, the business is no longer serving a person directly. It's serving software acting for one, and that software can reach out faster, more often, and through more channels than any customer would.

We call this agent-to-business communication, or A2B. Personal agents can reach a business in two ways. The first is through interfaces built for people: phone lines, chat, and websites. The second is through interfaces built for software: application programming interfaces (APIs), which let one system request an action from another directly, and agent protocols like the Model Context Protocol (MCP), the standard that lets an AI agent connect to a business's CRM, booking engine, or ticketing system. Few businesses expose that second kind to outside agents today, which is why so much early A2B traffic will come through the first.

Supporting Muse is only the beginning. Enterprises will need to serve every agent that follows it, without building a separate connection for each one. The solution is an A2B service layer: one governed interface that receives requests from any agent, through any channel, and applies the same rules to all of them.

Customer effort has been hiding demand

A surprising amount of customer demand never reaches a contact center.

Someone starts a return, can't find the order number, and gives up. A traveler decides changing a seat isn't worth another trip through the airline app. Another customer lets a questionable charge slide because disputing it would eat an afternoon. Companies read that silence as low demand, when in reality it's just been suppressed by the effort it takes to ask for help.

Another portion gets handled through self-service. Customers change bookings in apps, track orders in portals, and find answers in help centers. 

Personal agents change both. The customer using them simply states a goal (“change my booking” or “find out why I was charged twice”) and the agent achieves the goal via whatever channel makes the most sense. Tasks that used to end in an app can arrive as a call, chat, or email, and requests that used to be abandoned start showing up.

Agents also make more contacts per goal, because asking costs them almost nothing. Where a person might check one rebooking option and settle, an agent can compare every alternative, retry when a request fails, and switch channels when one stalls. Each of those steps is a separate contact for the business, even though the customer asked only once.

Multiply that across hundreds of millions of personal agents, and a business’s contact volume could grow much faster than its customer base. A contact center staffed for human demand can't hire its way out of that growth.

Agentic Erlang: capacity planning when customers bring software

When customer effort drops, more intent turns into traffic. That surge can exhaust concurrent call capacity, hit model or API rate limits, and flood integrations and back-office systems with more requests than they were built to handle. Capacity planning for A2B has to cover the software, not just the people.

Most contact centers still plan voice capacity with Erlang models, developed more than a century ago to size telephone exchanges. Erlang B estimates how many lines or concurrent sessions you need to keep blocked calls below a target. Erlang C estimates how many agents you need to keep wait times below a target. Both depend on two inputs: how many calls arrive and how long each takes. When AI agents answer the phone, Erlang B matters more, because the limit shifts from headcount to concurrent capacity.

The models still apply to A2B, but agent callers break their assumptions. Erlang math expects random, independent arrivals, callers who hang up when they lose patience, and familiar handle times. Instead, one task fans out into several simultaneous contacts, agents never hang up, and retries add contacts even when each one is shorter.

A simple worked example shows how fast this adds up: 

Baseline. A contact center takes 1,000 calls in its peak hour, one per customer task, with a 4-minute average handle time. That's about 67 Erlangs of traffic. At a 1% blocking target, Erlang B calls for 82 concurrent lines.

With A2B. Now assume 10% of those tasks (100) shift to personal agents, and lower effort surfaces 50 tasks customers would previously have abandoned. Each agent-driven task averages 2.5 contacts, including retries and parallel attempts, at 3 minutes each.

• Customer tasks: 1,000 to 1,050 (+5%)

• Contacts: 1,000 to 1,275 (+28%)

• Traffic: 67 to 79 Erlangs

• Lines needed at 1% blocking: 82 to 95 (+16%)

A 5% rise in customer need produces a 16% rise in required capacity, and that's before accounting for burstiness. Erlang B assumes random arrivals. Fan-out traffic arrives in clusters, so real peaks will run higher than the model predicts.

An agent-aware forecast, which we're calling Agentic Erlang, separates human and A2B demand and ties each contact back to the task that produced it. It supplements existing models rather than replacing them, and it shows whether growth reflects new customer needs or software making several attempts at the same one.

Personal agents use whichever channel works

A person usually picks the channel they prefer and sticks with it. A personal agent picks whichever channel gets the task done, and switches the moment one fails. It might try an API, fall back to the website, and end up on the phone, all for the same request. Each channel handles agent traffic differently, and each one breaks in its own way.

Voice is a clumsy way for two software systems to exchange structured information. A confirmation number that exists as clean data on the agent's side gets converted to speech, compressed into phone audio, and transcribed back into text, and each step can introduce errors with letters and numbers that sound alike. Both sides also add processing delay on every turn and have to guess when the other has finished talking. Legacy IVRs make it worse, forcing agents through menus and touch-tone keys designed for human callers, and security questions assume the customer is the one on the line.

Messaging and browser automation remove some of those problems but introduce others. A personal agent may need to interpret a page designed for visual navigation, and a layout change can break the workflow. Policies written for people may be difficult for an agent to interpret consistently.

Direct APIs and agent protocols offer a more structured path. They make inputs, permissions, and outcomes explicit. But no enterprise can reasonably build and maintain a separate integration for every personal agent provider. That's why architectures must separate a company's service logic from the interface used to reach it.

One service capability across many channels

An A2B service layer sits between personal agents and the systems that perform business actions.

On one side, it accepts requests through voice, messaging, browser interactions, APIs, MCP, or other agent protocols. On the other, it connects those requests to booking, billing, account, catalog, logistics, and CRM systems.

In between, it interprets the request and determines which business process applies. It collects missing information, applies policy, invokes the appropriate system, and returns a result. When the task requires judgment or additional authorization, it escalates to a human agent with the existing context intact.

This model reduces integration sprawl. The enterprise defines the workflow once and exposes it through several interfaces. A booking change follows the same eligibility rules whether the request comes from a customer on the phone, a personal agent using voice, or an external agent invoking a structured endpoint. The business logic remains consistent, and adapters handle the requirements of each channel or protocol.

We built our platform around the same principle. With Agent Composition, teams define one blueprint agent that holds its logic, skills, and tone, then adapt it across regions, languages, and channels without cloning it. A policy change made once flows to every version. On the systems side, our runtime treats each MCP tool call to a CRM, booking engine, or ticketing system as a self-contained request, with timeouts and a structured error path that tells the AI agent whether to retry, respond, or hand off to a human agent. Those are the two halves a service layer depends on: consistent logic and reliable connections to the systems that do the work.

Identity and authority must travel with the request

A service layer also needs to know what the requesting agent is allowed to do: which customer it represents, how that customer was authenticated, and what authority the customer delegated. Existing enterprise authorization can decide whether an agent may reach a system at all, but not whether it may cancel this customer's policy right now. Those per-action decisions belong in the service layer, and the proof required should scale with the risk. Checking opening hours needs little. Changing a reservation or making a purchase needs much more.

Gartner calls this kind of oversight guardian agents: technologies that supervise AI agents and adjust or block actions that fall outside their goals. In A2B, the service layer plays a similar role as the enterprise's front door.

Contact centers have long relied on a way to pass identity programmatically. When an IVR verifies a caller and transfers the call, it can send the result in the SIP User-to-User Information (UUI) header, so the receiving system doesn't have to ask again.

Our AI agents carry that model forward. They verify identifiers like a customer ID or date of birth against the enterprise's CRM or identity provider, and the Large Language Model (LLM) never decides whether authentication succeeded. That outcome comes from configured rules and the external system's response, enforced by the architecture. Once a caller is verified, sensitive tasks unlock without re-asking.

Both approaches establish authentication: who the customer is. Neither carries authority: what the customer has allowed someone else to do on their behalf. When the caller is a personal agent, the business needs both.

The next step is making authority travel with the request. No common A2B standard exists yet for delegated authority, but OAuth-style scoped access tokens are the closest building block. A delegated authorization token might look like this:

{
  "customer": {
    "id": "cus_8841",
    "auth_method": "passkey",
    "auth_time": "2026-10-02T09:14:00Z"
  },
  "agent": {
    "provider": "example-personal-agent",
    "agent_id": "pa_2231",
    "attestation": "signed"
  },
  "authorized_action": "booking.change",
  "scope": {
    "booking_ref": "ABC123",
    "max_fee": { "amount": 75, "currency": "USD" }
  },
  "data_access": ["booking.read", "booking.modify"],
  "expires_at": "2026-10-02T21:14:00Z",
  "review_url": "https://agent.example.com/tasks/4471"
}

In plain terms, the token says: this agent comes from a verified provider and is acting for a customer who logged in with a passkey this morning. It can change one booking and nothing else, pay up to $75 in fees, and its permission expires tonight. The customer can review what it did at the link provided. If the airline quotes a $95 fee, the service layer knows to pause and ask the customer before going further.

The service layer also has to plug into the compliance systems the enterprise already runs, such as identity and access management, fraud detection, consent records, and audit logs. Every action an agent takes should leave the same audit trail as one taken by a human agent, so compliance teams can see what was authorized, by whom, and on whose behalf. That’s the approach Parloa takes in its partnership with SAP, working with the pre-established service layer to ensure compliance while maintaining SAP as enterprises’ data source of truth. And by running on Microsoft Azure, Parloa works off of the established AI governance rules built into Azure’s foundation.

No contact center platform can establish this trust model alone. Personal agent providers, identity services, telecom networks, and enterprises will all play a part. Until standards mature, the service layer's job is to consume whatever evidence arrives and apply risk-based rules consistently: low-risk requests proceed with light verification, and high-risk actions pause, ask for more proof, or move to a human agent.

Observability must follow the task

Most contact center metrics measure individual contacts: call duration, containment, transfers, abandonment, and sentiment. A2B breaks that model, because one customer goal can now produce many contacts across several channels.

A single task might generate an API request, two retries, a phone call, and an escalation to a human agent. On a dashboard, those look like five unrelated events rather than one unresolved need. A call can even count as contained because no human agent joined, while the personal agent never completed its goal.

A2B needs task-level metrics that connect every attempt to the underlying customer intent: contacts per task, retry frequency, completion accuracy, escalation rate, and time to resolution. Systems also need to catch loops, duplicate actions, and repeat requests that should count as one operation. The primary metric should be resolved intent, not contained contact.

Resolution is already the measure we focus on. Parloa Lens pairs deterministic metrics like containment, average handle time, and tool calls with calibrated LLM judges that evaluate intent, resolution, and caller frustration for each conversation. That makes it possible to catch a conversation that looks contained but didn't resolve anything. The next step for the industry is extending that view beyond a single conversation, so one customer goal can be traced across every channel and attempt it touches.

The problems that remain to be solved

While a service layer handles the architecture, there are still some outstanding considerations that need to be resolved before we can all feel confident in A2B. 

1. Idempotency. A retry shouldn't book two flights. Every action that changes state needs a key that lets the service layer recognize a repeat across channels.

2. Detecting undeclared agents. On a voice line, an agent may not identify itself. Response latency, speech patterns, and call timing all offer signals, but none is conclusive, and misclassifying a human caller poses serious risks.

3. Rate-limiting without refusing real demand. Businesses cap how many requests a single source can send, both to block abuse and to protect their systems from overload. But a personal agent sending lots of requests can look like a bot when it's really working through one customer's task. Block it, and the need doesn't go away. The agent calls instead, moving the same request to the most expensive channel.

4. Agents negotiating with agents. When the enterprise side is also an AI agent, who decides when to escalate to a human? And how should a business handle retention offers or upsells when the other side is software following only its customer's instructions?

We don't expect any one company to solve these problems, and we don't expect them to wait. We've long anticipated a shift in which customers stop contacting businesses directly and send personal agents instead, and Muse suggests it's now underway. 

We're watching how personal agent providers, protocol maintainers, and standards bodies approach identity and delegation, and we're building our platform so enterprises can adapt as those answers arrive, without rebuilding their agents each time. The enterprises that put a governed service layer in place now will be ready for whichever agents show up next.