Your AI agent logged in. It still couldn't contact support.

Personal AI agents (PAs) and Model Context Protocol (MCP) servers are developing a beautiful relationship together.

‍

PAs have developed from standard AI chat tools (such as ChatGPT) to become agentic tools (such as Cowork and ChatGPT Work) that help SaaS customers not just retrieve information, but carry out tasks on their accounts.

‍

MCP-enabled SaaS businesses can expose API-backed tools that a PA can discover and use, making them natural partners for these newly capable agents.

‍

Together, they let a PA connect to an ever increasing number of SaaS businesses without bespoke instructions, and then get to work finding endpoints, reading data, and executing tasks.

‍

So far so good.

‍

What happens next is the problem. A PA can check a balance, list records, or pull a report, but it cannot directly contact the business about the account it has just connected to, for example to ask a billing question or raise a support ticket.

‍

We know this because we tested it. We pointed one PA at eleven SaaS products that we use and asked it to get a support answer from each business (we'll cover the per-product results in a separate post).

‍

Across the products where the PA successfully connected, its only route back to the business was to draft an email and hand it to us to send. Which perhaps is taking human-in-the-loop a little too far.

‍

No support path

‍

MCP servers, API connectors, OAuth: these give a PA tools for working with customer data and controlling access. Those tools generally work well for data access and product actions.

‍

What this surface lacks however is an account-linked support path; a way for the PA to ask a question, retain the conversation, and receive an answer. This is because the login credentials establish access to the product, but not necessarily a persistent endpoint for the PA.

‍

This is also true where the PA has already connected successfully. In our tests, the agent completed a large range of valuable actions - even correcting its own authentication document errors - but when it came to getting support, there was none to be found.

‍

Essentially, the technical work of connecting an account is becoming routine; connecting that account to support however is anything but.

‍

PAs can act but they have no say.

‍

Business cannot reach out

‍

Everything above describes PA-initiated contact. The reverse is arguably more significant.

‍

In the integrations we tested, the business had no way to start a support conversation with the PA. Every support exchange was PA-initiated. Without a callback address, there was no way to send a follow-up when a ticket's status updated, a price changed, or an improved offer became available. And if the PA was not connected, messages did not queue for later.

‍

Sure, email exists as a return path, but it’s not ideal. If the reply goes to the customer's inbox, a human has to read it and forward it to the PA, and then the original context is lost. If the PA has its own inbox, the reply arrives as a standalone message with no link to the original query. The PA has to parse it, match it to the right case, and work out what the business answered. And there is no corresponding email inbox and thread on the business side.

‍

So with email, the channel exists, but a persistent conversation on a topic doesn't.

‍

Missing commercial layer

‍

Most of the SaaS MCP servers we tested did not surface the customer's plan details, real-time usage limits or billing status.

‍

A PA that cannot see the commercial relationship cannot manage it end to end. It cannot warn the customer that they are approaching a limit or ask the business to adjust their plan without talking to the company that runs it.

‍

Having said that, one product we tested did let the PA see what the customer was paying for and gave it a scoped credential with a spending cap and an expiry. That example suggests what's possible when a business treats the PA as acting for the customer rather than merely as a tool to read data.

‍

Plugging the gap

‍

To summarize our tests: discovery and authentication were generally not the limiting factors. The missing layer was a stateful, bidirectional support channel. Once the PA is logged in, it should be able to ask the business a product or account question and receive the answer without a human relaying the message.

‍

That channel shouldn't replace human support; it can exist alongside it, as email exists alongside phone support. It would allow a PA to complete the tasks the customer sent it to do, whilst enabling the business to build an agent-based service relationship with the customer.

‍

We're building Exchange to provide this missing link, connecting PAs with a business's support operation (AI agent and human team) over a dedicated channel. We'd love to hear your experiences about connecting your agent to a SaaS or other business. Connect with us to help shape this new era of personal agent-to-business agent communications.

‍