Put Agents to Work

Connectors

Connectors let agents use external services while installation, assignment, and authentication stay under workspace control.

Connectors give agents access to the services you already run. The Marketplace helps you find them, while Installed, Proposed, and Archived keep their lifecycle visible. Skills remain a separate settings area for reusable agent expertise.

A connector gives an agent access to an outside service

A connector is an external service your agents can use, such as Stripe, Linear, Notion, or a search provider. It exposes actions an agent can call while it works. You add it, scope it to the agents that should have it, and keep its authentication under workspace control.

Connectors let an agent work beyond what lives inside Task Machine. An agent with a payments connector can read a charge, one with a project-management connector can open an issue, and one with a search connector can pull current results into its work. What an agent can reach is decided per agent, alongside the control over what it may do in its profile.

Browse the connector Marketplace

Open Settings, choose Connectors, and start on Marketplace. It shows a searchable grid of recognizable services, with each card naming the service and describing what it does. The catalog covers research, development, analytics, knowledge, messaging, sales, support, finance, marketing, and other common work.

The Connectors Marketplace showing searchable connector cards and lifecycle tabs for installed, proposed, and archived entries

The default grid uses the connector catalog Task Machine already knows. Search uses Task Machine's synchronized copy of the connector registry and ranks exact service names ahead of broader matches, so results remain fast and predictable without waiting on the registry. A verified check marks official connectors: a registry search result is official only when the registry proved the publisher controls the domain its namespace claims and the connector's own website lives on that same domain, evidence that it comes from the vendor itself. Entries published under a shared code-host namespace, entries whose website is on an unrelated domain, and entries that list no website stay community. Task Machine's own curation stays authoritative for connectors in the catalog, so curation is never overridden by a registry entry. Cards link to a safe published source when one is available, and the install review shows available publisher, version, website, and source details. Missing or unsafe links stay hidden. Deprecated or unavailable entries stay labeled honestly and cannot be installed.

Install a connector and scope it to agents

Select Install on a Marketplace card to open its details and continue into the same setup used by Add connector. When registry defaults are available, Task Machine carries them into setup. Otherwise, it carries the connector's name and description and asks you for the connection details instead of blocking installation. Installed connectors take two steps: Details and Connection. They save the command and arguments that assigned workers will run. Remote connectors add a third Verification step before anything is saved. Adding or managing connectors requires the mcp:manage permission. Members without it can browse the Marketplace read-only.

Verification tests a remote connector from the Task Machine backend, so it does not need a local or cloud worker to be online. Task Machine uses the selected authentication to initialize the connection and list its available actions. A successful result applies only to the exact details you reviewed. Changing them, going back, or closing the setup requires a new check, and a failed check must be retried before the connector can be added or changed.

An agent can start the same setup from Chat when your request depends on a service it cannot reach yet. It names the missing access and proposes the connector before attempting the dependent work. The proposal waits while you review it, authorize the service when required, and assign the connector. Once the connection is available, the agent can continue the original request.

The Proposed page keeps pending connectors in the same list format as Installed and Archived. Each row identifies the connector, connection type, connection address, and proposing agent. Review opens the complete proposal and its rationale before a permitted reviewer approves or rejects it.

Most connectors do not reach an agent until you assign them. Two public-web connectors are ready in every workspace: Playwright lets every agent open and interact with pages in an isolated browser, while Exa lets every agent search the public web and fetch readable page content. They cover research and browser evidence without an account-connection step. Search queries, requested public URLs, returned public page content, request metadata, and the worker's IP address may be processed by Exa as described in the Privacy Policy.

You assign every other connector to the specific agents that should have it, so a payments connector reaches your finance agent without widening what every other agent can touch. Scoping connectors per agent follows the same principle as scoping permissions per agent: access is granted where the work happens, not globally.

Assigning a connector does not silently grant its Vault credentials. Task Machine immediately sends each required credential-access decision to the Inbox, where an authorized member can approve one run, approve for a period, approve indefinitely, or reject it. If work reaches the connector before that decision, the original run waits without repeatedly retrying. The same Inbox decision also appears in the blocked Chat or Task Activity, with its context, actions, and completed outcome intact. Chat keeps its composer visible but unavailable until the decision is resolved, so another message cannot queue behind access the agent still lacks. Approval continues the preserved work; rejection stops it and blocks affected tasks until you change the connector assignment or grant access.

For coding work, the Marketplace includes the official GitHub, GitLab, and Bitbucket provider connectors. These handle provider operations such as pull requests or merge requests, reviews, issues, and CI pipelines. Each connector's selected official registry remote determines the setup default. A declared secret request header selects Vault-backed header authentication and fills in its name. Without one, setup starts account authorization. Repository SSH access remains separate and handles Git transport only.

A remote connector chooses one authentication method when you add or edit it. The Marketplace starts with the registry-declared default, which you can review before Verification. Use Account authorization when the service offers its own consent screen, choose a request header backed by an entry in the Vault for an API-key service, or choose no authentication for a public endpoint. These choices are exclusive. An account login never competes with a manually configured authorization header.

A request-header binding keeps its header name, optional value prefix, and Vault entry together. Leave Value prefix at No prefix when the service expects the stored value unchanged, select Bearer when its authorization header requires that scheme, or type the custom prefix documented by the service. Task Machine adds one space between a selected prefix and the Vault value without changing the Vault entry itself.

Installed connectors can map Vault entries to the environment variables their commands expect. The picker can create a new write-only entry without closing the connector setup, and the new entry is selected immediately.

The Add connector flow with its Vault picker open and the Create vault entry action available

Selecting Connect account discovers the service's authorization flow and takes you to its consent screen. Task Machine keeps the long-lived login in the Vault and uses short-lived access for remote Verification and later agent work. Vault-backed request headers are resolved only for the connection check and later use; their values never appear in the result. Installed connectors use selected Vault entries as environment variables instead, following the command's configuration.

Playbooks bring their own connectors

You rarely have to wire connectors by hand. A playbook bundle can declare the connectors the job needs and the agents they attach to, so installing the bundle creates those connectors already scoped to the agents that use them. When you install a bundle by hand the connectors come ready. When an agent proposes a bundle, its connectors are part of the single approval rather than a separate step.

The same catalog supports the public proof

The connectors your agents use are also what the public site shows as a "Works with your tools" wall on the homepage and cohort pages. The same catalog powers both surfaces, so the public promise stays tied to the connectors agents can actually use.

From here, set which agents carry which connectors in the agent profile. Open Skills separately when an agent needs reusable expertise. See Stay in Control for the mcp:manage permission that gates adding and assigning connectors.