Agent Queues Need Backpressure

An agent queue looks harmless until it starts succeeding.

At first there are only a few tasks. The agent wakes up, reads the next item, does the work, and reports back. The team adds another workflow because the first one saved time. Then a nightly job finds hundreds of candidates. A retry policy wakes failed tasks. A manager asks for higher throughput. A second agent joins the pool.

The system is still “just a queue,” but the queue has become the control surface for demand, cost, authority, and risk.

Without backpressure, an agent queue converts every upstream impulse into downstream motion. It starts more work than the organization can inspect, spends tokens on low-value tasks while high-value tasks wait, retries failures that need design changes, and hands humans review piles that are too large to review well.

Backpressure is the architecture that lets the system say: not yet, not this way, not at this priority, not without more evidence, or not until a human clears the bottleneck.

That is not friction. That is control.

Intake Is a Product Decision

The first form of backpressure is deciding what enters the queue.

Many AI systems treat discovery as entitlement. If a classifier detects a possible opportunity, the task is created. If a user asks for a broad batch, every item becomes work. If an upstream system emits an event, the agent receives it.

That is a recipe for noisy autonomy.

Queue intake should apply admission rules: value, urgency, evidence quality, owner, risk tier, duplicate detection, and readiness. A task that lacks the required source data should not compete with a task that is ready to execute. A low-confidence candidate should not be promoted to the same lane as a verified obligation.

Admission control turns the queue from a dumping ground into a promise. Items inside it are work the system is prepared to handle.

Priority Must Reflect Consequence

Agent queues often inherit priority from arrival time. That is fine for equal work. AI work is rarely equal.

A stale support draft, a risky code migration, a security alert, and a formatting request should not occupy the same lane simply because they arrived in that order. Priority should consider customer impact, deadline, confidence, cost, required human review, and the consequence of waiting.

The queue should also make priority legible. If a task is delayed because it requires a scarce reviewer or an expensive model, that should be visible. Otherwise people assume the agent is slow when the real bottleneck is policy.

Good priority design prevents autonomy from serving the loudest source instead of the most important outcome.

Concurrency Is Authority

Increasing worker count is not a neutral scaling operation.

More concurrent agents means more tool calls, more context assembly, more writes, more locks, more review items, and more simultaneous claims on shared state. If the system can edit repositories, message customers, update tickets, or spend money, concurrency is a form of authority.

Backpressure should limit concurrency by workflow, tenant, resource, risk tier, and external dependency. A codebase may tolerate one migration agent at a time. A customer account may allow several read-only analyses but only one pending write. A human reviewer may only be able to inspect ten drafts before review quality drops.

The question is not “how many agents can we run?” It is “how many effects can the surrounding system safely absorb?”

Retries Need a Budget

Retries are where agent queues quietly become expensive.

A malformed output triggers another model call. A tool timeout rebuilds the same context. A missing permission causes the agent to try an alternate route. A bad retrieval result produces a new search. Each attempt appears reasonable locally. Together they can overwhelm the queue with work that is not making progress.

Retry policy should distinguish transient failure, permanent failure, unknown effect, and design gap. Transient failures may retry with a small budget. Unknown effects require reconciliation. Permanent failures should stop. Design gaps should create a product issue, not another agent attempt.

The retry budget belongs to the task record. It should include attempts, cost, elapsed time, changed evidence, and why the next attempt is expected to improve the outcome.

If the state is not changing, the queue should stop pretending motion is progress.

Human Review Is a Capacity Constraint

Many teams keep humans in the loop and still overload them.

The agent produces drafts faster than people can review. Review queues grow. Humans skim. Feedback becomes inconsistent. The system records approvals but learns little because the reviewer did not have the time or evidence to judge carefully.

Human review capacity must be part of queue design. If a workflow requires approval, intake and concurrency should respect available reviewer attention. The queue can batch similar items, highlight uncertainty, route by expertise, and pause lower-value work when review load rises.

Keeping a human in the loop is not a control if the loop is flooded.

Backpressure Should Be Visible

A queue that silently delays work feels broken.

A good agent system shows why work is waiting: missing evidence, policy hold, cost budget, reviewer capacity, resource lock, downstream outage, duplicate detection, or risk tier. This helps users trust the delay and gives operators a map of what to improve.

Visibility also prevents pressure from being displaced into prompts. Without a clear queue state, teams ask the model to be “more efficient” or “try harder.” The real fix may be adding a policy lane, a better deduplication key, or a separate reviewer pool.

Backpressure is only useful if people can see where the pressure is.

Dead Letters Are Learning Material

Every queue needs a place for work that cannot continue.

Dead-lettered agent tasks should not disappear into operational shame. They contain the most useful product feedback: missing tools, ambiguous policies, stale source data, fragile prompts, repeated security stops, and cases where the workflow was too broad.

Review dead letters by failure class. Some will become improved runbooks. Some will become new tool contracts. Some will become evaluation scenarios. Some will prove the task should remain human-led.

The queue is not only execution infrastructure. It is an instrument panel for the maturity of the AI product.

Let the Queue Say No

Autonomous systems are often sold as a way to remove waiting. In practice, dependable autonomy requires better waiting.

The system should wait for evidence, capacity, authority, state stability, budget, and human attention. It should reject work that is not ready. It should slow down when downstream controls are saturated. It should stop retries when the remaining uncertainty is not reducible by another model call.

Agent queues need backpressure because autonomy magnifies demand.

The product is not the number of tasks started. It is the number of valuable outcomes completed without losing control.