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 it is available to 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

Skills & integrations → Integrations is one list of every integration, connected or not, with filters for status and category. Open one and choose Connect (or Add name connection when it already has one). The form asks for what that provider needs:

• How to connect — shown when a provider offers more than one method, such as OAuth or a personal access token.
• OAuth sends you to the provider to approve access. Some providers first need the client ID and secret of an OAuth app you register with them; for those, the form shows the Redirect URI to add to that app.
• API key or token — paste the provider’s key or token into the fields shown. 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.
• GitHub offers Install GitHub App, which installs the Workprentice GitHub App and needs no token to create or rotate, alongside a personal access token.

Providers can be connected more than once. The second connection needs an 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 connections to the same provider, and instructions can name whichever one a job needs. The connection an agent gets when it names no instance is marked Default; Make default on another connection’s menu moves it. Nothing else moves it: a default whose sign-in has expired stays the default and shows Reconnect until someone reconnects it or makes another connection the default.

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.

Each connection’s menu also has Configure context: notes that tell agents how your account is set up (custom fields, naming patterns, workflow rules), and an option to let agents record facts they discover about it as they work.

Who a connection is available to

Every row in the list says who it is available to, and who connected it. Company connections come in three scopes:

• Organization — one connection every workspace inherits. Org admins choose it as the Scope when connecting, or use Change scope… on an existing workspace connection. That move re-authorizes the connection for every workspace, so the confirmation names the account it signs in as. A workspace that shouldn’t use an inherited connection picks Don’t use in this workspace, and can restore it later. Slack is the exception: it is read per workspace, so connect it in each workspace that needs it.
• Workspace — shared by the workspace’s agents.
• This agent — a connection only that agent uses, added with Add → Connect an integration… on the agent’s Abilities card and listed there under Owned by this agent. Useful when the agent should act under its own identity.

Beside the shared ones, each person has their own connections, listed under Yours on the same page and connected with Yours as the Scope: accounts you sign in to yourself. Those are used only by agents you own — your personal agent, your private agents, and your copies of team templates — and never by a shared agent or a teammate. Your own agents can also use company connections unless an admin clears Allow use from private agents in that connection’s Configure context; a connection closed that way is badged No private agents. If a company connection turns out to be your own account, This is my account — move it to Yours moves it. Connecting from an agent’s Abilities card asks the Scope too: a personal or private agent opens on Yours, a shared agent on Workspace, and a copy connects only Yours.

Reach 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 such as Google Workspace fit organization reach, so every workspace inherits them without repeating the setup. A one-agent connection covers the 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 made the connection.

Company OAuth needs a company account

When you authorize a company connection over OAuth, sign in to the provider as the account the team should act as. If the provider reports that the account is your own, Workprentice refuses the grant and points you to Your connections instead, so one person’s inbox or drive is never quietly shared with the whole team.

Reach decides 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: choose Add custom server in Skills & integrations → Integrations and give it the server’s HTTPS URL. Workprentice checks the URL as you type and offers OAuth when the server advertises it; otherwise pick Client credentials (a token URL, client ID, and secret) or None for a server that needs no sign-in. Remote HTTPS servers only — local command and STDIO servers are not supported.

A server registered in a workspace is available to that workspace. An org admin can move it to the whole organization with Change scope…, after which every workspace sees it and can connect to it; connections stay where they were connected. The server’s menu also has Test connection, Edit server, and Remove server.

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.

Workprentice serves MCP in the other direction as well: your workspace is itself an MCP server that Claude Code, Claude Desktop, or any other client can connect to. See connect from MCP clients.

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 — office suites and document stores used company-wide. Manage them centrally, and choose Don’t use in this workspace where they don’t belong.
• One-agent connection for attributable actions — when an agent should act as itself, give it its own account and connect it from the agent’s Abilities card.
• Your own account for work done as you — connect your own mailbox or calendar with Only you, and your own agents act as you without that account ever reaching a shared agent.
• Second instance for a second account — one provider, two connections, 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.