Connectors

Connectors are how ThinkWork interfaces with the outside world. They bring external systems into the thread model and let agents act back on those systems in a controlled way.

ThinkWork uses connectors in two broad ways:

1. Integrations turn inbound messages, webhooks, and app events into threads, then send responses back out.
2. MCP tools give agents access to external capabilities they can call during work.

Both fit the same architectural story: ThinkWork keeps threads, agents, controls, and auditability in one system while connectors handle the system boundary.

Connectors at a glance

Integrations

Integrations cover app and system connectivity, including Slack, GitHub, Google Workspace, inbound webhook flows, outbound actions, and connector routing.

Use integrations when ThinkWork needs to receive or send activity through an external product surface.

MCP tools

MCP tools cover remote external capabilities that agents call during a turn. They are still connectors, but they are tool-oriented instead of message-oriented.

Use MCP when the capability already exists outside ThinkWork and you want agents to use it without rebuilding it inside the platform.

Common examples include:

• CRM lookups and account updates
• Task and ticket operations
• Internal API actions
• Search or retrieval against external systems
• Database or business-system queries exposed through an MCP server

Navigate this section

• See Integrations for Slack, GitHub, Google Workspace, inbound and outbound flows, auth, and routing
• See MCP Tools for MCP-based external tool connectors

MCP as a connector pattern

ThinkWork supports MCP (Model Context Protocol) as a connector path under Connectors, not as a separate top-level product module.

That means MCP sits inside the broader Connectors model:

• Threads are still the unit of work
• Agents still decide what to do in the thread
• Connectors bring in outside systems, whether they are communication channels or tool servers
• Controls still govern what agents can access and how usage is tracked

If you want agents to call remote tools through MCP, see MCP Tools.

Credential vault

All connector credentials are stored in the credential vault — a KMS-encrypted table in Aurora Postgres. Credentials never leave your AWS account.

The vault stores:

Credential type	Example
OAuth access + refresh tokens	Slack, Google
Webhook signing secrets	Slack, GitHub
API keys	Custom connectors
Service account JSON	Google Workspace (service accounts)

Credentials are encrypted at rest using a KMS key dedicated to the vault (created automatically during deploy). The Lambda functions that handle connector events have IAM permissions to decrypt only the credentials they need.

Rotating credentials

Credentials with refresh tokens are refreshed automatically before expiry. For credentials that require manual rotation (API keys, webhook secrets), use the admin app:

1. Navigate to Connectors → [Connector Name] → Credentials
2. Click Rotate
3. Enter the new credential value
4. The vault updates and all active connector functions pick up the new value within 60 seconds (Lambda environment variable cache TTL)

OAuth flows

For connectors that use OAuth (Slack, Google), ThinkWork handles the full OAuth dance:

Admin app: "Connect Slack"
    → Redirect to Slack OAuth authorize URL
    → User approves
    → Slack redirects to /connectors/slack/callback
    → Lambda exchanges code for access + refresh tokens
    → Tokens stored in credential vault
    → Connector marked as "active"

The OAuth callback URL is https://<api-gateway-url>/connectors/<connector-id>/callback. This URL must be registered with the external service as an allowed redirect URI.

Connector recipes

A connector recipe is a template for building custom connectors. The examples/connector-recipe/ directory in the ThinkWork repo contains a complete working example with:

• A Lambda handler for inbound events (webhook validation, thread creation)
• A skill pack with outbound tool definitions
• A Terraform module for the connector infrastructure
• An admin app plugin for the connector configuration UI

See Authoring Guide: Connectors for the full walkthrough.

Connector routing

When a connector creates a thread, it uses the connector routing rules to determine which agent handles it. Routing rules are evaluated in order:

Rule type	Example
Keyword match	If message contains “billing” → billing-agent
Channel/source	If Slack channel = #engineering → eng-agent
User mapping	If GitHub user = @alice → alice-agent
Default	Catch-all agent for the connector

Routing rules are configured per connector in the admin app. If no rule matches, the thread goes to the connector’s default agent.

Tip

For simple deployments, set a default agent on each connector and skip routing rules entirely. Add rules later when you need to fan work out to specialized agents.

Note

Need agents to use external tools instead of inbound channels? See MCP Tools for the ThinkWork pattern for connecting remote tool servers through the Connectors layer. MCP stays under Connectors in the docs because it is one integration path, not a separate platform pillar.

Thread metadata from connectors

Connector threads carry metadata about their origin:

// Slack thread metadata
{
  "channelId": "C08ABC123",
  "messageTs": "1712345678.123456",
  "teamId": "T08XYZ456",
  "userId": "U08DEF789",
  "username": "alice"
}

// GitHub thread metadata
{
  "repoFullName": "acme/backend",
  "issueNumber": 1234,
  "eventType": "issues.opened",
  "actor": "bob",
  "labels": ["bug", "priority-high"]
}

The agent receives this metadata in its context on every turn, so it can tailor responses (e.g., addressing the Slack user by name, linking back to the GitHub issue).