Integration types
Connectors, channels, knowledge sources and automation — one vocabulary for everything that links agents to your systems, people and events, what is true today and what is next.
Connectors reach your systems. Tools are what agents are allowed to do there. Channels are where your people and customers meet the agents. Knowledge sources are what agents read. Automation starts work from events and reports back.
That one sentence is the whole model. Everything that links an agent to the world outside Agentic Workforce ME is one of four integration types, and every type is summarised on the console’s Integrations page (route /tools). The words on these pages are the words the console, the API reference and the product website share — nothing has to be learned twice.
A connector is how Agentic Workforce ME reaches one of your systems — its transport, its authentication and the tools it exposes.
invoice.get and payment.record, one connection ("AP service key"), granted to the AP Validator agent, payment.record behind an approval policy./v1/mcp-servers /v1/connections /v1/connectors /v1/a2a/remote-agents /v1/http-credentials /v1/tool-grants /v1/approval-policies /v1/agents/:id/effective-configA channel is where people reach an agent — a web widget, WhatsApp, email, Telegram, Teams, Slack, SMS or the Workspace.
hive_pk_…, origin allow-list) and a WhatsApp Cloud API number, both routed to the same published agent./v1/embed-keys /v1/channelsA knowledge source is a system agents read rather than act on: its content is indexed into a knowledge base and searched with citations, with source permissions preserved.
kb.search./v1/knowledge-bases /v1/knowledge-bases/:id/connectors /v1/knowledge-bases/:id/documents/:docId/aclsThe event seam: triggers start runs into Agentic Workforce ME, webhooks notify your systems out of Agentic Workforce ME.
invoice.received trigger (kind: webhook) fired by your ERP with an HMAC signature; a run.completed outbound webhook back to the ERP when the agent finishes./v1/triggers /hooks/:triggerId /v1/webhooksTools are not a fifth type: they are what a connector exposes and what a grant allows an agent to do — the unit of permission, approval and audit. They are documented with connectors on Connectors, tools & grants.
The same four layers the product website draws: people arrive through channels, agents on your org tree do the work, everything important passes the trust layer, and the systems, knowledge and keys sit at the bottom — searched, granted and unlocked only at the moment of use. Integration types map onto the first and the last layer; the trust layer is what makes them safe.
Web widget, WhatsApp, email, Telegram, the Workspace. Every door opens the same kind of run — same agent, same tools, same approvals, same trail. Beside them, triggers start runs from events and schedules instead of a person typing.
Published agent manifests on your tenant → department → section → unit tree. An agent’s effective tools are the tools its grants allow, and nothing more.
One door for every tool call: schema validation, the grant check, the approval policy check, then the audited execution with the connection’s credentials decrypted only for that call. Runs, steps and outbound webhooks are recorded here.
Connectors (MCP servers, databases, remote agents, HTTP APIs) expose the tools agents act with; knowledge sources (uploads, SharePoint, Confluence, Google Drive, S3, websites) are indexed into knowledge bases agents read with kb.search. The model never holds a credential.
One sentence each, exactly as the console uses them. The longer forms live on the type pages.
A connector is how Agentic Workforce ME reaches one of your systems — its transport, its authentication and the tools it exposes.
A tool is one operation an agent may perform through a connector, validated against its schema and gated by the Tool Gateway.
A channel is where people reach an agent — a web widget, WhatsApp, email, Telegram, Teams, Slack, SMS or the Workspace.
A trigger starts a run from an event or a schedule instead of a person typing — a signed webhook, a cron, a system event.
An outbound webhook is how Agentic Workforce ME tells your system what happened — run completed, run failed, approval requested — signed and retried.
A knowledge source is a system agents read rather than act on: its content is indexed into a knowledge base and searched with citations, with source permissions preserved.
interrupt() — so nothing executes while a named person decides. Database writes are force-gated. Read more →Today: agents consume MCP servers — yours, over Streamable HTTP, with the tools they expose granted per agent (host an MCP server). MCP is a transport one connector kind uses, not a category of its own: a database connector, a remote agent and an HTTP API sit beside it and pass the same gateway.
Also today: Agentic Workforce ME is itself an MCP server for the agents a tenant explicitly exposes — each appears as the tool hive.<agent-slug> (plus hive.<agent-slug>.<skill> per named skill) at POST /v1/mcp to Claude, OpenAI, Copilot Studio, Foundry or any MCP client, and every call is a real, gated run.
Next: connector tools, resources or prompts served over MCP. The MCP server offers exposed agents as tools only — it is a roadmap item, listed as one below.
Everything in the first list is in production. Everything in the second carries the label Next wherever it appears — in the console, on the website and on these pages — and is never described as available.
query.execute is force-gated)The 2026-09-04 console release added a small API under /v1/integrations/* so tooling can see what the Integrations hub sees. Every row below is available — available in the console since the 2026-09-04 release. The phase column is the console’s release order: Now-A (catalog and health checks) and Now-B (hub payload, attach, connected systems). Every existing endpoint in the REST reference is unchanged.
| Method | Path | Phase · status | Purpose |
|---|---|---|---|
| GET | /v1/integrations/catalog | Now-A Available | Connection kinds behind "Connect a system" — MCP server, PostgreSQL / SQL Server / Oracle, remote agent (real systems only; vendor templates are Next) — with registered when the tenant already has one. Masar web sources are not catalog cards: they start from a URL under /v1/masar/* and attach with connector.kind = "masar". |
| POST | /v1/integrations/health/:target_kind/:id/check | Now-A Available | On-demand health probe for an MCP server, connection, database connector or remote agent (admin, rate-limited). |
| GET | /v1/integrations/overview | Now-B Available | The hub payload: connectors with health and counts, knowledge sources; channels and automation for admins. |
| POST | /v1/integrations/attach | Now-B Available | One call for wizard step 4: grants + approval policies + draft-manifest merge, optional per-agent publish. |
| GET | /v1/agents/:id/connected-systems | Now-B Available | Per-agent view: each declared tool with Granted / Approval, plus channels, knowledge and triggers. |
The console, the website and this portal are checked against the same frozen glossary. If a word here differs from what you see in the console, the console is one release behind.
| Retired | Replace with | Where it still lives (allowed) |
|---|---|---|
| "Communication gateways" | Channels | nowhere in prose |
| "Connector" for a knowledge source | Knowledge source | API path /v1/knowledge-bases/:id/connectors, table kb_connectors |
| "Database connectors are a fourth tool source" | "Databases are one connector kind" | nowhere |
| "MySQL" as a supported database | Postgres, SQL Server, Oracle (MySQL = Next) | nowhere as "true today" |
| "Tools" as the page/hub name | Integrations | route /tools |
| "Webhook" for an inbound trigger | Trigger (kind: webhook) | triggers.kind='webhook' |
| "MCP servers" as a category | Connectors (kind: MCP server) | table mcp_servers, /v1/mcp-servers |
| "Needs re-authentication" | Credentials rejected | code needs_reauth |
| "under five minutes" (marketing) | "in a handful of steps" (until measured in QA) | — |