The Interruption Ledger: 63 Requests, 26 Untracked

Sixty-three. That's how many concrete requests hit me in fourteen working days, not counting anything already written down, not counting email threads with subject lines. Call them favors, quick checks, "can you just...". Twenty-two of them ever became a tracked task. Of the forty-eight that needed action, twenty-six didn't.

I called the notebook the interruption ledger: a running record of every request that arrived sideways, mid-call, mid-sprint, in the corridor, in a three-minute huddle that should have been a message. I didn't change how I worked. I wrote things down, then checked at 6pm whether they existed anywhere I'd see them again.

This is the field report. No five-step system, no app tour. A ledger, three findings, and one conclusion I didn't expect: the work that goes missing is almost never the work you're worried about.

The Rules of the Experiment

For fourteen working days I logged every request that reached me outside a task list, with the time, the requester's exact words, and whether a tracked task existed by the end of the day. Observation only. I didn't change my behavior, which turned out to be the hard part.

What counted: any sentence with an implied action. "Can you look at the retry bug?" "Let's check whether that hits older accounts." "Please add this to the roadmap." What didn't count: status updates, FYIs, and decisions that had already been made and recorded elsewhere.

The log looked like this:

| Field | Entry |

|---|---|

| Time | Tue 11:04 |

| Exact words | "Can you check if the retry bug hits old accounts?" |

| Implied action | Scope a bug across a customer segment |

| Tracked by 6pm? | No |

Two biases worth naming up front. First, logging a request makes you remember it, so the untracked count is probably a floor, not a ceiling. Second, I was the only subject, so this is an anecdote with a spreadsheet, not a study. Take the shape of it; don't quote the decimal places.

And the discipline was genuinely annoying. The log didn't change my behavior. It just made the behavior visible. By day five I'd started dreading the notebook, which is usually a sign you've found something real.

63 Requests, 22 Tasks

Of the 63 requests, 15 were settled inside the conversation itself, answered, decided, or politely declined. That left 48 that implied real action. Twenty-two had a tracked task by 6pm. Twenty-six didn't. That's a 46% capture rate for work two people had already agreed to.

Then the interesting part: what actually happened to the 26.

• Nine came back later as some version of "did you ever get to that?", average delay, six days.
• Eleven got done anyway, from memory, within 48 hours.
• Six are still undone as I write this.

So the loss wasn't total. It was a tax. Nine items re-requested, six dropped, and a low hum of "wait, did I agree to something?" that followed me into weekends. If nobody measures that hum, does it count as work? It costs something, so it should. It just doesn't show up in a sprint report.

And task capture wasn't broken in the way I expected. I had a perfectly good task system. I just didn't consider a request real until it was in that system, and by the time I got around to it, half the time I'd already forgotten I'd made a promise.

The loss wasn't total. It was a tax, and the tax compounds. A re-requested task costs the original work plus the interruption plus the apology.

The 41-Minute Half-Life

A verbal request keeps its shape for about as long as the conversation that produced it. In my log, the median gap between hearing a request and recording it, when I recorded it at all, was 41 minutes. Past that, the exact words were gone, then the requester, then the distinction between a commitment and a musing.

Interruption research has been pointing at this for years. Gloria Mark's work at UC Irvine on interrupted work is the source of the widely repeated figure that it takes roughly 23 minutes to return to a task after an interruption (the original study is more careful than the headline). Harvard Business Review has documented similar fragmentation around continuous email checking. Microsoft's Work Trend Index keeps finding the same thing from a different angle: most people don't get enough uninterrupted focus time in a workday.

But the cost isn't just the interruption. It's that the interruption carries a payload, a commitment, and the payload has nowhere to land.

Ever walked back to your desk after a five-minute conversation and had no idea what you'd been doing before it started? Now imagine that conversation also assigned you something, and the assignment left with the conversation.

An interruption costs you the task you were on. An uncaptured interruption costs you the task it created. Double the damage, one event, and only one of the two losses gets noticed.

AI Made This Worse

A 2026 analysis of more than 100,000 GitHub developers found that autocomplete alone lifted coding activity by 40%, and full AI stacks pushed it as high as 180%, while releases rose only about 30%. The gap between those numbers is where this whole problem lives.

Sit with the specifics. Autocomplete plus synchronous coding agents: up to 140% more coding activity. Add asynchronous agents: up to 180%. The corresponding gains were roughly 50% more projects and 30% more releases than developers without those tools.

