Animus/ Blog
runtime ↗animus.team ↗github
← All posts
FIELD NOTES · 10 min read · The Animus Team

How queues turn coding agents into a reliable delivery system

Coding agents are useful in a chat tab. They become dependable when you stop treating them like chat tabs and start treating them like workers in a delivery system. The payoff is simple: a solo founder or small team can keep multiple agents moving without losing track of ownership, duplicating work, blowing past capacity, or merging unreviewed changes. The difference is not a smarter prompt. It is an explicit queue, leases, lifecycle states, workflow phases, and an audit trail.

The problem is not agent intelligence. It is delivery semantics.

A one-off coding session can produce a patch, explain a bug, or draft a test. But once you run more than one agent, the hard questions are operational:

  • What work is ready?
  • Which agent owns it right now?
  • How many agents should be allowed to run at once?
  • What happens if one crashes halfway through?
  • Which tasks are blocked, retried, waiting for review, or done?
  • Who changed what, and why?

A transcript does not answer those questions cleanly. It records a conversation, not a delivery system.

Distributed task systems solved this problem long before coding agents showed up. Amazon SQS, Google Cloud Tasks, Celery, and Temporal all center the same basic idea: put work in a durable place, let workers claim it safely, record state transitions, retry failures, and make the system observable.

That is the mental model Animus brings to coding agents. The daemon is the scheduler. The queue is the backlog and lease table. The subject is the human-readable unit of work. Workflow phases are the runbook. Review loops are the safety gates.

In other words, queues turn agents from people in chat tabs into a small production system.

A queue makes the subject the source of truth

When work starts in chat, the transcript becomes the source of truth by accident. That breaks down quickly. A founder should not have to read every message from every agent to know what is happening.

A queued subject gives the system a stable object to manage. The subject says what needs to be done. The queue says whether it is waiting, leased, deferred, held, or ready to dispatch. The workflow records which phase is running. The subject lifecycle tells humans whether the work is ready, in progress, blocked, under review, or done.

That separation matters. The agent can still reason in a conversational loop, use tools, and iterate. But delivery does not depend on a chat window staying open or a human remembering which tab is active.

This is how mature task systems behave. In SQS, a message remains in the queue while a consumer works on it, but it becomes temporarily invisible to other consumers during the visibility timeout. If the worker finishes, it deletes the message. If it does not finish before the timeout, the message becomes visible again and can be retried. Celery makes a similar reliability point: task messages are acknowledged by workers, and if a worker is killed before acknowledgement, the task can be delivered again.

For coding agents, that maps cleanly: an agent leases a subject, runs the assigned workflow phase, writes back results, and either completes the phase or leaves the work recoverable.

Leasing prevents duplicate work without stranding failed work

Without leasing, two agents can pick up the same issue, edit the same files, and create conflicting changes. With a permanent lock, a crashed agent can strand the task forever.

A lease is the middle ground.

The SQS visibility timeout pattern exists to prevent multiple consumers from processing the same message at the same time while still allowing unfinished work to return to the queue. AWS also supports changing the visibility timeout when a task needs more time, which is the same operational shape as a worker heartbeat. Google Cloud Tasks persists asynchronous work in a queue until successful execution or retry exhaustion, with dispatch rate controls and retry configuration built into the service.

Coding agents need the same safety property. One agent should own a subject for a bounded period. If it completes the work, the system records that completion. If it stalls, crashes, or times out, the daemon can recover the subject instead of leaving it trapped in an abandoned session.

There is one important caveat: retries mean work should be repeatable where possible. Cloud Tasks warns that duplicate execution can happen and handlers should avoid harmful side effects. Celery similarly recommends idempotent task functions when using late acknowledgements. For agent workflows, that means phases should be designed so rework is safe: write clear outputs, check current state before acting, and avoid assuming a failed run changed nothing.

Capacity limits keep agents from becoming a new kind of outage

Autonomous coding agents spend real resources. They use model budget, context, CI minutes, branch space, review attention, and repository write bandwidth. If five agents run at once because five chat tabs were opened, that is not parallel delivery. It is ungoverned load.

A queue gives the team a place to enforce capacity.

Google Cloud Tasks describes queues as a way to control dispatch flow, manage delivery rates, configure retries, and smooth spikes. Google SRE’s four golden signals include saturation, which asks how full a service is. As saturation rises, latency and failures often follow. The same idea applies to an agent fleet. Queue depth, active leases, retry rate, and review backlog tell you whether the system is healthy or overloaded.

Celery’s monitoring guide points to the kinds of signals operators actually inspect: ready messages, unacknowledged messages, active tasks, reserved tasks, worker status, task runtime, failures, retries, and task history.

Animus applies that operational thinking to coding agents. The daemon can run a limited number of agents, leave the rest queued, and expose pressure before it becomes chaos. For a small team, this changes the working model from “we opened five prompts and hope none collide” to “we can safely keep agents busy overnight within known limits.”

Lifecycle states make agent work readable at a glance

