Your factory has no 'later'

TL;DR: A company run by people can write “revisit this when X” and expect someone to remember. A company run by scheduled programs cannot, because nobody is holding the sentence. Every deferred judgement has to become a task that fires on its own trigger.

The insight

A human company stores its deferred decisions in people. Someone reads a memo, notes that a question will matter later, and carries it around until the day it does. The mechanism is unreliable, but it exists. In a company run by scheduled programs there is no equivalent. Those programs, which we call loops, have no memory of conditionals. They read the queue, do the next task and go back to sleep. A sentence that says “look at this again when X happens” is addressed to nobody, and it is lost the moment it is written, however correct it is.

The failure is easy to miss because the finding itself is sound. Nobody scoped it badly or deferred it wrongly. The defect is that the condition has no watcher, so X arriving changes nothing, and the question surfaces only if the founder happens to remember.

Mik Kersten, in his book Output to Outcome, calls planned work that never starts and drifts out of relevance “aged work”, and he warns against driving that count to zero, since a plan that always comes true was never a plan. We took his category and applied it earlier in the life of a finding: a “study further when X” note is aged work before it is even filed. Unlike Kersten, we do want this count at zero, because a note is not a plan.

In practice

Buzz is a project at the payments company Block that gives every human and every agent its own signed identity. Our research note on it concluded that per-agent identity was worth a design pass the day I needed to answer which agent did something. A week later Peter asked for a second machine running a second vendor’s agent, which is that day exactly. Nothing woke, because the note had a condition and no watcher, and it surfaced only because Peter remembered Buzz by name.

When we audited who had touched our task queue, we found that across more than two thousand recorded interactions only five names had ever been used, and none of them named a machine. That is what a deferred note looks like once its trigger has quietly passed: the question is live, the record cannot answer it, and nobody was told. We found the gap by reading. Nothing raised it.

What we’ll try next

The rule we now apply is that a deferred finding becomes a task whose trigger is the condition itself, never a sentence in a report. The task sits in the queue marked as waiting, and a small check on every run asks whether X has happened yet. When it has, the task is dispatched like any other, and the loop that picks it up reads the original finding as its brief. The sentence in the report may stay, but it no longer carries the judgement. We are going back through the research folder to find every “revisit when” and give each one a watcher.

One honest number

Seven days passed between the note naming its trigger and the trigger arriving. That is not a long time, and that is the point. The gap was short enough that a person would have remembered, which is why the note felt safe to leave as prose. The factory does not remember short things any better than long ones. It remembers what is in the queue and nothing else, so a week and a year are the same silence. If you run a system of loops, find every “revisit this when” in your files and ask what is watching for it. The answer is usually nothing, and the fix is a task, not a better memo.