Everything between "code written" and "software shipped" has to absorb that difference: review queues, dependency conflicts, test failures, deployment windows, and the small human question of what's actually worth finishing. If you want a broader view of how developer activity is shifting, GitHub's Octoverse publishes the yearly numbers.

And it isn't only code. A 2026 analysis of AI adoption at startups recommended assigning models to specific jobs, support summaries, proposal drafts, bug explanations, instead of adopting them because they're powerful. The same logic applies to tasks. An agent that can file issues will file issues. Every generated suggestion becomes a candidate for your queue.

More output isn't more shipped work. More output is more decisions. Decisions, unlike code, don't compress.

It Isn't a Communication Problem

Teams describe this as a communication problem. It usually isn't. A piece of work with no recorded owner, status, and next action has no state, so nothing can act on it, including the person who agreed to do it.

Research on asynchronous tool use found that delayed feedback creates serious performance problems for AI agents, particularly when they must switch between tasks, track dependencies, and hold state across multiple activities. Humans fail in exactly the same places:

• A task gets mentioned in chat and never recorded.
• A decision lives in a meeting transcript, not the plan.
• A developer waits for clarification while the task still reads "in progress."
• A deadline lives in one person's head.
• Work resumes four days later with none of the original context.

State management is the unglamorous fix. Every task that has to survive a handoff carries the same handful of fields: desired outcome, current status, owner, review date, dependencies, links, definition of done, next action, and whatever is blocking it.

The last two are the ones people skip. "Next action" forces you to say what literally happens next. "Blocker" forces you to name who you're waiting on. A task with both is something a stranger can pick up cold. A task with neither is a note to self that gets re-read in confusion.

The Cheap Requests Are the Ones That Vanish

The six items still undone at the end of the experiment all took under two minutes. Update the onboarding copy. Check whether the retry bug affects legacy accounts. Add a customer request to the roadmap. Nobody writes those down, which is exactly what makes them expensive four days later.

A follow-up email costs twenty minutes of reconstruction. The two-minute rule is the reason two-minute tasks get lost.

Two minutes is also a lie, incidentally. "Update the onboarding copy" hides a tone decision, an approval, and a person who owns the current version. "Check whether the bug affects older accounts" hides a query, a schema owner, and a support ticket you'll have to update afterward.

Founders feel this most. A single list mixing customer support, product bugs, sales calls, hiring, fundraising, content, and financial admin will always be dominated by whatever is loudest, and the strategic work stays permanently deferred. The structure that helped me was crude: today, this week, this cycle, recurring operations, strategic backlog. Five buckets, and nothing urgent allowed in the last one.

Work in progress limits did the rest. One primary task. One secondary, and only while the primary is blocked. No new feature work while a release blocker is open. Boring rules, but they're the reason six items stayed undone instead of becoming twenty.

What I Changed

I stopped trusting memory and started writing requests in the requester's own words, before the conversation ended. One habit, one keystroke, maybe four seconds per request. It accounted for most of the improvement, and it's the only change I'd defend in an argument.

What broke first: my capture note became a landfill. I was recording more than I could ever action, which felt productive and wasn't. So I added a single daily triage pass, inbox to next action, waiting-for, scheduled, someday. Ten minutes. Most of the capture list died there, which was the point.

Then dates. When no deadline exists, I set a review date instead: the day I'll look at the thing and decide whether it's still real. When I move a date, I write down why. After three weeks, four of seven slips turned out to be review waits, not bad estimates. That's a fact about my own workflow I couldn't have guessed from the inside.

I also stopped capturing in tools that needed a mouse. Half the value of a ledger is speed, if recording a request takes longer than hearing it, you won't record it. Karea's keyboard-first design is why it stuck for me: one shortcut from anywhere, type the thing in the requester's words, keep talking.

The part nobody says out loud

Some of those 26 requests should have vanished. A rough filter:

Priority score = (Impact × Confidence × Urgency) ÷ Effort

It isn't a substitute for judgment, but it stops every incoming suggestion from being treated as equally important. AI can generate candidate tasks. A person should decide which ones enter the committed queue.

That's the shape of the next few years, I think. Soon some of those 63 requests won't come from a person at all, an agent will file them, with a title and a priority and no memory of why. The ledger stops being a bucket and becomes a filter. Which is fine. A filter is what it should have been the whole time.