The gap between notifying a human and getting a decision back

A notification tells a person something happened. A decision stops the machine until a person says what should happen. Notification infrastructure is built for the first job and measures itself on delivery. AI agents increasingly need the second job, and the gap between the two is where approval systems quietly fail.

Two jobs that look alike for one second

Both jobs begin with a push message landing on a phone, which is why they get conflated. Watch what happens after the tap.

For a notification, nothing needs to happen. The person read it, the system's promise is kept, and the send log records a delivery. This is the right shape for "your agent finished the migration" and "the overnight run hit an error."

For a decision, the interesting part has not started. Somewhere an agent is holding at a step it must not pass alone. The person's tap has to become an answer, the answer has to find its way back to exactly that waiting agent, a clock has to be running so that silence eventually resolves the wait, and the resolution has to land on the safe side. Then somebody, months later, may need to see who decided what.

The parts you end up building

Teams that wire agent approvals over a plain send API build the second half themselves, usually discovering the parts one incident at a time.

Pending state. The question must exist somewhere other than the agent's memory, or a crash erases the fact that anyone was ever asked.

Correlation. The answer arrives on a different connection than the question left on. Something has to match them, reliably, across retries and duplicate taps.

Timeout policy. Silence must become an outcome. The safe mapping is silence means no, and it has to be enforced by the system rather than remembered by every caller.

Recovery. Deploys happen mid-wait. The waiting has to survive the process that started it, which pushes you toward a poll-the-ledger or webhook-resume design whether you planned one or not.

Routing. The right person has to receive it on a device they actually check, which for a product with many users means an enrollment story, not a hardcoded channel.

The record. When the agent acted, someone approved it. When it did not, someone declined or nobody answered. Both belong in a durable, queryable trail.

None of these is exotic. Together they are a real distributed-systems project, and every one of them fails silently: a lost pending row, a mismatched correlation, a timeout that never fired. The notification was delivered. The approval never worked.

The ledger is the tell

You can tell which job a system was built for by looking at what it stores. Send-oriented systems keep a send log: message, channel, delivery status. Decision-oriented systems keep a ledger: question, person, answer or fail-closed expiry, timestamps, and enough durability that the wait itself can lean on it. Pushary's decisions.ask() is the second kind. The call blocks until a real answer exists, the pending decision lives in the ledger rather than in a process, and the resolution is recorded next to the question.

That is also why "we added an approve button to our notification" is not the same feature. The button produces a tap. The loop produces a resolved decision.

Use both, on purpose

The practical architecture is not notifications versus decisions, it is notifications and decisions with a clear rule. If the agent may proceed either way, send a notification and keep moving. If the agent must not proceed without a person, create a decision and block on it. One enrollment, one delivery path, and one audit surface can carry both, which is how Pushary's two-call integration is shaped: notifications for the telling, decisions.ask() for the deciding, and a person on their phone at the end of both.