Integration capabilities
Every integration is described with the same four capabilities. This vocabulary is canonical: it appears in product surfaces (catalog rows, OAuth dialogs, integration detail pages, bindings) and in this documentation. Learn it once.
Audience: IT (the enabler) and builders
The four capabilities
The agent reads content from this system into the workspace. Pull Snowflake tables, sync SharePoint files, read Slack history.
The platform modifies content inside this system. Save a file to Google Drive, create a Linear issue.
Events in this system kick off work in the platform. Inbound email creates a work item, a Slack mention spawns an agent turn.
The agent sends messages back through this system. Reply in the Slack thread it was mentioned in.
The two-axis model
The four capabilities map to a fixed 2 by 2 grid. The columns sort by direction (into the platform versus out). The rows sort by shape (content versus events).
Where you will see this in the product
- Catalog rows at
/integrationsshow a one-line chip strip with the lit capabilities for each provider. - Integration detail pages show the full 2 by 2 at the top.
- OAuth authorize dialogs preface the connect button with the chip strip and the sentence "After you connect, this integration will be able to."
- Project bindings preview which capabilities the binding lights up for that specific project.
Absence is not a paywall. A capability that is not lit means the integration does not support that capability today. It is not a paywall, not a permission, and not "coming soon." If we ship support later, the capability lights up in the next release.
Caveats
Some lit capabilities carry a micro-copy specifier. Slack supports Reply but only in the thread where it was mentioned. Google Drive supports Write as two-way sync. These specifiers are visible in the 2 by 2 and in the documentation. The chip strip uses a small marker to indicate that a capability has a caveat; hover or tap reveals it.