Orchestrate Agent Work with Queues, Not Endless Loops

An agent loop repeatedly sends work to a model until a stopping condition is reached. That mechanism can be useful, but it is not the complete architecture for agentic engineering. Most software work is better represented as a queue of tasks that are explored, prioritized, implemented, reviewed, and removed when complete.

A queue matches how development teams already operate. Project managers, users, telemetry, and engineers add work. Multiple developers or agents take items from the queue. Each item moves through a sequence of states until it is resolved.

A simple loop may repeatedly pass the same prompt to an agent in a `while` structure and rely on the agent eventually declaring the task complete. The useful property is that the agent can continue working without a human present. However, away-from-keyboard execution does not require one endless loop.

A queue-based workflow can use repository issues and labels as state. For example:

1. A bug report or feature request enters the backlog.
2. An "explore" label triggers an agent to inspect feasibility and relevant code.
3. The exploration returns findings and may place the item back in the queue.
4. An "implement" label triggers a sandboxed agent to make the change.
5. A review step checks the result.
6. The task leaves the queue when the pull request is merged or the issue is closed.

Multiple agents can pick different items from the queue. Any developer can add the label that starts the next step. This resembles a team of workers operating from a shared backlog rather than one agent running a private, permanent cycle.

The queue can also be event-driven. An observability system may detect a production problem and create an issue automatically. An exploration agent can return structured information such as whether the bug is understood, whether an immediate fix is safe, or whether human judgment is required. The result determines the next state.

Queue-based orchestration preserves prioritization. When fifty issues exist, the human or team can decide that only three are critical. An endless agent loop does not naturally represent that decision authority.

Queues also avoid paying for continuous activity when no useful event has occurred. A task runs because something entered the system, not because an agent has been instructed to consume tokens forever.

The model also matches collaborative engineering. Multiple people and agents can participate, tasks can be inspected at each state, and work can be paused or redirected without terminating an opaque process.

Build a bounded agent queue with explicit states:

1. Intake. Create an issue from a user report, telemetry event, feature request, or human

observation.

1. Triage. Decide how important the item is and whether it should advance. Keep prioritization under

human or clearly defined organizational control.

1. Explore. Let an AFK agent inspect the codebase, investigate the problem, and describe possible

changes.

1. Classify. Require structured output indicating whether the item is understood, whether it can be

implemented automatically, and where human input is required.

1. Implement. Trigger a sandboxed agent only after the task has adequate scope and acceptance

criteria.

1. Review. Run automated checks and produce a review recommendation.

1. Decide. Auto-merge only classes of change that have earned that level of trust; otherwise present

the completed package to a human.

1. Close and learn. Remove the item from the queue and capture any system improvement revealed by

the work.

This workflow can give the human a much richer starting point. Instead of receiving only a raw bug report, the human can receive the report, the codebase exploration, the proposed fix, the completed implementation, and a review summary.

A loop is not inherently useless. It can be an internal mechanism for completing a bounded task. The mistake is treating a single loop as the whole operating model for a team or product.

A queue still needs governance. Someone must decide what enters, what is important, which items can advance automatically, and when a task is genuinely complete.

Represent agentic development as a prioritized queue of bounded tasks. Use loops inside tasks when useful, but use explicit states, triggers, and decision points to coordinate the overall system.