the backlog as an API: letting a manager agent groom and run your task queue

Everyone who runs parallel AI coding agents eventually hits the same ceiling. It is not implementation throughput. Five agents are running fine. The ceiling is everything in the queue behind them: who decides what runs next, which tasks are actually ready to hand off versus still too vague, and what happens to the work that comes back needing more before it is done. Queue management, in other words. And until recently, it was entirely manual.

As you scale agent count, more of your time goes to this coordination layer. The agents get faster. You get busier. The bottleneck shifts from writing code to managing the pipeline that writes code.

What queue management looks like when you do it by hand

Say three agents just finished. Now you need to decide which items in the backlog are ready to pick up. Check if any are still too vague to run (a task that says "improve perf" is not an agent-ready spec). Brief the next batch. Triage the output from the agents that finished (some are done, some go back, some surface a question you have to answer before the next step). Then repeat.

None of this is the high-leverage work of an engineer or founder. It is coordination overhead, and it scales linearly with how many agents you run. The more throughput you add, the more of your time goes to queue management rather than to anything that actually requires your judgment.

The instinctive response is to get faster at the coordination. Read faster, brief faster, triage faster. That helps at the margin. It does not change the shape of the problem: you are still in every loop, and the loop count grows with agent count.

What changes when the backlog is queryable state

There is a different model. Instead of a backlog that lives in a Notion page or a markdown file (readable by you, but not structured enough for an agent to act on without reading the whole thing every time), a backlog that exposes structured state: what tasks are open, what priority they carry, what stage they are in, what questions are still open on each one. An interface a manager agent can read from and write to directly.

When the backlog has that shape, a manager agent can do the routine coordination work without you acting as the intermediary:

• Query for the highest-priority task that is ready to run
• Read the task's current spec and flag gaps before firing an implementer
• Groom a vague task (split it, add acceptance criteria, resolve ambiguity) before starting it
• Fire the implementer against the groomed spec
• Read the output, check it against the acceptance criteria, and decide: done, needs revision, or requeue with notes
• Close the task when the gate is met

You are not removed from the loop. You review the manager agent's grooming calls rather than doing the grooming yourself. That is a meaningfully different kind of attention: approving decisions instead of making them at every step.

The manager agent loop

Concretely, the loop runs like this:

1. Read. Fetch open tasks by priority. Skip any with unresolved questions that require human input.
2. Pick. Select the next task that is ready: spec is clear, no blocking dependencies, no open ambiguities.
3. Groom. If the spec needs sharpening (vague acceptance criteria, missing constraints, undefined scope), write it before handing off. If the task genuinely can't be groomed without a human answer, surface the question and move on to the next one.
4. Fire. Start the implementation agent against the groomed task.
5. Review. Read the output. Check it against the spec. If the gate is met, close. If not, requeue with specific notes so the next run has something to work from.

The manager agent runs this loop. Your work moves to the decision boundaries: do I agree this task is next, and do I agree this output is done. Both can be asynchronous. You check in rather than staying in every step.

What this requires from your tooling

For this to hold, four things need to be true. First, the backlog needs structured state that is queryable by an agent, not just a block of prose. Second, the manager agent needs read and write access to that state via a stable interface; MCP is the natural fit because it lets any agent with the right credentials drive the same pipeline. Third, the groomed spec needs to reach the implementer without requiring you to copy it across manually. Fourth, there needs to be a gate mechanism so the implementer cannot mark a task done without the manager's sign-off.

Without the first two, the manager agent is parsing markdown files and writing back to them. That works, but it is fragile and easy to break. Without the last two, you are still in every loop to validate each handoff. The gate is what makes the whole loop trustable rather than a suggestion the implementer can skip.

What still needs your judgment

A manager agent handles routine queue work well. It is not a product manager. Some categories still need a human in the decision:

• Business-context prioritization. The backlog says task A is next. You know the demo tomorrow makes task B the actual priority. That context is not in the task; it is in your head. The manager agent picks by the structure it can read.
• Novel scope. A task that requires understanding something that has not been written down yet cannot be groomed by an agent without a conversation first. Grooming works on tasks that are already mostly specified.
• Security, compliance, and cross-cutting architecture. These benefit from a human reading the spec before the implementer runs, not after. Gate them manually rather than delegating the gate check to the manager agent.

The point is not to remove human judgment but to concentrate it where it matters. Routine coordination does not need your judgment. Strategic priority calls and high-stakes architecture reviews do. The manager agent handles the former; you own the latter.

What comes back to you

When the manager agent runs the loop, the work that reaches you has already been filtered. Tasks that are genuinely done arrive at the gate with the output and the manager's case for why it passes. Tasks that hit ambiguity surface the specific question rather than a half-finished diff. The coordination overhead collapses into two kinds of interaction: approvals at gates, and answers to questions the manager could not resolve without you.

That is a compressible workload in a way that raw queue management is not. Gate approvals can be batched. Ambiguity questions are usually short. The throughput of your agents does not require a proportional increase in your attention.

This is what agents managing agents looks like in practice at the backlog layer. The control-plane framing for MCP is the underlying concept; the backlog loop is one concrete application of it. The related question of how you wire the interface is covered in how to wire an AI orchestrator into a structured development pipeline.

defract and the backlog API

This is what defract's 1.5.0 MCP server was built to support. The server exposes the full task backlog as CRUD over MCP: a connected agent can query open tasks, read their current state and spec, write scope questions, create subtasks, and trigger stage transitions. The lifecycle gates (each stage requires approval before the next starts) mean an implementer cannot close a task the manager agent or you have not signed off on. Claude Desktop connected via the 1.6.0 MCP bridge, or any agent with MCP access pointed at the project, can act as the manager loop described above.

The code and the terminal transcripts stay on your machine. You bring your own Claude Code subscription. The manager agent drives the process via MCP; you own the gates. See defract's MCP interface for the full capability surface, and the parallel agents primer for the underlying mechanics.