# What is Worker?

Also called worker process, worker pool, consumer.

A worker is a process that pulls units of work from a queue or schedule and executes them outside the request and response path. Workers are typically run as an interchangeable pool, so capacity is adjusted by changing how many exist and how many items each handles at once. They are the standard place to run long jobs such as agent runs, report generation, and data synchronization.

A worker's basic loop is to claim an item, execute it, and acknowledge completion. If the worker dies before acknowledging, the item becomes visible again and another worker takes it, which is what makes the pool tolerant of individual failures. Because the same item can therefore run more than once, worker tasks should be written to be idempotent or to detect prior partial completion.

Sizing a pool involves two independent numbers. The count is how many worker processes exist, and per worker concurrency is how many items each handles simultaneously. Tasks that mostly wait on network calls, which describes most agent work, can carry high per worker concurrency because they release the processor while waiting. Tasks that are computationally heavy usually need low concurrency and more processes.

Isolation is the reason most production systems run several worker pools rather than one. A pool dedicated to fast notification sends is not blocked by a pool running multi minute agent tasks, and a pool for one tenant class cannot consume all the capacity belonging to another. Isolation also allows different timeout, retry, and scaling policies per class of work.

Workers need their own operational surface, since nothing about them appears in web request metrics. Useful signals include items processed and failed per unit time, execution duration distributions, how long items waited before being claimed, restarts, and whether workers exit cleanly when asked to stop so in flight work is finished or safely returned rather than lost.

## Key points

- Executes queued or scheduled work outside the request path.
- Unacknowledged work returns to the queue when a worker dies.
- Capacity is process count multiplied by per worker concurrency.
- Separate pools isolate fast jobs from long running ones.
- Needs its own metrics; web request dashboards do not cover it.

## In practice

An agent platform runs two worker pools. One handles short jobs such as sending notifications, with many processes and low per process concurrency. The other runs agent tasks that can take several minutes and mostly wait on model and tool calls, so each process handles a dozen at once. During a deploy, workers stop claiming new items, finish what they hold, and exit, so no agent run is cut off mid execution.

## Related terms

- [Queue](/en/glossary/queue)
- [Concurrency](/en/glossary/concurrency)
- [Autoscaling](/en/glossary/autoscaling)
- [Throughput](/en/glossary/throughput)
- [Dead Letter Queue](/en/glossary/dead-letter-queue)

[Back to the AI Glossary](/en/glossary)