Workers

A worker is the process that actually runs your code. Workers connect to the Workflows platform, register the workflows and activities they know about, and poll for tasks. When the platform schedules a workflow step or activity, an available worker picks it up and executes it.

Workers are stateless and interchangeable. Any worker that has registered a given workflow or activity can execute it — there is no affinity between a specific execution and a specific worker. This means you can run as many workers as you need, and the platform distributes tasks across them automatically.

When you start a worker, your workflows and activities are automatically registered with the platform. There is no separate registration step or deployment manifest to maintain.

Workers are also fault-tolerant from the platform's perspective: if a worker crashes mid-execution, the platform detects the absence of heartbeats and reassigns the in-progress task to another worker. The workflow resumes without data loss, because the event history contains everything needed to reconstruct state.

Call run_worker() with the list of workflow classes the worker should handle. The worker connects to the platform, registers everything, and starts polling for tasks. It runs until the process is stopped.

import asyncio
import mistralai.workflows as workflows

async def main():
    await workflows.run_worker([MyWorkflow])

if __name__ == "__main__":
    asyncio.run(main())

import asyncio
import mistralai.workflows as workflows

async def main():
    await workflows.run_worker([MyWorkflow])

if __name__ == "__main__":
    asyncio.run(main())

The MISTRAL_API_KEY environment variable determines which workspace the worker connects to. All workers sharing the same key share the same task queue.

MISTRAL_API_KEY=your_key uv run python my_worker.py

MISTRAL_API_KEY=your_key uv run python my_worker.py

1. A workflow execution is triggered (via API, schedule, or the console)
2. A task is added to the queue
3. An available worker picks up the task and starts executing the workflow
4. When the workflow calls an activity, an activity task is added to the queue
5. Any available worker picks up the activity task and executes it
6. The result is recorded in the execution history
7. The workflow resumes with the activity result and continues

To verify that a worker is connected and inspect its configuration, call the whoami endpoint:

GET /v1/workflows/workers/whoami

GET /v1/workflows/workers/whoami

{
  "scheduler_url": "...",
  "namespace": "mistral-workflows",
  "tls": false
}

{
  "scheduler_url": "...",
  "namespace": "mistral-workflows",
  "tls": false
}