Glossary

Task queue

The thing that lets a request survive the process that made it.

Definition

A task queue is a durable list of units of work that producers append to and worker processes claim from, decoupling the moment work is requested from the moment it is executed. Queues give a system retries after failure, control over how many jobs run at once, tolerance for bursts of demand, and a record of work that outlives the process that requested it.

Field: Distributed systems
Common implementations: SQS, Celery, Sidekiq, Postgres
Key guarantee: Work survives a crash

What a queue actually buys you

The naive alternative is doing the work inside the request that asked for it. That works until the work takes longer than a request should, until the process restarts mid-way, or until a thousand requests arrive at once. A queue converts the work into a durable record, so the request returns immediately and the execution becomes someone else's problem, specifically a worker's.

Everything else queues are praised for follows from durability. Retries are possible because the job still exists after a failure. Concurrency limits are possible because a fixed number of workers claim from one list. Backpressure is visible because the queue length is a number you can watch.

The properties that matter when choosing one

Delivery guarantee
At-least-once is the norm, which means jobs can run twice and handlers must be idempotent. Exactly-once is mostly a marketing claim about a system that does deduplication for you.
Claiming
How a worker takes exclusive ownership of a job. Usually a conditional update or a visibility timeout, so two workers cannot claim the same item.
Retry and backoff
How many attempts, how long between them, and where a job goes when it has exhausted them, normally a dead-letter queue somebody actually monitors.
Durability
Whether an enqueued job survives a restart of the broker. In-memory queues are fast and lose work; database-backed queues are slower and do not.

Commonly confused with

Term	What it is	The difference
Message bus / pub-sub	Broadcast of events to many subscribers	Fan-out to any number of listeners. A task queue delivers each job to exactly one worker.
Cron	Time-triggered execution of a fixed command	Triggered by the clock, not by demand, and with no per-item state.
Event stream	An ordered, replayable log of events	Consumers track their own position and can replay history. A queue item is claimed and removed.
Thread pool	In-process concurrency across worker threads	Lives and dies with the process. Nothing survives a restart.

Why agent systems depend on them

Agent work has exactly the shape a queue is built for: it takes minutes rather than milliseconds, it fails in ways worth retrying, it must not run twice on the same task, and it has to keep going after the person who requested it closes their laptop. Running an agent inside a web request is the single most common architectural mistake in early agent products.

Polaris uses a Postgres table called agent_jobs as its queue. A runtime service polls it, claims a job with a conditional update so two machines cannot take the same one, retries a failed job up to two further attempts, and writes results back to the same database the frontend reads. The queue contract is deliberately runtime-agnostic, so the machine behind it can be replaced without touching the product.

Agent runtime

Not the model, not the framework: the thing that actually runs the job.

Headless agent

Nobody is typing at it, so its output is actions and artefacts rather than replies.

Agent orchestration

Deciding which agent does what, in what order, and what happens when one fails.

Work log

The record that makes an unwatched run reviewable afterwards.

How long an agent session can run, and what happens when it ends

Every agent runtime has bounds. The useful thing a vendor can do is tell you what they are.

What keeps running after you close the lid

The honest version: nothing on your laptop survives, so the work has to not be on your laptop.

Questions people ask

+Can a database table be a task queue?

Yes, and for most workloads it is the right choice. A Postgres table with a status column and a conditional claim gives durability, retries and exact ordering with no extra infrastructure. Dedicated brokers earn their operational cost at throughputs most products never reach.

+What happens if a worker dies mid-job?

That is what claiming with a timeout is for. The job stays in the queue with a claimed timestamp, and if it is not completed within the timeout it becomes claimable again. This is exactly why handlers must tolerate running twice.

+Do task queues make agents slower?

They add a small scheduling delay, typically seconds, and remove the far larger risk of losing a multi-minute job to a restart. For work measured in minutes, the trade is not close.