AI agent approval prompts: the hard part is remembering to come back

By the founder of Cerevisor. Every claim here about how Cerevisor behaves was checked against the app's source code on 12 November 2026.

An AI agent waiting for approval that nobody notices

Picture three agent runs going at once. One reaches a point where it needs a person to pick between two drafts before it can carry on. The person sees the signal, thinks “after this one”, and goes back to the agent they were reading. Nothing breaks. Nothing moves either.

That small stall is the subject of this piece. It is not about how carefully people review agent work, which I have written about before. It is about the step before review: remembering to show up at all.

A piece on DEV Community published on 10 November describes this gap in Cursor. Its author explains that an approval request can sit unnoticed while the person is looking at the agent’s chat, and that no hook (a small script the tool runs on certain events) fires while the agent waits for approval. The sentence that stuck with me:

That is a reasonable design choice, and the author sells a product that fills the gap, so I read it as one practitioner’s report rather than a verdict. But it names the problem well. The agent did its part. It asked. The question is who is responsible for the asking turning into an answer.

Why “I’ll get back to it” fails: prospective memory

Psychologists have a name for remembering to do something later: prospective memory. It is different from remembering a fact. Nobody quizzes you; the memory has to fire by itself, at the right moment, while attention is on something else.

The researchers Reshma Dodhia and Key Dismukes, who studied this in aviation and everyday work, made a useful point in a paper in Applied Cognitive Psychology. When a task is interrupted, resuming it becomes a prospective memory task, and they wrote that “interrupted tasks are a special case of prospective memory.” Their work points to three reasons resumption fails:

• The interruption grabs attention abruptly, so the intention to come back is never properly formed.
• New work starts straight away, leaving little room to notice any reminder.
• The moment to go back is not marked by any single clear signal. It is just “later”.

An agent pausing for approval hits all three. The pause arrives while the operator is busy elsewhere, there is always another agent to read, and “later” has no edge to it.

The other half of the research is more hopeful. A plan that ties a specific situation to a specific action works far better than a general intention. Psychologists call this an implementation intention: “when X happens, I will do Y”. Peter Gollwitzer and Paschal Sheeran pulled the studies together:

The figure d = .65 is an effect size: a standard way of saying how big a difference is, and in this field it counts as a large one. The lesson for agent tools is direct. A vague signal that “something needs attention” is the weak version. A cue that names the exact thing and takes the person straight to it is the strong version.

How Cerevisor handles an agent waiting for input

Cerevisor treats three kinds of waiting differently, because each one fails in a different way if nobody comes back.

A permission prompt. This is the box that asks whether an agent may use a tool, such as running a command or writing a file. In the app’s code, a prompt that gets no answer within five minutes is turned down automatically, and the agent is told why: no response came in time. The comment in the source says it plainly: five minutes is long enough to read the prompt and decide. A forgotten approval never quietly becomes a yes.

A question from an agent. Sometimes an agent asks the person something mid-task. By default the agent waits ten minutes, and if no answer arrives it is told to carry on with its best judgment and say so. The work keeps moving, and the record shows the question went unanswered.

A human step. This is a stop placed in a workflow on purpose, where the run waits for a person to choose or fill something in before the next agent starts. Here the design is the opposite. A human step has no time limit and never guesses an answer, because it exists for decisions that should not be guessed. So the reminder has to carry the weight:

• If Cerevisor is behind other windows or the run is in the background, a desktop notification appears saying “Your input is needed”, with the name of the workflow and the step that is waiting.
• Clicking it brings Cerevisor to the front with the panel open on that exact step, not on whichever step has been waiting longest.
• If the window is already in front and focused, no notification is sent. The amber dot and the footer count of steps waiting already say it.

There is one more rule I care about. Cerevisor’s Operator, the part of the app that can wake up and push work forward on its own, will not run a workflow that contains a human step. It says so on screen and leaves the run to the person. A decision reserved for a human does not get delegated by the back door.

Where the cue is weakest in an ai approval workflow

The design above still leaves one case where memory carries the load, and it is worth naming because every multi-agent tool shares it. When the app is already in front and the person is reading a different agent, a desktop notification would be noise, so none is sent. What remains is the amber dot and the count of steps waiting. That is the same situation the Cursor piece describes, and it is the Dodhia and Dismukes pattern exactly: the cue is on screen, but it is not distinctive enough to break into work the person is already absorbed in.

More alerts are the wrong fix. They train people to dismiss alerts. The better fix is placement. If a choice between two drafts does not need to happen in the middle of a run, put the human step at the end, so that finishing the run and making the choice become the same moment. The “when X, do Y” plan then forms by itself: when the run finishes, choose.

An approval that waits on someone's memory is a step with no owner. Decide in advance who owns it when nobody comes back.

The broader pattern for anyone running several agents at once:

• Every place an agent waits on a person is a small promise someone has to keep from memory, and memory for future intentions is the weakest kind.
• The harness, not the person, should decide what a broken promise means. Turning down an action, proceeding with a note, and waiting forever are all legitimate. Not deciding is the failure.
• The fewer places a run stops for a person, the more each stop gets noticed. Put the stops where the decision actually matters.

Four questions to ask any harness about agents waiting for approval

If you are comparing orchestration tools, these four questions sort them quickly, and every vendor should be able to answer them from documentation:

1. What happens to an approval request that nobody answers? Is there a time limit, and does silence count as yes or no?
2. When an agent asks a question and gets no answer, does it stop, guess, or carry on and record that it did?
3. Does the reminder name the specific item that is waiting, and does it open that item, or just the app?
4. Can an unattended or scheduled run reach a decision that was meant for a human, and if so, what happens?

For a concrete next step, pick the one decision in your current agent setup you would least like an agent to guess, and make it an explicit stop that waits for a person. In Cerevisor that is a human step, and the guide shows how to add one and where it waits. Then put it at the point in the run where you will naturally be looking, rather than in the middle where “after this one” lives.