Set up worker pools

Solo flow (default)

When you run cori run, Cori spins up an ephemeral in-process worker for that run. Nothing else is needed.

This works fine for local development and single-machine setups.

Keep a machine online: cori work

If you want a machine to stay available between runs — so that other machines can dispatch work to it — run:

cori work

This starts a long-lived worker that listens on your identity-derived task queue. It stays running until you stop it.

Named shared pools: cori work --shared

For multi-machine setups where you want to dispatch specific steps to specific machines (e.g., a machine with Notion credentials, or a machine with access to a private network):

# On the machine that should handle Notion steps:
cori work --shared notion-pool

# On the machine that should handle data processing:
cori work --shared data-processing-pool

A workflow can then declare that a step should run on a named pool by setting the step's task_queue. Cori dispatches that step to any machine running cori work --shared <pool>.

Example scenario:

Machine A has Notion credentials configured. You run cori work --shared notion-pool on it. Machine B has no Notion access. A workflow running on Machine B has an mcp_tool step that writes to Notion. By declaring task_queue: notion-pool on that step, it gets dispatched to Machine A.

Production configuration

For shared workers in production, point all machines at the same Temporal cluster:

# ~/.cori/config.toml on each machine
[temporal]
host = "temporal.mycompany.com:7233"

See Configure Temporal.

Checking worker status

cori status

cori status shows the current endpoint, your identity, and which workers are currently online. If a workflow hangs with a task-queue-related error, run cori status to check whether the expected worker is online.

Not in v1

There are no Cori cloud workers. All workers are machines you control running cori work or cori work --shared. There is no hosted worker infrastructure.