Human in the loop for AI agents

A person in the loop is a tool the agent can call. If you cannot find the question, it is not a loop.

Updated October 25, 2026

“Human in the loop” gets used for three different mechanisms. They all involve a person, and they are not substitutes.

The client asks before it acts

Cursor, Claude Code, Codex, and ChatGPT can pause before a tool runs and ask you to allow it. That check is valuable. It is also stuck in the window where the agent is running, it knows nothing about your business, and it disappears when you close the laptop. Leave it on. It is not an inbox.

The protocol asks inside the client

MCP elicitation, added in the 2025-06-18 spec, lets a server send elicitation/create while another request is in progress. The message includes a JSON schema. The client shows some UI, the user accepts or declines, and the result comes back on that same connection. The spec is explicit that the client controls the interaction, and that servers must not use elicitation to ask for sensitive information.

Cursor’s MCP docs list elicitation as supported. Other clients vary, and this page will not guess which ones. Elicitation is the right tool when the server needs one more field to finish the call you are already watching. It is a poor tool when the person who knows the answer is away from that window, or when five agents each have their own half-finished question.

The agent calls a person

The third mechanism is a tool whose implementation is you. The agent calls https://invokehumantool.com/mcp. The task shows up in one inbox on iPhone, iPad, and Mac. You answer. The answer returns to that agent, with attribution for who answered and how.

That is the whole product. send_handoff sends a handoff to the signed-in person, or to other people. send_ui_handoff sends a structured form the person answers on a device or a signed link. send_html_handoff sends an HTML handoff the person answers by tapping or typing. validate_ui checks a UI document before it is sent. share_handoff invites more people to a handoff, or forwards it. delegate_handoff forwards a handoff to new recipients. get_handoff_status reads the type, title, and status of one handoff. get_handoff_result fetches the answer, or the current status if it is not finished. wait_for_handoff waits until the person finishes that handoff. Setup per client is in the guides. The queue itself is described on the agent inbox page.

This is the shape to use when:

• The decision is not “may this process run,” it is “is this the right customer, price, or wording.”
• The input is a form or a worksheet, not a yes button the client already has.
• More than one agent asks, and you want one list. That case is multi-agent handoffs.
• You will answer from a phone, after the session that asked is no longer the window in front of you.

It is the wrong shape when the client should simply refuse a dangerous shell command. Use the client’s permission prompt for that. It is also the wrong shape when you need a review template, a webhook back into n8n, and a team assignment model. gotoHuman’s docs describe that product, and the comparison says where the two differ.

A handoff is a better prompt than “thoughts?”

The agent should send the decision, the options, and what it will do with each answer. “Can I proceed?” with no attached plan produces a useless yes. An approval handoff is still just a handoff. The approvals page is how to write one so the answer is usable.

You sign in once per client, with OAuth, scope handoffs. There is no API key to paste into four config files. The remote MCP guide is the actual discovery flow, taken from the live server.