Integrations
ThinkWork integrations are the boundaries where external systems meet the agent harness. In OSS ThinkWork, that foundation is intentionally small: OAuth credential primitives, webhook surfaces, MCP server registration, and per-user connection flows. Premium extensions can build richer provider-specific modules on top without depending on a shared OSS integration runtime.
What remains in OSS
Section titled “What remains in OSS”The OSS integration foundation includes:
- tenant and user credential storage primitives
- OAuth redirect and token handling patterns
- MCP server registration and per-user MCP auth
- webhooks as explicit API surfaces
- thread and Space primitives that integrations can target
It does not include a public integration catalog, integration execution table, private extension route, Linear tracker flow, or integration lifecycle API.
Design posture
Section titled “Design posture”External-system access should be modeled at the right level:
| Need | Preferred shape |
|---|---|
| The tenant platform agent needs tools during work | MCP server or built-in skill/tool |
| A user needs provider OAuth | Mobile per-user connection flow |
| A user-owned connector emits an event | Connector trigger targeting a Space |
| A tenant needs an inbound endpoint | Explicit webhook/API route |
| An enterprise customer needs a packaged workflow | Private extension with its own tables, runtime, and admin module |
This keeps OSS ThinkWork focused on the harness and avoids shipping under-proven provider abstractions as if they were stable platform contracts.
OAuth and credentials
Section titled “OAuth and credentials”OAuth credentials and provider tokens remain part of the platform. They should be resolved only by the runtime surface that needs them. User-owned connectors such as Gmail and Calendar stay tied to the consenting user; event triggers route into Spaces with explicit requester and credential-subject attribution.
Private extensions
Section titled “Private extensions”Premium or enterprise modules can install into the same AWS account and appear in admin, but they should own their domain model and lifecycle explicitly. private extension is the canonical example: it should bring its own tracker adapters, admin module, runtime bridge, writeback model, deployment wiring, and docs.