We are handing agents real authority. They open pull requests, move money, send messages to customers, run migrations, touch production. Most of the time that is fine, and the autonomy is the point. But there is always a handful of steps where you want a person to look first — the irreversible ones, the expensive ones, the ones that talk to the outside world.
The usual answer is "human-in-the-loop," and in practice it is often a fiction. The human is a log line nobody reads, or a Slack message in a channel that scrolls past, or an approval UI someone has to be sitting in front of. The agent either blocks forever waiting on a human who never sees the ask, or it does not really wait at all. The checkpoint exists on the architecture diagram and not in real life.
A checkpoint only works if the agent can get the ask in front of a person, and the person can answer from wherever they are.
The agent asks, on a phone
Roundtrip ships an MCP server. Connect it to Claude (Desktop or Code), Cursor, or any MCP client, and the agent gets a tool whose entire job is to pause and ask a real human. The ask arrives as a push notification on a phone, not a line in a log.
The flagship tool is request_human_approval:
agent reaches a risky step
↓
calls request_human_approval "About to refund $4,200 to 3 customers. OK?"
↓
Roundtrip pushes it to a phone two buttons, required response, high priority
↓
a person taps Approve / Reject from wherever they are
↓
signed webhook returns the decision
↓
the agent continues — with a human's yes behind itThe person is not watching a dashboard. They are at lunch, and their phone buzzes with a clear ask: what the agent wants to do, the context to judge it, and two buttons. They tap one. The agent gets a human-authorized result and moves on. That is a checkpoint that exists in real life.
Non-blocking by design
The detail that makes this practical: the tool call does not hang the agent waiting on a human. request_human_approval returns a requestId right away, and the decision arrives later via a signed webhook. The agent correlates the eventual answer with the request it sent.
That matters because humans answer on human time. A blocking call that waits ten minutes for someone to come back from a meeting is a broken design: it ties up the agent and falls apart the moment the wait is long. A request id now, and the verified decision whenever the person actually responds, is the shape that survives real-world latency. An agent can have several approvals outstanding at once and resume each as its human gets to it.
Beyond yes or no
Approve and reject covers a lot, but not everything. Sometimes the agent does not need permission. It needs input: a value to use, a choice between options, a corrected draft. For that, the same MCP server exposes send_request, where the agent supplies a full structured card: a form with typed fields, a multi-option decision, a message with context.
So the human in the loop is not limited to a gatekeeper tapping yes or no. They can hand the agent a number, pick from a list, edit the text the agent is about to send, or attach a file, and all of it comes back structured, the same way the approval does. The agent gets not just a verdict but an answer it can use.
The checkpoint that's actually there
Autonomy is worth keeping. The goal is not to slow agents down with approvals on every step. It is to make the few steps that need a human into checkpoints that genuinely work: the agent gets the ask in front of someone, that person answers from their pocket, and the answer flows back so the agent continues with real authorization behind it.
If you are building agents that occasionally need a person, that is the gap Roundtrip fills. The same round trip your code can use is the one your agent calls when it needs a human to decide.