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

This gets awkward with several AI agents running at once. They can all work in parallel, but I still have to tell each one what I want and decide whether its answer is any good. The way I work now, my job is thinking and AI executes in the system I build (1.1.1). I can delegate the execution, but I can’t delegate my attention to three threads at once.

The first version of this note said the missing cost was briefing rather than recovery time. That isn’t quite right. When I open a finished thread after working on something else, I often need to remember why we chose an approach before I can judge the result. That is recovery time (delta) followed by review time. If I interrupt my current task as soon as an agent finishes, I’ve also added an interruption (lambda). The agent finishing didn’t interrupt me; looking at its answer did. And reviewing an answer may need its own minimum useful block (theta), which won’t necessarily be the same as the block I need for writing code.

I called the agent overhead omega, but I’m not sure it belongs in Duruk’s equation. The equation describes how much usable attention I have. Briefing, catching up, and reviewing are work that spends that attention. Some of their cost already shows up as interruptions and recovery; the rest is still work I have to fit into a block. Running more agents can therefore produce a queue of answers faster than I can understand them. A short reminder of why a thread reached its current state might make the return cheaper. Reading results when I’m already thinking about that project might avoid a switch. Neither idea makes the review itself disappear, and I haven’t measured how much either one helps.

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 demand: briefing, returning to, and reviewing AI agents consume the same limited attention; some of that cost appears as interruption and recovery, while the remaining work still needs time
• Model scope — covers focus blocks only, not weekly reviews, next-action identification, or someday/maybe

#GTD #AI #Workflow #Drafting