AI Agent Needs Human Approval? Here's How to Get Notified

Human-in-the-loop approval is a checkpoint where an autonomous AI agent stops a workflow mid-run and waits for a person to say yes before it spends money, deletes data, or ships a change. The problem most teams hit first isn't building the checkpoint, it's the silence afterward: the agent is paused, waiting, and nobody finds out until they happen to check the logs. This covers how to get notified the instant an agent needs your decision, and how the agent finds out what you decided, without you having to build a whole review dashboard just to unblock it.

Why does an AI agent need a human in the loop?

An agent that can act on its own is only safe to leave unattended up to the point where an action is expensive, destructive, or hard to reverse: a production deploy, a refund over a threshold, an email to a customer list. Past that point, the agent should stop and ask, rather than guess. The gap is that "stop and ask" only works if the ask actually reaches someone. An approval request sitting in a log file the agent wrote and nobody is tailing is functionally the same as the agent never asking at all.

How do I get notified the moment an agent needs a decision?

The agent needs one HTTP call at the exact point it decides to pause, sent to wherever a human will actually see it: a phone, not a log file.

1. Get a Bearer API key scoped to send messages from your Pingwire account (Settings → API keys).
2. Pick a target: a channel your team watches, or your own username for a private notes-to-self alert.
3. At the pause point in the agent's code, POST the decision it needs, in plain language, to /api/v1/messages.php.
4. Set "priority":"urgent" if the agent is genuinely blocked and waiting, not just logging progress.
5. Have the agent then either poll for a reply or exit and let a separate resume step pick the thread back up.

curl -X POST https://pingwire.dev/api/v1/messages.php \
  -H "Authorization: Bearer pw_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "deploys",
    "title": "Approval needed",
    "text": "Migration will drop 3 unused columns on orders. Reply GO to proceed.",
    "priority": "urgent"
  }'

That single call is the same primitive covered in sending a push notification from an AI agent, aimed at a narrower job: not "tell me it's done," but "tell me it's stuck and needs a yes." The wording matters here more than usual. "Migration will drop 3 unused columns, reply GO to proceed" gives a reviewer everything needed to decide from the push preview alone, without opening a dashboard first.

How does the agent find out what I decided?

Sending the request is the easy half. The agent still needs to learn the answer, and it has two honest options: keep the process alive and poll, or exit and let a separate step check in later.

Polling means calling GET /api/v1/messages.php?channel=deploys on an interval and scanning new messages for a reply after the timestamp of the approval request. This works fine for a workflow that's already resident and waiting, like a script sitting in a sleep loop. It stops making sense for anything that would otherwise exit, because now the agent is burning a process just to ask a chat log the same question every few seconds.

That's the point where hand-rolling this stops being worth it: a bash script that sleeps, polls a channel, and greps for a keyword is a small piece of infrastructure you now own, including what happens when it crashes mid-wait, what counts as the latest reply once the channel has other chatter in it, and what to do if the read call itself times out. None of that is hard by itself, but all of it is now yours to maintain for a feature that exists only to wait. Handing the send-and-wait step to Pingwire's MCP connector instead means an agent built on the Model Context Protocol can call a send tool at the pause point and a read tool to check for a reply, using the same underlying messages API, without you writing the retry loop yourself.

What if I don't reply in time?

Nothing about this pattern forces a timeout on its own; an unanswered approval request just sits in the channel until someone reads it. If the agent needs a hard deadline, that's a job for the agent's own code, not the messaging layer: schedule a follow-up reminder for N minutes later that only fires if no reply came in, or fold the request into an escalation policy so a second person gets pinged if the first one doesn't answer.

Approval alerts: polling, a custom webhook, or Pingwire

Approach	Who gets notified	What the agent maintains
Log file + manual check	Nobody, until someone looks	Nothing, and that's the problem
Custom webhook to your own server	Whoever built the receiver	An endpoint, auth, retries, and a UI to reply from
Pingwire message + poll or MCP	Anyone in the target channel, on their phone	One API call to send, one to check for a reply

The middle row is the one teams underestimate: a webhook receiver sounds like a small script, but it needs its own auth, its own retry handling if the human's device is offline, and its own place to type a reply back, which is most of a chat app rebuilt from scratch for one feature.

Is this just Slack with extra steps?

If your team already lives in Slack and only needs approvals, a Slack webhook is a reasonable choice, and worth naming honestly rather than talking around. Where Pingwire earns its place is the parts Slack doesn't do out of the box for this specific job: a scoped API key that can send and nothing else, so a compromised agent can't read history or message people outside its one channel; a CLI and MCP connector built around agent workflows rather than human chat first; and self-hosting if the approval requests involve data you don't want sitting in a third party's servers at all. If none of that matters for your setup, the honest advice is to keep using what your team already has open. Migration effort is the other real objection, and it is smaller than it sounds for this one workflow specifically: an approval-alert pause point is one outbound API call, not a rewrite of how the agent makes decisions, so trying it costs an afternoon rather than a sprint.

One quotable fact worth knowing before you wire this into anything that retries: Pingwire collapses identical automated text sent to the same target within a 60-second window into a single message, specifically so a flaky agent that fires its approval request five times in a retry loop doesn't spam the reviewer with five separate pushes.

Set up your first approval alert

Create a scoped API key, send one test approval request to your own username with priority: urgent, and confirm it arrives as a push before wiring the pause point into a real agent. From there, add polling or the MCP connector and CLI reference for the reply side. Create a free Pingwire account to get your first API key.