Connectors

The connector interface and the catalog of shipped connectors.

A connector is a self-contained module that gives the agent the ability to read and write a particular kind of state. Each connector owns its tools, file resolvers, skills, and any system-prompt context it wants to inject. The agent composes them at run time based on which connectors are enabled for the user.

The connector interface

Every connector exports a Connector object with four hooks:

type Connector = {
  id: string
  tools: (ctx: AgentContext) => Record<string, DispatchTool>
  fileResolvers?: (ctx: AgentContext) => FileResolver[]
  skills?: (ctx: AgentContext) => SkillDoc[]
  systemPromptSection?: (ctx: AgentContext) => Promise<string | null>
}
  • tools: AI SDK tool definitions. Tools are hidden from the model by default and unlocked through tool search at run time. A tool can carry a risk annotation (external-write or policy-write) that routes it through the permission gate before execution.
  • fileResolvers: owners of one or more virtual path namespaces (for example /preferences, /documents, /automations/triggers). When the agent calls read_file, write_file, or list_directory against a path, the request is routed to the resolver that owns that namespace and awaited synchronously, so the agent only sees success: true after the change is durable.
  • skills: markdown documents mounted under /skills/{skillName}/. The agent reads them on demand via read_file; skills act as just-in-time prompts for specialized behaviors.
  • systemPromptSection: an optional async function returning a string that gets concatenated into the system prompt for runs where this connector is active. Used for short connector-aware orientations (e.g. "you have a Slack workspace connected").

Catalog of shipped connectors

The agent composes from about two dozen connectors. They split cleanly into user-facing connections (external accounts the user authorizes) and internal surfaces (Dispatch's own data model that the agent reads and writes).

User-facing connections

These show up in the user's Connections settings. Each one has a dedicated Features connection page covering scopes and limits.

ConnectorActs on
gmailGmail account: read, search, draft, send, label, archive
google-calendarGoogle Calendar: read events, free/busy, create/update/cancel, RSVP
outlook-mailMicrosoft Graph email: read, search, draft, send, categorize
outlook-calendarMicrosoft Graph calendar: read events, free/busy, create/update/cancel
slackSlack workspace: list channels, read channel and thread history, post messages, download files
telegramTelegram: receive prompts, send replies to chats
composioBroker for additional third-party SaaS actions exposed through Composio's toolkit catalog. Tools are materialized at run time from the user's authorized Composio toolkits, so this connector is registry-presence-only and returns no static tools

Internal surfaces

These are not third-party integrations; they are Dispatch's own data model exposed through the same connector interface.

ConnectorProvides
preferencesThe agent's preferences file at /preferences/global.md plus the permission policy at /preferences/permissions.md
daily-notes/daily-notes/today.md and historical daily notes, with the current day injected into the system prompt
people/people/{slug}.md records for the user's contacts
meetings/meetings/... records organized by date
documents/documents/... arbitrary notes and files
todos/todos/{slug}.md plus a todo_create tool used by both chat and the todo runner
automations/automations/triggers/... and /automations/schedules/... definitions
custom-skillsUser-authored skills at /custom-skills/{slug}.md; auto-invoke skills are listed in the prompt by name and description and read on demand. See Custom skills
booking-pagesBooking links surface: tools to create recurring and single-use scheduling pages. Guest availability, booking, reschedule, and cancel flows run server-side, not through this tool surface
connectionsAwareness of which integrations the user has connected, plus the connections_connect tool used to surface "connect this" calls to action
historyTools to list and load past agent sessions
searchThe unified search tool that spans entity types
defaultsA read-only mirror of preferences and automations as they ship out of the box; the agent uses it to diff against the user's customizations

The survey connector exists for internal telemetry and is not documented further here.

How connectors compose

For a given run, the agent context lists which connector IDs are active. The agent runner asks each one for its tools, file resolvers, skills, and prompt section. Tools are added to the tool-search registry; file resolvers are registered into the path router; skills are mounted under /skills/; prompt sections are concatenated.

Connectors do not depend on each other. A user with only Gmail connected sees the same agent shape as a user with Gmail plus Slack plus Calendar; the latter just has more tools available. The skill files and prompt sections explain to the agent how to use each connector; the user does not need to learn separate commands per connection.

Adding a connector (for engineers reading this)

A new connector is a module that exports a Connector object matching the interface above. The connector is registered in the central connector catalog, then enabled for relevant accounts. Skills live as markdown files next to the connector code so they ship together.

For agents

  • A connector is a self-contained module with id, tools, optional fileResolvers, optional skills, and optional systemPromptSection.
  • Connectors are composed per run based on the user's active connections.
  • The catalog includes user-facing connections (gmail, google-calendar, outlook-mail, outlook-calendar, slack, telegram, composio) and internal surfaces (preferences, daily-notes, people, meetings, documents, todos, automations, custom-skills, booking-pages, connections, history, search, defaults).
  • Tools are not added to the system prompt directly; they are surfaced through the tool-search registry on demand.
  • Tools with a risk annotation pass through the permission gate before executing.
  • composio is registry-presence-only; its tools are materialized at run time from the user's authorized Composio toolkits.

On this page