Good point, Andrew, and I think it lands on something I under-argued rather than something that breaks. Yes, a delegated task is unfinished, and it does leave something open. My claim is about granularity. If I've framed the task tightly enough at handoff, the loose ends are few and quiet — nothing is required of me until a result comes back. The case mentioned in the research is a task that's open and still waiting on me. A delegated task is open and waiting on something else. In practice that's the difference between residue I notice and residue I don't. It isn't free, though, and that's exactly why the cap exists. Every open task leaves a little. At 1-3 it stays under the threshold. At 10+ several are in result-state at once, and they all start bearing thinking again, which is the failure mode I'm arguing against in the first place. It's a version of what a product and engineering group does when they scope a project. The rest of the work still exists; you've drawn a line around a subset so you can focus on it. Partly a mental trick, and it leaks. Which is the point — you can only run it so many times at once. (I'm going to edit the original article to fine-tune this point).
