Agent Queues Need Air Traffic Control, Not Infinite Tabs

The next ugly agent failure is not going to look like one bot making one stupid edit.

It is going to look like twelve smart-enough bots doing individually reasonable things at the same time.

One agent is fixing the bug. Another is refactoring the same file. Another is running tests. Another is retrying a flaky command. Another spawned a helper. Another is waiting on approval. Two more are chewing tokens because nobody cancelled the stale branch. The dashboard says “working.” The repo says “conflict.” The bill says “surprise.”

That is not an intelligence problem.

That is an air traffic control problem.

Agent products need queues, slots, cancellation, leases, budgets, and merge lanes. Not infinite tabs. Not “just run another worker.” Not a happy little swarm animation while the system quietly turns into spaghetti.

Source freshness check: this post was checked on 2026-06-27. The current agent/devtool stack is active right now: Gemini CLI was pushed on 2026-06-26, Claude Code on 2026-06-26, OpenAI Agents SDK on 2026-06-25, GitHub MCP Server on 2026-06-26, LangGraph on 2026-06-25, and MCP on 2026-06-26. The current direction is obvious: agents are becoming execution surfaces around repos, tools, CLIs, MCP servers, memory, and workflows. Once you can launch more than one, concurrency policy stops being boring plumbing and starts being product safety.

Parallel agents are not automatically throughput

Builders love the swarm fantasy.

Run five agents. Run fifty. Let them explore. Let them compete. Let one write tests, one patch the bug, one update docs, one review the diff, one summon a tiny cursed council of subagents.

Cute.

Sometimes parallelism helps. Most of the time, uncontrolled parallelism just moves the bottleneck from “one agent is slow” to “nobody knows what is happening anymore.”

Parallel agents can collide on:

• the same files
• the same branch
• the same database fixture
• the same browser session
• the same MCP server state
• the same issue tracker
• the same deployment environment
• the same human approval window
• the same token budget
• the same reviewer patience

Software teams already learned this lesson with CI, queues, locks, deploy trains, rate limits, and job schedulers. Agents do not magically escape that physics because the button says “AI.”

If anything, agents need stricter control because they can decide what to do next.

A flaky test runner retries the same command.

An agent retries, changes the command, edits the fixture, asks a subagent, reads a doc, opens a PR, and writes a confident summary about how everything is fine.

Every agent task needs a flight plan

Before an agent run starts, the system should know what kind of flight it is clearing for takeoff.

Not a vague prompt. A flight plan.

