An Agent's Work Isn't "Done Later" Until You Can Find It Later

I have a habit of asking agents to pause instead of pushing through. Wait for a review. Wait for an external rate limit to clear. Wait for me to make a call I'm not ready to make yet. Pausing is not the problem. The problem is what happens to the paused work afterward. A few weeks ago I went looking for a task I knew an agent had finished setting up, and then couldn't find it. The output existed somewhere. I was fairly sure it had already passed whatever check it needed to pass. But nothing told me where it was, whether it was still waiting, or what I was supposed to do next. I ended up reconstructing the state by hand — grepping logs, opening the last few files it had touched, trying to remember the reasoning from a session that had happened days earlier. Nothing had failed. That's what made it worth stopping on. The task had stopped correctly, for a correct reason, and it had still gone missing. Memory is not a queue When you delegate work to an agent and it hits a stopping point, the stop itself is usually the right call. Waiting for a human decision, waiting for an external system, waiting for a review — these are sound reasons to halt rather than guess. What breaks things is how that stop gets recorded. In practice it often isn't recorded anywhere at all. It lives in whoever was watching at the time: "I'll pick this back up tomorrow," "rerun it after the rate limit resets," "check on this once the review comes back." That's a plan stored in a person's memory, and memory degrades the moment something else demands attention — the next task, the next meeting, the next thing that's actually on fire. A day later, the questions start piling up. Which task was this? Had it already passed its check, or was that a different one? Is it still blocked, or is it clear to continue? If you can't answer these without re-deriving the whole context, then delegating the work to an agent didn't remove the cognitive load — it just moved the load to a later, colder moment when you have less context to work with, not more. The paused task still exists as an artifact. Nothing about it is lost. What's missing is a way back to it that doesn't depend on someone's memory of a specific afternoon. That gap doesn't look like a failure when it happens. It looks like nothing happening at all, which is exactly what makes it dangerous — a task that quietly goes unresumed is indistinguishable, from the outside, from a task nobody needed. Three fields, not a longer log The fix I've settled on is small enough to feel almost too simple: a stopped task is only resumable if three things are recorded together, at the moment it stops. What exists. The actual artifact — the branch, the draft, the generated output, whatever the agent actually produced. Not a description of it. The thing itself, or a direct pointer to it. Current status. Not just "in progress" or "done." Has it been reviewed? Confirmed correct? Sitting behind an external constraint? Stopped on purpose, or stopped because something broke? These are different states that call for different next actions, and collapsing them into a single "pending" bucket is exactly how the state gets lost. The next concrete action. Not "follow up on this" — what, specifically, happens next. If it's waiting, what does it become unblocked by, and roughly when. If it's clear to proceed, what's the actual next step. Individually, each of these is close to useless. A status without an artifact is a status of nothing. An artifact without a next action is inert — you know it exists, but not what to do about it. It's the combination of all three that turns "something an agent was doing" into "a task I can resume in one look," and dropping any one of them quietly downgrades it back into the kind of thing that only lives in someone's memory. Don't reach for a document first The instinct, once you notice this gap, is to write it down properly: a runbook, a section in the README, a note in the session log. That instinct isn't wrong, and I did eventually write some of this down. But documentation solves a different problem than the one that's actually costing time. The expensive part isn't that nobody explained the process. It's that resuming a task requires reconstructing its state from scratch every time, whether that reconstruction happens by a human rereading a log or by an agent re-deriving context from scratch. A document you have to read in full before you can act on it adds a step to every single resume, and if an agent is the one resuming, "read the whole history and infer the current state" is a slow, error-prone way to arrive at three fields that could have just been recorded directly — inferring state from a record never designed to hold it means filling gaps with guesses the original record never made, and those guesses are where the misreads come from. What actually closes the gap is a single checkable entry point — one place that already holds the three fields for everything currently stopped, so checking status is a lookup rather than an investigation. Documentation earns its place explaining what that entry point means and how to use it. It isn't a substitute for having the entry point exist. An agent given a long history to synthesize and an agent given three structured fields are doing very different amounts of work to reach the same conclusion, and only one of those is reliable enough to build a pipeline around. Visible incompleteness beats invisible incompleteness Recording every stopped task in one place has a side effect that takes some getting used to: it makes how much is actually unfinished visible, all at once. There's something uncomfortable about that. A drafted piece of work sitting untouched. A queue of things waiting on review. Output that passed its checks three days ago and never went anywhere since. But visible incompleteness is something you can act on. You can decide to drop it. You can decide it can wait another week. You can decide it's been superseded and doesn't need finishing at all. None of those decisions are available for work you can't see, because you can't make a call on something you've already forgotten exists. The list is only as trustworthy as its worst entry, though, and that's worth taking seriously. As the number of tracked tasks grows, the format tends to drift — one entry recorded a little differently than the others, a status field left stale after someone acted on the task manually and forgot to update the record. An agent reading that list has no way to independently verify it and will act on whatever it says, including when what it says is wrong. A queue that machines read is stronger than a queue only humans remember to check, but it inherits a new failure mode in exchange: it's vulnerable to quietly going stale. A human skimming a document sometimes catches that by instinct; a machine won't. What to track first This generalizes past any one kind of task. A draft nobody published. Output that's been reviewed but not merged. A deploy that's staged but not promoted. A fix that passed its checks but never shipped. All of these get the same "I'll get back to it" treatment, and all of them are equally capable of quietly disappearing. You don't need a workflow engine to start. One entry point holding, for each stopped task: What it is Its current status Whether it's clear to proceed or genuinely blocked If blocked, roughly when that's expected to clear The next concrete action That's the whole list. It's a small amount of structure, and the difference it makes is disproportionate to how little it costs to set up. Delegated work moves fast, which is exactly why it accumulates stopped points fast too. The fix isn't to stop pausing — pausing correctly is good operational hygiene. It's to make sure every pause leaves behind something more durable than a person's memory of having noticed it.