AI Assistants
AI Assistants are the AI-powered agents that interact with users in Workspace Chat and through integrations such as the Slack app. Each assistant can answer questions, suggest diagnostic tasks, run automation, and recommend next steps — all within the permissions of the workspace and the user.
This page is conceptual: what an assistant is, how it reasons, and what shapes its behavior. For the actual UI — profile names with their exact percentages, the configuration form, and the steps to create or edit an assistant — see Use → AI Assistants.
How an assistant reasons
When you ask a question in Workspace Chat, the selected assistant gathers four kinds of context before answering:
- Production insights — structured results from tasks that have already run in the background.
- Issues — findings already flagged by tasks.
- Knowledge — workspace-authored notes scoped by topic or resource.
- New diagnostic runs — additional tasks the assistant chooses to execute for this question.
It then combines those into a single answer. Two ideas matter for understanding the result:
- Plurality of assistants. A workspace can have multiple assistants, each tuned to a different risk profile and audience (e.g., aggressive triage for an interactive engineer, conservative response for an autonomous webhook). They share workspace data, not behavior.
- Confidence thresholds. Each assistant has its own thresholds for which tasks it considers and which it actually runs. These are the assistant’s primary tuning knob (see below).
Confidence thresholds
Confidence thresholds are the most important conceptual lever for assistant behavior. There are two of them, and they decide different things:
| Threshold | Decides | Effect of raising it |
|---|---|---|
| Filter confidence | Which tasks the assistant considers relevant to a question | Smaller, more focused candidate set. Fewer surprises, but may miss tangentially relevant checks. |
| Run confidence | Which considered tasks the assistant actually executes | Quieter, more cautious investigations. Lower noise, but slower coverage. |
Lower both thresholds and the assistant becomes broader and more eager — useful when a human is sitting at the screen ready to read whatever comes back. Raise both and the assistant becomes more selective — useful when results will fan out to a Slack channel or an incident ticket and false positives are expensive.
This is why a workspace has multiple assistants rather than one: a thorough triage assistant and a conservative auto-responder are not at odds, they live side by side, each correctly tuned for its audience.
The exact numeric defaults for each named profile (Standard, Conservative, Strict, Custom) live in Use → AI Assistants.
Three things shape what an assistant says
Confidence thresholds tune the assistant’s reflexes. The actual content of an answer is shaped by three additional levers your team controls — the levers also discussed under operational context:
| Lever | What it changes | Where it lives |
|---|---|---|
| Rules | Interpretation — what the assistant treats as noise vs signal, what to deprioritize, how to phrase findings. | |
| Commands | Procedure — repeatable investigation workflows; invoked via slash from chat or fired on a schedule. | |
| Knowledge | Context — narrative facts that telemetry cannot supply: ownership, maintenance windows, architecture assumptions. |
Tasks (separate concept — see SLXs and CodeBundles) supply the fresh measurements on which interpretation operates. The Building Operational Context guide shows how to combine all of these in practice.
RBAC, in concept
Assistants are not a side channel that bypasses permissions. Two layers determine what an assistant can do:
- The assistant has its own access level (read-only or read-write), its own task-tag filters, and its own confidence thresholds.
- The user must be assigned to the assistant; their workspace permissions and the assistant’s permissions are intersected.
The intersection is the important property. A read-write assistant assigned to a read-only user cannot perform write actions. A read-only assistant cannot be coerced into a write action even by an admin user. The lower-privileged side always wins.
Three invariants always hold, regardless of configuration:
- Workspace isolation. Assistants cannot cross workspace boundaries or reference resources from other workspaces.
- Secret opacity. Assistants never read secret values; secrets are only injected into task execution through the secure runner pipeline.
- Auditability. Every AI-triggered action produces the same audit log entry as a human-triggered action.
Concrete configuration (form fields, profile presets, percentages, who can change them) lives in Use → AI Assistants.