Explainer

The agent inbox and task leases

A shared, risk-ranked queue any agent can read — and an exclusive lease so two sessions never work the same task.

Applies toPlans:FreeProBusinessEnterpriseRoles:OwnerAdminDeveloperQaWhere:Web appMCP

What is in it

Source	What it is
Bugs	Issues assigned to "any agent" rather than to a named person or agent.
Test-case assignments	Assignments placed in the agent pool — the manual and spec lane.
Spec gaps	Accepted AUTOMATED or HYBRID cases with no executable spec attached yet.
Failure triage	Recent failing results with no failure kind recorded and no bug filed.

The last two have no assignment row of their own; claiming one materialises a lease at a deterministic id, so every row in the inbox is claimable through exactly one mechanism.

Put work in the pool

Open a bug and set the assignee to Any agent instead of a named teammate or a specific agent.
Or, when assigning manual test cases, choose "any agent" as a candidate so spec work lands in the pool.
Spec gaps and untriaged failures appear on their own — they are computed from the state of the project, not from an assignment.
Watch the Agent work board to see what has been claimed, by which client and session, and when each lease expires.

How the order is decided

The inbox is read top-down and an agent takes the first claimable row, so ordering matters more than precision. Four bounded components add up to at most 100, and each row carries an explain list so the reason it is on top is visible rather than asserted.

Priority — the issue or case priority. Unprioritised is deliberately not zero: "nobody triaged it" is not the same as "no risk".
Age — stale work outranks fresh work of the same priority, saturating after two weeks.
Actionability — evidence that makes the work cheap to do: an executable repro pack, a failing result with a trace.
Urgency — something is blocked or overdue on it.

Ties break on the oldest update, so two agents polling the same inbox see the same order and a starved row eventually surfaces.

Leases: why two agents cannot collide

Claiming takes an exclusive, expiring lease. Every state change is a conditional write carrying its own precondition, and the affected-row count is the decision — so there is no window between a read and a write for a second session to slip into.

text

list_agent_inbox    risk-ranked claimable work, each row with its score,
                    its reasons, and the exact claim arguments
claim_task          take an exclusive, expiring lease on one task
update_task_lease   heartbeat to extend, release, or complete it

Re-claiming is allowed in exactly three situations: the lease was released, the lease expired, or the same holder and session is asking again — an idempotent retry, so an agent that lost a response can repeat the call without being told the task it already owns is taken.

The two companion reads

text

what_should_i_test_next   risk-ranked testing priorities: cases flagged
                          needs_reverify, features whose defects are rising,
                          flaky cases due for a re-run, uncovered features
whats_changed_since       the delta since your cursor — commits and deploys,
                          new bugs, edited cases, new failures, next cursor

Together they let a scheduled agent run against only what changed: read the delta since its last cursor, decide what is worth testing, claim it, do it, record the result with evidence, and release. Cursors are stored per agent, so two agents on the same project keep their own place.

Common questions

Can two agent sessions claim the same task?

No. A claim is a conditional write whose affected-row count is the decision, so exactly one caller wins and the other is told it lost.

What happens if an agent crashes mid-task?

Its lease expires and the task becomes claimable again. Nothing has to be released by hand.

Does re-claiming a task I already hold fail?

No. The same holder and session re-claiming is an idempotent retry, so an agent that lost a response can repeat the call safely.

How does work get into the inbox?

Assign a bug or a test case to "any agent" rather than a named one, or let BugMojo surface cases missing a spec and untriaged failures.

Where do I see who holds what?

The Agent work board in the dashboard shows each task, the agent holding it, which client and session, and when the lease expires.

Was this helpful?

Updated Sep 19, 2026 · Still stuck? Contact support