Connectors

A connector is a tool that reaches an external system as the user. It is the platform's answer to the hardest part of enterprise agents: letting an agent act in ServiceNow, a calendar, or a mailbox without ever holding a shared god-credential.

The core idea: delegated identity

Each user connects their own account once. From then on, when an agent calls a connector on that user's behalf, the platform resolves that user's OAuth token at call time and sends only that. Two people asking the same agent the same question get their own data back.

Operations

Each connector exposes a small set of named operations, and every operation is tagged. The tag is what governance keys on:

Available connectors

Browse these in the app under Catalog → Connectors, and connect your own accounts under Settings → Your connections, which shows every connector by category with its operations and whether you have connected it. 25 connectors ship today across seven categories, plus the knowledge sources listed at the end. Every operation below carries the tag governance keys on: read runs at once, write parks for approval under supervised autonomy, and destructive parks even under trusted autonomy.

IT service management

Ticketing and service desks an agent can search, raise and resolve in.

CRM and support

Customer records and cases, filtered by the caller's own sharing rules.

Mail, files and calendar

Everyday work an agent reads and acts on as you.

Communications

Chat, mail, calendar and meetings an agent reads and posts to as you.

Developer

Code hosts and issue trackers.

Privileged access

Remote support and privileged sessions. Every state change is approval-gated.

Agent platforms

External agent runtimes this platform can delegate work to.

Knowledge sources

These are not tools an agent calls; they are sync sources attached to a knowledge collection. A scheduled sync pulls content for agents to search and cite, mirroring each document's readers so a colleague never retrieves a page they could not open at the source. Details are on the Knowledge & memory page.

The list grows in one place: a connector is one adapter module behind the same protocol, and the catalog, the connect flow, the approval gate and the audit trail come for free. Anything not listed can usually be reached today as a custom connector, below.

Custom connectors: any REST API, no code

When an internal or niche tool has no built-in adapter, an org admin can configure a custom HTTP connector — from Settings → Connectors → Add a custom connector — with no code and no deploy. A custom connector is a description, not a program:

• a base URL and an auth method — OAuth 2.0 (authorize/token URLs, client, scopes) or a static bearer token entered per user;
• a list of operations, each a method + path with {braces} for path parameters, tagged read or write.

What you configure becomes a real connector: an agent declares it by slug like any other, the call is delegated as the requesting user, writes park for approval, and every call runs through the one execution path. Path parameters are filled from the model's arguments and, for a write, the remaining arguments become the JSON body.

Knowledge sources (Confluence, Google Drive) also use delegated OAuth, but they are not agent-callable tools — they sync documents into knowledge collections, mirroring each document's source permissions so retrieval stays permission-aware.

Using a connector in an agent

Add the connector name to the agent's tools. That's the whole grant.

---
name: exec-assistant
model: default
tools:
  - calendar
---

# Role
Book meetings on the user's calendar. Always confirm a slot before creating it.

The model sees one calendar tool whose schema lists the available operations, and picks an op plus arguments.

The connect flow

1. Consent

   The user starts a connection (from settings, or from a Connect card in chat). The platform builds an authorization-code + PKCE request and redirects to the provider.

2. Callback

   The provider redirects back with a code, which the platform exchanges for tokens server-side.

3. Vault

   Tokens are encrypted at rest and referenced indirectly. They are decrypted only server-side at call time and never returned through the API.

4. Use and refresh

   A background sweep refreshes tokens before expiry. If a run parked waiting on the connection, completing consent resumes it automatically.

Lifecycle and safety

• Revocation is immediate — credentials are resolved per call, so a disconnected connector stops working on the very next call, not at the next token refresh.
• Deprovisioning cascades — removing a user revokes all of their connector credentials, disables their automations, and cancels their runs.
• Health checks — each connector exposes a cheap liveness probe that runs on a schedule.
• DLP applies — data read back from an external system is screened before it reaches the model, and outbound arguments are screened too.
• Everything is audited — connect, disconnect, every invocation, and every approval decision.
• An administrator decides which connectors exist — Admin → Infrastructure → Connectors lists every connector, and one switch turns each on or off for the whole organization. A connector that is off is hidden from everyone, cannot be connected, and is not offered to an agent that declares it: the agent tells the user the connector is not available and to contact their administrator (it still saves, with a warning). Knowledge sources of that kind stop syncing but keep what they already imported, so switching it back on resumes where it left off. Everything starts on.

How connectors differ from MCP servers