AI Workers
An AI worker is the operating unit responsible for a specific business task. When outputs and responsibilities differ — for example, inquiry handling, report creation, and sales research — give each its own worker.
Overview
For each worker, configure the instructions that convey purpose, the model to use, the knowledge it can reference, the skills and integrations that extend its capabilities, and the triggers that start it automatically. Use the tabs in the settings screen to assign only what the task actually needs.
Basics
How to split workers
Use separate workers for tasks with different outputs and responsibilities — for example, inquiry handling, weekly reports, sales research, and accounting review. Overloading a single worker makes instructions vague and makes it hard to tell whether bad output came from instructions, knowledge, skills, or integrations.
What to put in instructions
On the Instructions tab, write the goal, audience, output format, knowledge to reference, tools the worker may use, prohibited actions, and conditions for asking a human to confirm. For workers started from Slack or another inbound channel, also define when to ask clarifying questions, since input from those channels is often short.
Assign per task
Assign only what the task actually needs from the settings tabs. • Skills: repeatable procedures the worker should follow • Knowledge: documents to reference (selected by folder) • Integrations: MCP, Composio, or native connection profiles • Triggers: schedules or inbound-channel conditions that start the worker • API calling: outbound requests to external systems Examples: support workers need FAQs and response rules; sales workers need product materials and a customer database; accounting workers need invoices and supporting documents.
Before going to production
Before production use, run at least one test from manual chat, from a trigger, and from each inbound channel (Slack, etc.). If output differs from what you expected, review the instructions, knowledge, skill assignments, and integration permissions first — change the model only after these are confirmed.
Checklist
- Does the worker name make the task obvious at a glance? (e.g. it contains the task name, like "Customer Inquiry" or "Weekly Report")
- Are the assigned skills, knowledge, and integrations limited to what this task actually uses?
- Have you tested at least one realistic success path and one exception path (e.g. vague request, or missing input) with production-like inputs?