Agent Connector Platforms

What the category is.

An agent that only talks to a model needs nothing. An agent that has to read this user's inbox, update this user's CRM record or file this user's ticket needs a credential per user per provider, and that requirement multiplies badly: ten integrations across a hundred thousand users is a million credentials to obtain, store, refresh and revoke. An agent connector platform is a hosted service that owns that problem and exposes the result as callable tools — increasingly over MCP, so any agent can point at it. Arcade, Composio, Pipedream Connect and Nango are the recognisable examples; the category is defined by the job.

It is easy to confuse with two neighbours. An agent framework decides how you express the loop that calls tools; a connector platform supplies the tools and the identity to call them with. A managed agent runtime operates the loop and usually includes a tool gateway of its own — often a thinner one, which is why the two are commonly used together.

Three products in one purchase.

Every platform in this category is really three services bundled behind one URL. They differ enormously in how hard each is to replace.

• The connector catalog — pre-built integrations with the SaaS products your users already have. This is the advertised number, and the least durable part of the purchase. It is deep on the same dozen products everywhere and thin on the long tail, and the long tail is where your differentiation lives. Every platform also supports custom tools, so adding what is missing is work you can actually do.
• The token vault — an encrypted, per-user, per-provider credential store that runs the OAuth challenge, refreshes and rotates tokens, recovers from scope mismatches, and injects the secret into the outbound call at execution time. Nobody markets this. It is the part that takes a quarter to build properly and a security review to keep.
• The tool-shaping layer — renaming parameters, hiding fields, trimming responses, deciding which of a vendor's fifty operations the model is offered. A sleeper feature, because most vendor APIs were designed for developers reading documentation rather than for a model choosing under a token budget. See tool design for agents.

The property worth paying for is that the model never sees the token.

The mechanic these platforms share is worth stating precisely, because it is a real security boundary rather than a convenience. Your agent asks for a tool by name plus a user identifier. The platform resolves that user's credential server-side and injects it into the outbound request at execution time. Only the response comes back to the model.

The alternative — assembling an Authorization header inside your agent loop — puts a live credential in the same context window as untrusted tool output. Once it is in the context, a prompt injection in a retrieved document has something to ask for. A token that was never in the context cannot be exfiltrated by persuasion, which converts a class of attack into a non-event.

This also changes what an agent is from a permissions standpoint: it acts as a specific user, with that user's scopes, rather than as one service account holding the union of everyone's access. That distinction is the whole subject of agent identity & permissions, and a connector platform is the most common way teams end up on the right side of it.

How to choose, and the one thing you cannot retrofit.

The comparison that matters is short and it is not the catalog count. Ask what the meter runs on, because the units differ structurally — per tool call, per execution second, per connected account, per authorization challenge — and each one taxes a different shape of agent. A chatty loop is cheap under one and ruinous under another, so price your own volumes under each rather than comparing headline tiers. Ask whether the credential store can live in your infrastructure, since that requirement eliminates options faster than any other and correlates inversely with catalog size. Ask what happens to your traces.

Then ask the question nobody puts on a pricing page: whose name is on the consent screen? When your user clicks "Connect Gmail", the OAuth dialog names an application. On the default hosted path that name is the platform's, not yours. Every platform here supports bringing your own OAuth client IDs, and doing so is a day of app registrations at adoption.

It is worth the day because tokens are issued against a specific OAuth client. Changing that client later means every existing user re-authorises — which is not a migration task but a conversion funnel, and some fraction never returns. An enterprise admin who allow-listed your vendor's app approved your vendor, not you, and that review has to be redone if you ever switch.

Related: scoped credentials for agents for what an injected credential should be allowed to do, third-party tool drift for the catalog changing under you, delegated access & consent records for the record the token is not, and MCP registry & distribution for how these tool sets get found and installed.