run_id: agt_run_2026_06_27_1000
kind: repo_patch
priority: normal
requested_by: human_or_system
objective: fix failing billing test and open PR
workspace:
  repo: clord
  branch: agent/billing-test-fix
  file_locks:
    - src/billing/**
    - tests/billing/**
limits:
  wall_clock: 25m
  max_tool_calls: 45
  max_cost_usd: 3.00
  max_subagents: 1
permissions:
  allow:
    - repo.read
    - repo.write.branch
    - test.run
    - pull_request.create
  deny:
    - production.deploy
    - secrets.read
    - billing.write
cancellation:
  cancel_if_branch_changes: true
  cancel_if_human_closes_issue: true
  cancel_if_budget_exceeded: true

That sounds bureaucratic until the first time two agents fight over the same migration file.

Then it sounds like oxygen.

The point is not to make agents slow. The point is to stop pretending “run” is a complete product concept.

A serious agent system needs to answer:

• what is this run allowed to touch?
• what resources does it reserve?
• what is the priority?
• what expires?
• what happens if a newer run supersedes it?
• what happens when the human walks away?
• what happens when the model loops?
• what happens when the tool layer is rate limited?

If your answer is “the user can open the logs,” your product is already late.

The queue is part of the UX

Most agent queues are either invisible or useless.

A task says “queued.” Then “running.” Then maybe “done.”

That is not enough.

Users need to see the airspace:

• which agents are running
• which are waiting
• why they are waiting
• what they are blocking
• what they are allowed to touch
• what they already spent
• which runs are stale
• which runs are superseded
• which one will win if two produce changes

This is not just admin-console nerd stuff. It changes how people trust the product.

If a developer asks an agent to fix a bug, then asks another to investigate the same area, the UI should not happily launch both into the same files with no warning. It should say something like:

Another agent is already holding src/payments/** for PR #482. Start a read-only investigation, wait for that run, or cancel it?

That is a product moment.

That is the difference between “AI magic” and “AI kicked me in the shins.”

Backpressure beats retry storms

Agent systems love to retry.

Model timed out? Retry. Tool failed? Retry. Test flaky? Retry. Network sad? Retry. Human did not answer? Wait and retry. Subagent died? Spawn another.

Retries are useful. Retry storms are how you turn one failure into six failures and a bill.

Backpressure means the system can say no, slow down, or degrade gracefully:

• queue low-priority tasks instead of launching them
• cap concurrent write agents per repo
• make retries consume budget
• pause tasks when tool rate limits hit
• downgrade stale tasks to read-only
• require fresh approval after long waits
• cancel runs when newer context invalidates them
• stop subagent spawning after a hard limit

A good agent product should be proud of refusing work sometimes.

“Not now” is better than pretending the runway is clear while three planes are already trying to land.

Cancellation is a first-class feature

Cancellation cannot be an afterthought.

If an agent run can spend money, hold locks, write files, call tools, or wait for approval, then cancellation needs to be real.

Not “hide the spinner.”

Real cancellation means:

• stop model generation
• stop tool calls
• release locks
• revoke leases
• kill child processes
• cancel subagents
• mark produced artifacts as abandoned
• explain what changed before cancellation
• produce a receipt

Without that, every agent queue becomes a graveyard of zombie work.

The nasty cases are not hard to imagine:

• a run waits overnight with stale assumptions
• a human fixes the issue manually while the agent keeps working
• a newer run supersedes an older run but both keep editing
• a subagent keeps a browser/session/tool lease alive after the parent is cancelled
• a queued task starts after the branch moved and applies yesterday’s plan to today’s repo

That last one is how you get a “successful” agent run that should never have started.

The cancellation path should be tested like the happy path.

If your agent cannot stop cleanly, it is not autonomous. It is just unattended.

Merge lanes matter more than leaderboards

The industry is still too obsessed with agent benchmarks that reward completing isolated tasks.

Useful, sure.

But real product pain shows up in shared state.

Can five agents work around the same repo without trashing each other? Can a product explain why one run waited and another launched? Can a human cancel a stale plan and trust it actually stopped? Can the system prevent two agents from opening competing PRs against the same migration? Can it cap cost before a retry storm becomes a finance surprise?

That is the benchmark builders should care about.

Not just “did the agent solve the task?”

“Did the agent solve the task without turning the surrounding system into a haunted airport?”

The minimum viable control tower

If you are building agentic devtools, do not wait until customers are running a hundred agents to design this.

Start with a small control tower:

1. Task identity — every run has an ID, owner, objective, priority, and expiry.
2. Resource claims — repos, files, environments, browser sessions, tool scopes, and external systems can be reserved or marked read-only.
3. Concurrency limits — cap write agents per repo/project/tool surface.
4. Budgets — time, tool calls, tokens, dollars, retries, and subagents.
5. Freshness checks — queued work revalidates context before starting.
6. Cancellation receipts — stopping a run produces a clear record of what happened and what was revoked.
7. Conflict policy — decide which run wins, waits, downgrades, or dies.
8. Human-visible queue — show why work is waiting and what it blocks.

This is not anti-agent.

This is how agents become boring enough to trust.

The future is not one giant omniscient bot doing everything at once. It is a managed fleet of narrow runs, each with a flight plan, budget, permission lease, and clean landing path.

More agents can mean more leverage.

But only if somebody controls the damn airspace.