I came across Duruk’s focus capacity model while reading his newsletter about engineering productivity. It gave me a way to talk about something GTD handles intuitively but never names: why your day can feel busy yet produce nothing. The model has three parameters: lambda (how often you get interrupted per hour), delta (how long it takes to recover after each interruption), and theta (the shortest block of time where you can still do meaningful work). You take each uninterrupted stretch, divide by theta, round down, and add them up: C = Σ floor(block_i / θ). Anything shorter than theta scores zero.

The model only covers one slice of productivity, protecting and using focus blocks. It doesn’t touch GTD’s clarify-organize-reflect loop, weekly reviews, or someday/maybe lists. But for the part it does cover, it gives useful vocabulary.

The GTD connection

When I mapped these parameters to what GTD actually does, three connections stood out:

• Batching changes when you respond to lambda. The interruptions still arrive, but you defer responding until a processing window. I use “no meeting mornings” for this — not fewer interruptions in the world, just fewer that reach me during deep work.
• Capture systems minimize delta. Without capture, recovery means reconstructing context from memory (in my experience, easily 10-15 minutes of “where was I?”). With a good capture tool, you just read your last note and you’re back in a couple of minutes. 2026-01-31_07-56_git-commits-as-cognitive-snapshots Git commits serve the same function for code work.
• Context lists help match tasks to available time. GTD contexts are originally about physical context (what tool or location you need), but in practice I also use time estimates when picking from a list. If I have 15 minutes before a meeting, I pull from the quick-task list, not the deep-work list. That’s not changing theta — it’s picking tasks that fit the block I actually have.

Fitting tasks to blocks

The article treats theta as fixed, but the practical question is different: given a block of known size, what task fits? A 25-minute gap before a meeting gets a code review, not architecture work. You’re not changing theta, you’re choosing what to attempt.

AI agents push this further. 1.1.1.2 Reactive prompting treats AI as environment that overhears thinking. An agent can pre-stage context and suggest what to work on based on available time. My /gtd:select-next-task command does a version of this — it checks my calendar and recommends tasks that fit the next open block.

Where the model stops working

With multiple AI agents running in parallel, the model’s assumptions stretch. You’re no longer a single worker fitting tasks into focus blocks. You’re an orchestrator spinning up agents and reviewing their output. The relevant overhead isn’t recovery time (delta) but briefing time: how long it takes to give an agent context and verify what it produced. I’ve been thinking of this as omega, though I’m not sure it belongs in the same equation.

The honest question is whether switching between agents even counts as an interruption. The cognitive load of reviewing agent output feels different from deep generative work, but it’s still a context switch. I don’t have a clean answer here. The way I work now, my job is thinking and AI executes in the system I build (1.1.1), but the model doesn’t capture what that orchestration actually costs.

Concepts

• Focus capacity equation — C = Σ floor(block_i / θ), where lambda, delta, and theta shape the blocks
• GTD maps partially — batching defers lambda, capture reduces delta, context lists help match tasks to blocks
• Task-to-block fitting — choosing appropriately-sized tasks for available time, not changing theta itself
• Orchestration overhead — briefing and reviewing AI agents introduces costs the model doesn’t account for
• Model scope — covers focus blocks only, not weekly reviews, next-action identification, or someday/maybe

#GTD #AI #Workflow #Drafting