# Background runs on one session now execute one at a time, in the order you sent them

> Agno AgentOS holds each queued background run until the earlier runs in its session have finished, so every run starts with the history the previous one wrote. QueueConfig.queue_per_session controls it and is on by default for agents, teams and workflows.

- Published: 2026-10-16
- Author: Yash Pratap Solanky
- Categories: Changelog
- Canonical: https://www.agno.com/blog/background-runs-on-one-session-now-execute-one-at-a-time-in-the-order-you-sent-them
- Markdown: https://www.agno.com/blog/background-runs-on-one-session-now-execute-one-at-a-time-in-the-order-you-sent-them.md

With `QueueConfig(durable=True)`, Agno's AgentOS stamps every background ticket with a `session_seq`, and a worker claims it only once no earlier run in the same session is still queued, running or paused. The rule covers agents, teams and workflows alike.

<Video src="/videos/changelog-queue-per-session-terminal.mp4" />

Picture a chat client that lets someone send a second message before the first answer arrives. Earlier releases ran both turns side by side: the second loaded its history before the first had written anything, session state went to whichever run saved last, and answers could land out of order.

A waiting run stays queued and spends no attempt and no worker slot. Runs on other sessions keep executing concurrently, up to `max_concurrency`. A run paused for human approval holds its session until someone continues or cancels it, since the runs behind it probably depend on its outcome, and a continued or retried run keeps its place in line.

We submitted three background runs to one session and one to another on an embedded Postgres, with a stub model that waits one second standing in for a real one.

![Real output timeline of four background runs, each model call one second long. Before, on earlier releases, runs A, B and C on session chat-1 and run D on chat-2 all start together at about one second. Now, runs A and D start together right away, run B on chat-1 starts after A ends, and run C starts after B ends. A poll of run B while run A is running returns status PENDING with waiting_on set to run A's id.](https://www.agno.com/images/v3-1-4-queue-per-session.png)

The setting is on by default:

```python
from agno.os import AgentOS, QueueConfig

agent_os = AgentOS(
    agents=[agent],
    db=db,
    queue=QueueConfig(durable=True),  # queue_per_session=True is the default
)
```

`GET /config` reports what the queue actually enforces, so a client can discover it without admin access:

```text
GET /config queue: {"durable": true, "queue_per_session": true}
```

Pass `queue_per_session=False` to let runs on one session execute concurrently again. Claude, Codex and the other external agents stay serialized either way, because their sessions refuse a second concurrent turn. A custom queue store opts in by setting `serializes_sessions = True`; without it, the worker logs that marked tickets run concurrently and `/config` reports `queue_per_session: false`.

The line only covers runs that go through the durable queue. Media uploads, non-JSON payloads and direct non-background calls run outside it, so keep them off sessions that also take queued runs.

See the [cookbook](https://github.com/agno-agi/agno/blob/main/cookbook/05_agent_os/background_tasks/queue_per_session.py), and learn more about the [durable queue](https://docs.agno.com/agent-os/background-execution/durable-queue) in the documentation.