Queue-Driven Attention

Queue-Driven Attention is my operational framework for ensuring that my focus, and by extension, my AI agents' focus, is always on the highest leverage work by strictly limiting active tasks to five items.

What it is

This approach is a direct implementation of a strict work-in-progress limit. I maintain two primary surfaces: `mission-control/QUEUE.md` and `mission-control/INBOX.md`. The `QUEUE.md` file is a plain text list, never exceeding five active items. These are the immediate, actionable tasks that require my direct attention or the orchestration of my agents. The `INBOX.md` is an unprioritized, unconstrained list of everything else—ideas, future features, research topics, minor bugs, content prompts. It's the holding pen for potential work, while the queue is the active work surface. My primary agent, VERA, is programmed to consult the `QUEUE.md` first when looking for directives, ensuring its efforts align with my current top priorities.

Why I do it this way

I learned the hard way that context switching is a profit killer. As a solo operator running a multi-product studio, the sheer volume of potential work can lead to fragmentation. By enforcing a strict queue limit, I eliminate decision fatigue about "what to work on next." It forces a ruthless prioritization that ensures resources—my time, agent compute cycles, and external services like Vercel or Resend—are always directed toward the most impactful items. This discipline is essential for shipping today. It also provides a clear, unambiguous signal to my agentic systems, which thrive on well-defined constraints. Without this, agents can drift, or I can find myself chasing too many threads simultaneously, which is inefficient for both human and AI resources.

How it works in practice

Every new idea, bug report, or content prompt initially lands in `INBOX.md`. When a slot opens in `QUEUE.md`—meaning an item has been completed and shipped, or explicitly moved back to the inbox—I review the `INBOX.md` and pull the single highest-leverage item into the queue. For instance, if I'm iterating on a new feature for Inky, the development cycle might be broken down into queue items like "Implement Stripe checkout for Inky," "Design Inky onboarding flow," or "Draft Thesis-First Content for Inky's launch." Each item in the queue is designed to be a discrete unit of work. My agents, like Claude Code, might then take a queue item such as "Refactor Total Formula 1 data ingestion service" and break it down into sub-tasks, leveraging Multi-Agent Parallelism to execute those concurrently. Once a task is complete, say, a new guide for Pregnancy Power Hour is ready to go live, it's marked done, and the next item from the inbox is promoted. This applies across the board, from architecting new product features to generating content, or even managing financial operations in Mercury.

Where this breaks down

The system's primary vulnerability is genuine, unexpected urgency. While rare, an external critical path dependency or an unforeseen production issue can force an immediate reprioritization, temporarily disrupting the queue. This requires a conscious decision to either pause an existing queue item or move it back to the inbox to make space. It also demands discipline; the temptation to add "just one more thing" to the queue is constant, and succumbing to it dilutes the focus. Furthermore, for very large, multi-stage projects, the queue items must be carefully defined to avoid becoming too broad, which can lead to stagnation within a single queue slot. I've learned that breaking down larger initiatives, like a full Lead Magnet → Paid Ladder funnel for a new product, into smaller, shippable queue items is critical for maintaining flow and agent velocity.