Developer overview
Build plugins that operators run — connectors, transforms, skills, tools.
Operators run the show. Developers extend what operators can do by building plugins: connectors to new data systems, transforms that shape data, skills that guide execution, and tools that add external capabilities.
In workspaces these appear as integrations and skills — "plugin" is the builder's word for what operators install and run.
What a plugin is
- Connector: reads from a data system operators already use — databases, warehouses, files, APIs.
- Transform: reshapes data inside a workflow — aggregate, clean, classify, resolve entities.
- Skill: a versioned instruction module that guides how work gets done in a workspace.
- Tool: an external capability a workflow can call during a run.
How plugins reach operators
- Build the plugin against its capability contract.
- Publish it to the registry so workspaces can discover it.
- Operators install it into their workspace and use it in the loop: describe, proposal, preview, dry-run, commit.
- Feedback flows back. Operator corrections and approvals show where a plugin helps and where it misfires — that is the signal for the next version.
A plugin never commits anything on its own. It proposes through the same loop operators already review, so everything it does stays inspectable and reversible.
For how operators review and commit plugin-driven work, see Operators.
Example: a Postgres connector declaring full-refresh plus incremental modes lets one source serve both nightly syncs and backfills; a validation-assist skill attached to the mapping node catches malformed rows before they reach review.
Example 2: a forecast skill that triggers on renewal language, paired with a warehouse lookup tool, so every churn proposal arrives with account history attached.
Field-level contracts for what you build: Integrations, Skills, Workflow nodes, Write policies.
Image: plugin lifecycle — build, publish, operator installs, runs in the loop, feedback returns.