Give Your Agents a Task Queue, Not a Task List

Here’s a principle so simple it feels like cheating:

Agents work dramatically better — and for dramatically longer — when you have them create their own task queue first, then tell them to keep going until it’s empty.

The Attention Bottleneck

OpenAI recently described a problem most of us have felt but couldn’t name: human attention is the bottleneck, not the agent.

Their engineers could only manage 3–5 Codex sessions before context switching degraded their own productivity. They’d spent months building better AI, only to discover the limiting factor was them. As they put it:

Give agents objectives instead of strict transitions, much like a good manager would assign a goal to a direct report.

That resonated. I’d been fumbling toward the same idea, but OpenAI’s internal tooling validated it with real numbers: teams using queue-based orchestration saw 500% more landed PRs in three weeks.

The Pattern

I don’t use Linear or a fancy orchestrator. I use markdown files:

tasks/
  task-ui-11.md
  task-api-12.md
  done/        ← completed work
  proposed/    ← follow-up ideas the agent had along the way

One file per task. Scope, acceptance criteria, dependencies. The agent reads the next one, does the work, moves it to done/, picks up the next, and keeps going.

My favorite setup? Kicking off a queue before hopping in my self-driving car. By the time I’m halfway across Austin — Luna, my dog, side-eyeing me from the back seat because I keep peeking at the laptop on the passenger seat — the agent has already churned through a dozen tasks. Commutes have become coding sessions.

Why It Works

Three things happen when you give an agent its own backlog:

Context compounds. The agent planned the whole queue, so task 15 understands the decisions from task 3. That’s radically different from handing it isolated tasks 40 sessions apart.

Momentum builds. I got Codex to run for 45 minutes straight and the quality held up. No drift, no degradation — just sustained focused work.

It self-generates work. Interesting refactoring opportunity spotted in task 7? Into proposed/ it goes. The agent stays focused while bookmarking future improvements — exactly what a good engineer does.

The Proof: 50K Lines of Fraud Detection

Two weeks ago I pointed this pattern at a fraud detection project I worked on. Multi-agent orchestration, investigation workflows, a real UI.

Two weeks later: 50,000 lines of TypeScript. Working UX. Agent-to-agent communication patterns I’d have spent days designing by hand. And a proposed/ folder full of good follow-up ideas the agent had while building.

The coherence was the surprise. The agent in task 40 still understood the architecture from task 8 — named things consistently, reused abstractions it had built earlier. Same context, running continuously, not 40 separate chat sessions stitched together.

Try It

1. Plan first. Prompt: “Break this project into a task queue as markdown files in tasks/. Include scope and criteria. Don’t start coding yet.”
2. Review the plan. Adjust scope. Split big tasks. This is where your engineering judgment matters.
3. Let it run. Agent works the queue, moves tasks to done/, defers tangents to proposed/. Step away.
4. Review in batches. Check in every 30–60 minutes, not every 5.

No Jira. No external tracker. Just markdown in a folder — zero dependencies, git-versioned, readable by any LLM.

I wrote earlier about giving agents values instead of task lists — that’s about the marathon. This is about the sprint. Values for the autonomous agent. Queues for the focused build. Both are built on the same insight: the more your agent can manage itself, the more it can accomplish.