There’s a timing problem in confirm-before-execute flows that’s easy to overlook until it causes a duplicate action: the window between when the user confirms and when the action actually dispatches.

In most implementations, the flow looks like this:

Agent plans an action

User is shown a confirmation prompt

User taps confirm

Action dispatches

The assumption is that step 3 leads directly to step 4. But in practice, there’s a gap — and things can happen in that gap.

This post covers what we call the late confirmation race in StareBrain, and how we handle it without introducing false blocks or silent duplicates.

What Can Go Wrong in the Gap

The most common case: the action was already dispatched by an earlier path before the confirmation came back.

How does that happen?…