Asking a machine for something used to be a short transaction. You asked, it answered, and you were still at your desk when it did. Everything built around that shape inherited the assumption quietly: the answer arrives before your attention leaves.
That assumption is expiring. The interesting work now runs for hours, sometimes days, occasionally a week. The people wiring agents together have started shipping the plumbing to match — you hand over the work and get back a handle rather than a result, something you check on later instead of holding the line. The plumbing is the easy half. The hard half is that your process still only knows two states.
Here is the mechanism. Most workflows can represent not started and done. Long-running work introduces a third state — in progress, indefinitely — and a system with nowhere to put it will put it in a person. Somebody becomes the place the pending thing lives. That is fine at three of them and catastrophic at fifty, because human memory does not have a query interface.
The specific failure is that silence is ambiguous. Nothing came back. That reads identically whether the work is still running, finished into a folder nobody checks, or died on Tuesday afternoon. Three very different situations with one indistinguishable signal, and the only instrument that can tell them apart is somebody deciding to go and look.
So a pending state needs three things, none of them exotic. A handle — a name you can check without re-asking, so status is a lookup rather than a conversation. A status legible to someone other than the person who started it, because the one person who knows is also the one person who is on a plane. And an expiry: a stated answer to if nothing comes back by Thursday, then what.
The expiry is the one everybody skips, and it is the one that does the work. An open loop with no deadline is not patience. It is an item nobody owns, aging quietly in a system that cannot see it. A deadline forces a decision — escalate, retry, or abandon — and all three of those are better than indefinite, including abandon.
There is a second-order effect worth naming, because it changes what you are actually managing. Once work can take a week, half-finished work accumulates. You are no longer managing output; you are managing inventory. Twelve things in flight is twelve dependencies, twelve decisions waiting on something, twelve chances to start the same job twice because nobody could tell it was already running. Throughput problems disguise themselves as capacity problems for exactly as long as the inventory stays invisible.
The ten-minute move. Find the longest-running thing in your workflow. Ask three questions about it: what is it called, who besides you can check its status right now, and what happens if the answer never comes. If any of those has no answer, that work is not in your system. It is in your head, and it is aging.
Takeaway: A system that only knows done and not started will quietly convert every long task into somebody's memory. ✱
