# Queues

> For the complete documentation index, see [llms.txt](https://docs.lertha.com/llms.txt).
> Any documentation page is available as raw Markdown by appending `.md` to its URL.

> How work finds a worker.

Every run is started on a **queue**, and a **runner** polls one queue for the task and flow
types registered on it. The orchestrator matches the two; nothing is pushed to a worker, workers
pull.

```kotlin
val runner = connection.runner("lab").apply {
    register(GreetingTask)
    register(AgentRun)
    start()
}
```

## Properties

- **Registration is fixed at boot.** Register everything, then `start()`. Registering afterwards
  is an error, so a queue's set of types is visible in one place.
- **A queue does not care which build is polling.** Two builds on one queue is version skew; see
  [Determinism](/concepts/determinism).
- **No head-of-line blocking.** A slow task does not hold up the others on the same queue.
- **A task inside a flow runs on the flow's queue** unless `TaskOptions.queue` says otherwise.
  That is how a flow on the platform's queue can call a task on the ML team's queue.

## Naming

One queue per deployable worker is the simple rule: `gateway`, `ml`, `outbound`. A queue name is
part of the run's identity in the UI, so choose it once.

**Remember:** the queue is the boundary between who asks and who does.