Run Workflows
If your team has built an internal automation (a data pipeline, a report generator, a ticketing flow), you can call it from Work by selecting it from the + menu. Pick one, prompt naturally, get the result back in the chat. No CLI, no API call.
Workflows aren't built inside Work. They're built in Mistral's Studio environment by developers, then published as Chat-compatible assistants that surface in Work. If you're a developer building or publishing Workflows, see Conversational Workflows in the Studio API docs.
How Workflows work in Work
- Developers in your organization build Workflows in Studio and publish them as chat-compatible assistants.
- You see those Workflows in Work's tool menu, ready to attach to any chat.
- When attached, Work calls the Workflow as part of its reasoning, like any other tool, with the Workflow's name surfaced in the chat so you always know which one ran.
The Workflow handles its own inputs, its own logic, and its own output format. Work routes your prompt to it and renders the result back in the chat.
Using a Workflow in a chat
- Click the
+icon in the chat window. - Select
Workflowsfrom the menu. - Pick the Workflow you want to run from the list.
- The Workflow name appears as a tag in the chat input, confirming it's attached.
- Send your prompt. Work calls the Workflow immediately, alongside its thinking chunk.
Once the Workflow runs, the tag also appears above your message in the chat history, so you can scroll back and see which Workflow was used at each step.
What you see during a run
A typical Workflow call surfaces:
- Thinking chunk: Work reasons about what arguments to pass to the Workflow based on your prompt.
- Workflow started:
{workflow-name}: confirmation that the Workflow has been invoked. - Workflow output (or failure): the result rendered in the chat. Some Workflows render inline; others may open in Canvas.
- Workflow failed:
{workflow-name}: if the Workflow can't run (missing access, invalid input, tier restriction), the error is reported back.
Example, a Workflow that fails because of a tier restriction:
Workflow started: vibe-nuage
Your account tier (free) does not have access to this feature
Workflow failed: vibe-nuageWork reads the failure and surfaces it back to you in plain language:
The workflow failed: your free account tier does not have access to this feature.
Skills vs. Workflows
Both extend Work's capabilities, but they're different shapes for different jobs:
| Skills | Workflows | |
|---|---|---|
| What it is | Instructions + resources (a SKILL.md and optional files) | A coded process built in Studio |
| Who creates it | Any user, often from a chat | Developers in Studio |
| What it does | Tells Work how to approach a task | Runs deterministic logic and returns a structured output |
| Best for | Style, procedure, checklist, repeatable method | Data pipelines, automations, integrations with internal systems |
| Triggered by | Auto-match on description, slash command, or natural reference | Explicit selection via + > Workflows |
Use a Skill when you want Work to behave a certain way. Use a Workflow when you want Work to call something that already exists.
Limitations and availability
- Workflows must be published to your workspace by a developer in your organization. If you don't see any Workflows in the menu, ask your team's Studio developer or your workspace admin.
- Some Workflows may be gated by account tier or organization plan. Failures of this type appear in the chat with a clear reason.
- Workflows are invoked explicitly via the
+menu. Work doesn't auto-trigger them based on the prompt (unlike Skills).
For developers
If you're building Workflows that should appear in Work:
- See Conversational Workflows for the API and concepts.
- See Publish in Vibe for the requirements (workflow must return a
ChatAssistantWorkflowOutput). - See Forms and confirmations, Progress tracking, and Canvas for richer UX in the chat.