The biggest productivity gain is not only that agents can work in parallel. It is that humans can understand what is happening without reading every token.

Task systems do this with states and events. Celery exposes task events such as sent, received, started, succeeded, failed, rejected, revoked, and retried. Its monitoring tools can list active, scheduled, reserved, revoked, and registered tasks. Temporal records workflow executions as ordered event histories, which become the source of truth for replay and recovery.

Coding work needs states that make sense to product and engineering leaders, not just infrastructure operators:

  • Ready means the work can start.
  • In progress means an agent has an active lease.
  • Blocked means the agent needs information or hit a dependency.
  • Review means output exists, but should not be accepted yet.
  • Done means the work was accepted.

Those states let a founder scan the board and decide where attention is needed. What is blocked? What is waiting for review? What failed twice? Which subjects are ready for another agent? Which work is truly done?

That is much more useful than a pile of transcripts.

Workflow phases turn autonomy into a runbook

Agents should be autonomous inside a bounded job. They should not have to invent the delivery process every time.

Anthropic’s guidance on building effective agents makes a useful distinction between workflows and agents. Workflows follow predefined code paths that orchestrate LLMs and tools. Agents dynamically direct their own process. Anthropic recommends using the simplest system that works because more agentic systems can trade latency and cost for better task performance. The same guidance notes that coding is a strong fit for agents because code can often be verified with automated tests, agents can iterate on test feedback, and human review remains important for broader system fit.

That is the case for explicit workflow phases.

A small team does not need an agent to decide from scratch whether it should research, plan, implement, test, review, or rework. The system can define those phases. The agent can then operate with freedom inside the phase it was assigned.

For example:

  1. A subject enters the queue as ready.
  2. The daemon leases it to a researcher phase.
  3. The researcher writes sourced findings back to the subject.
  4. A writer or implementer phase uses those findings to produce output.
  5. A test or review phase checks the result.
  6. Failures route to rework.
  7. Approval moves the subject to done.

That structure does not make the agent less capable. It makes the work repeatable.

Review loops are where autonomy becomes delivery

An autonomous agent can generate a lot of output. A delivery system decides what is acceptable.

Anthropic describes an evaluator-optimizer pattern where one LLM call generates a response and another evaluates it, gives feedback, and triggers improvement. The same article points out that coding agents benefit from automated tests and human review. Temporal’s workflow model also supports long-running, resumable processes, which fits review and rework better than a single unstructured conversation.

For coding teams, the lesson is straightforward: implementation should not move straight to done.

It should move through checks. A failing test creates rework. A reviewer request creates rework. A blocked dependency moves the subject to blocked. A passed review closes the subject.

This is how teams let agents run ahead without letting them merge ahead. The agents can produce drafts, patches, tests, migrations, and explanations. The queue and workflow enforce that “done” means accepted, not merely generated.

Auditability is the trust feature

Auditability can sound like enterprise overhead. For a two-person team running coding agents, it is the thing that makes automation safe enough to trust.

Production systems assume crashes, retries, and partial failures. Temporal records ordered event histories so workflow state can be reconstructed and work can resume after a worker failure. Temporal also recommends meaningful worker identity so operational issues can be traced back to a specific worker instance, process, machine, or log stream. Celery’s event stream and Flower monitor expose task progress, history, runtime, worker status, active and reserved tasks, failures, and retries. Google SRE emphasizes monitoring not only for alerts, but also for dashboards and retrospective debugging, especially answering what is broken and why.

Coding agents need the same traceability.

Every automated change should be attributable to a subject, lease, agent identity, workflow phase, tools used, tests run, review result, and final status. That is the difference between “the AI changed something” and “the implementer leased TASK-123, changed these files, tests failed in the test phase, the reviewer requested rework, and the second run passed.”

When the system can tell that story, founders can delegate more work to agents without personally watching every session in real time.

What small teams should do next

If you are a solo founder or small team trying to use coding agents safely, do not start by asking, “How many agents can I run?”

Start with these questions:

  1. What is the unit of work? Use a subject, issue, task, or ticket as the source of truth.
  2. How does an agent claim work? Use a lease, not a permanent lock and not an informal chat assignment.
  3. What states can the work be in? Make ready, in progress, blocked, review, rework, and done visible.
  4. How much capacity is allowed? Cap concurrent agents and watch queue depth, active leases, retries, and review backlog.
  5. What phases must every task pass through? Define the runbook instead of asking each agent to invent one.
  6. What creates rework? Treat failed tests, reviewer feedback, and missing information as explicit transitions.
  7. What gets recorded? Keep an audit trail that ties output back to the subject, agent, phase, and checks.

Animus is built around that model. The daemon schedules work. The queue controls dispatch and leases. Subjects carry the human-readable state. Workflow phases make execution repeatable. Review loops keep autonomy tied to acceptance.

Coding agents are not reliable because they are always right. They become reliable when the system around them assumes they can stall, collide, retry, fail, improve, and need review.

That system starts with a queue.

Sources