Integrations

Integrations connect agents to your tools — CRMs, ticketing, chat, code, analytics — through the open Model Context Protocol. Once a connection exists, its tools simply appear in the agents’ toolkit; there is nothing to wire per assignment.

That last point is the design. Ability is configured once, at the connection, rather than per task: connect your CRM on Monday and every assignment, chat session, and webhook-triggered run in that scope can reach it from then on. When you write an assignment like the weekly pipeline report, the instructions describe the work — “pull the open opportunities, flag the at-risk deals” — and the agent finds the CRM tools already in hand. Web browsing and file handling are built into every agent and need no connection at all.

Browse the full list in the integration catalog — it spans automation, data, design, engineering, finance, legal, marketing, operations, productivity, sales, and support tools.

Connecting

From Customize → Integrations, add an integration from the directory. Two kinds of setup:

• OAuth — a Connect button sends you to the provider to authorize.
• API key — paste the provider’s credential into the fields shown.

In practice the flow takes a minute either way: approve the grant on the provider’s own page, or fetch the credential from the provider and paste it in. Connecting Slack, for example, means pasting the bot token from your Slack app — the Slack guide walks that one end to end, including wiring up events so you can chat with your agent from Slack.

Providers that support it can be connected more than once — add a second account with its own instance name (for example, hubspot_acme) and agents can address either. This is how you handle a second brand, region, or environment: hubspot_acme and hubspot_emea are two credentials to the same provider, and instructions can name whichever one a job needs.

Name instances after the account, not the person

An instance name like hubspot_acme says whose data lives behind it; hubspot_new or sarahs_hubspot will make sense to nobody in six months. When there is only one connection, the plain provider name is fine.

Scopes

Connections are credentialed at one of three scopes:

• Workspace — “Connect this workspace to the accounts and systems its agents need. Everyone in the workspace can use them.”
• Organization — available to members and agents across the whole org; managed by org admins. In a workspace’s view, org-inherited connections can be disabled per workspace.
• Agent-private — a credential owned by a single agent and used only by that agent, connected from the agent’s page. Useful when one agent should act under its own identity.

Scope should follow ownership of the account. A CRM the revenue team works in daily is a workspace connection in the revenue workspace. Company-wide systems — Google Workspace, Slack — fit organization scope, so every workspace inherits them without repeating the setup; a workspace that shouldn’t have one can switch it off. Agent-private connections cover the narrower case where the agent is the identity: an agent that files GitHub issues under its own bot account, so its activity is attributable to it rather than to whoever connected the credential.

Scopes decide who can use a connection; guardrails are the deny side. A guardrail can block a provider entirely for an agent, a workspace, or the whole organization, regardless of what connections exist — so “the CRM is connected” and “this intern agent may touch the CRM” stay separate decisions.

Custom MCP servers

Beyond the catalog, you can register your own MCP server at workspace or organization scope: give it the server’s HTTPS URL and Workprentice discovers its authentication (OAuth or client credentials) automatically. Remote HTTPS servers only — local command and STDIO servers are not supported.

This is the door for systems the catalog will never list: an internal inventory service, a homegrown admin API, a vendor that ships its own MCP server. Expose it over HTTPS, register the URL, and its tools appear in the agents’ toolkit just as a catalog integration’s do.

Patterns that work

• Workspace connection for team systems — the CRM, the ticket queue, the analytics account a team lives in. Connect once; every agent in the workspace can use it.
• Organization connection for shared systems — chat and office suites used company-wide. Manage them centrally, and disable per workspace where they don’t belong.
• Agent-private credential for attributable actions — when an agent should act as itself, give it its own account and connect it from the agent’s page.
• Second instance for a second account — one provider, two credentials, distinct instance names; assignments name the one they mean.
• Custom MCP server for internal tools — anything your team can serve over HTTPS becomes part of the toolkit, without waiting on the catalog.