How an AI agent can ask a person and wait

Updated 2026-09-28

An agent asks a human by filing a question with context, then either waits inline until an answer arrives or parks itself and resumes from a callback or a notification. The question needs a clear ask, the reasoning behind it, what the agent already tried, a link to the exact place a person needs to act, and, where there's a choice, a recommendation. The answer then reaches the agent through the same channel it registered, and the agent continues from where it stopped.

Why do agents stall?

An agent runs code. It can call APIs, read files, push commits. It cannot sign in to someone else's account, click a button that only a phone can press, or decide something with no clearly right answer. Five things send an agent looking for a human:

• A sign-in only a person can complete, often behind two-factor confirmation.
• An API key or token the agent doesn't hold and shouldn't generate itself.
• A click inside someone's own account: approving a purchase, confirming a device, accepting new terms.
• Spend above the limit the agent was given.
• A judgment call with more than one reasonable answer, where guessing is the wrong move.

None of these need the agent to stop working entirely. They need it to pause one task, ask, and keep going on anything that doesn't depend on the answer.

How does an agent wait for an answer?

Three patterns cover most of it, and an agent can move between them as a wait gets longer.

Block and poll

The agent files the question, then calls a wait function with a timeout. If the answer arrives inside that window, the call returns it and the agent continues in the same run. If not, the call returns a timeout state instead of an error, and the agent tries again or switches to a different pattern. This suits short waits: seconds up to a few minutes.

Park and resume on a callback

A wait that could run for hours shouldn't hold a process open the whole time. Instead, the agent registers a callback address it controls. When a person answers, that address gets called, and a scheduler wakes the paused run with the answer attached. The agent's process can exit completely between filing the question and getting the callback.

Notify and let the person pick the channel

A person isn't always watching a queue. The system holding the question can also push a notification to a phone or a running app, so the person sees a new ask without checking on a schedule. The agent doesn't need to know which channel the person prefers. It registers where to send the notification, and the person answers from whichever channel receives it.

What does a good ask contain?

A vague question sends a person hunting for context the agent already has, which is slower than the agent doing that work first. A good ask carries five things.

• What is needed. One clear field per piece of information, typed as a choice, a yes or no, free text, or a secret, so the answer can be checked automatically.
• Why. The reason this specific thing is needed now, in plain language.
• What was tried. The steps the agent already took, so the person isn't redoing work.
• A deep link. The exact screen to act on, so nobody has to search settings tabs to find it. A person who has to hunt first answers later, or answers wrong.
• A recommendation. Where there's a real choice, the agent's best guess and its reasoning, so the person can often just confirm instead of researching from scratch.

How should secrets travel?

Never through chat. A password, API key, or one-time code typed into a chat window sits in that transcript indefinitely: logs, history, anything downstream of the model. A field marked as a secret belongs on a page the person controls, submitted directly, and the system should never echo it back into a conversation the agent or any model can read. Any question-asking system worth using treats "secret" as its own field type, separate from plain text.

Checklist

• Can the agent keep working on anything that doesn't depend on this answer, instead of blocking entirely?
• Does the ask name what's needed, why, what was tried, and link straight to the screen that matters?
• Does it offer a recommendation when there's a real choice to make?
• Can the person answer from a phone, without opening a terminal?
• Is a secret field kept out of chat and out of any model's context?
• Does the agent resume on its own once the answer lands, without a person re-triggering it?

How Rails Unblock does it

Unblock is an MCP server an agent connects to like any other tool. It gives the agent one tool to file a question, ask.file, with a title, a reason, one or more typed fields, the steps already tried, links to the exact screens involved, and, for a decision, a recommended value with its reasoning. The agent then either waits inline with ask.wait, which holds the call open with progress keep-alives for up to ten minutes, or less if the host times out sooner, and returns the answer or a timeout, or registers a channel with ask.subscribe: poll again later, an approved HTTPS callback, or a notification to the agent's own registered terminal pane. The person answers from a queue that works from a phone or a laptop, wherever they are when the ask arrives.

A field typed as a secret never reaches a chat transcript or a model's context. Unblock strips it before building any conversational summary, and the person can only fill it in on the page itself. If someone tries to answer a secret field from chat, Unblock points them to the page instead of accepting it there.