---
name: mindset-human-in-the-loop
description: Use when a Mindset (mindset.ai) agent's run must pause for a person, through the mindset-admin MCP server. It sends them a link to a form, waits for a decision or information, then carries on with the answer. Use whenever the user mentions a human in the loop, an approval, a sign-off, a review step, or asking someone before the run continues.
metadata:
  title: "Human in the loop: Pause a run until a person answers"
  blurb: An agent whose run stops, sends someone a link to a form, and carries on with their answer.
  group: Examples
  order: 1
  docs: write-a-script, security-model, runs
  checked: 28ab3d642
  updated: 2026-10-26
---

# Human in the loop: Pause a run until a person answers

The user wants an agent that does some work, stops to ask a person for a decision or information, and carries on with the answer. This skill is a pointer. The method lives on the platform, in `get_information` and `find_examples`, and it is current for the platform you're connected to. Read it there rather than working from memory or from this file.

## Where you are building: host, org, environment

Every Mindset call names three things. Get all three from the person before you write code or call a tool. Never guess or invent them.

| Value | What it is | Where the person finds it |
|---|---|---|
| **Host** | The Mindset deployment their org lives on, for example `https://eu.mindset.ai` | The address bar when they're signed in to the Studio, or an agent's **Embed** tab |
| **Org slug** | Their company's account. The org is the isolation boundary: members, model keys, settings and audit sit here, and one org can never see into another | An agent's **Embed** tab, or the address under **Settings → Systems → Connect an AI client** |
| **Environment slug** | A named partition inside the org, such as Sandbox, Test or Production | An agent's **Embed** tab, or the same address. The **Environment** switcher in the Studio shows which one is current |

How environments behave:

- **Agents, scripts, functions, connections, triggers, schedules, conversations, runs and API keys each belong to exactly one environment** and can't see anything in another.
- **Every org starts with one environment, Sandbox, whose slug is `original`.** A slug never changes, even when the environment is renamed. Use the slug, never the display name.
- **Nothing copies between environments.** To promote a change from Test to Production, make the same change again in Production.
- **Don't create an environment to hold your work.** Environments can't be deleted, and they're for stages such as Test and Production, not for projects. Work in the environment the person names. Create one only if the person asks you to.
- **Members, model keys and org settings are shared by every environment.** Changing an org setting changes it everywhere.

## Before you start

This skill works through the `mindset-admin` MCP server. Check that its tools (for example `get_information`) are available to you. If they aren't, set the server up first, following the `mindset-mcp` skill or https://docs.mindset.ai/docs/work-from-claude-code.md, then come back here.

Call `get_information` with no arguments for the platform's own topic index. Its guidance is current for the platform you're connected to. Where it and this skill disagree, follow `get_information`.

## Read first, in this order

1. Tell the user which Org and Environment you're in (every reply from the server names them), and build only where they asked.
2. Call `get_information` with topic `human-in-the-loop-blocks`. It covers what to settle with the user before building, the widget, the `$widget` step, question links and thread links, waits and the no-answer route, several people in turn, runs started by another system, what the person sees, what the platform cannot prove about who a person is, and how to test. If that topic is missing from `get_information`'s index, asking a person is switched off in this Environment: stop and tell the user rather than building round it.
3. Call `get_information` with topic `choosing-what-to-build` and read "Someone else decides, by link" and "Someone else decides, in Slack", to confirm a script is the right build for this request.
4. Call `find_examples` with the request in the user's words, for example "a manager approves by link", "two approvers in turn" or "ask several people at once". Adapt the closest example to this request; never copy one wholesale.

When you reach those steps, also read `authoring:widget`, `authoring:script` and its parts (the `$widget` step is in `authoring:script:steps`), `authoring:flow_test_parameters` to test the routes, and `authoring:trigger` for a schedule.

## The shape to build, without waiting to be told

- A script runs. A phase with a `$widget` step pauses it.
- A link reaches the person through any connection that can reach them: an email, a Slack message, a ticket, or anything else with an API.
- The link opens a form that asks for a decision, information, or both. Publish the form before the script uses it. The script routes on the answer, and a `wait` routes the run when nobody answers.
- Buttons inside a Slack message (`$ask`) are a different thing. Build them only if the user asks for buttons in Slack, from `get_information` topic `slack-approvals-authoring`.
- Don't impose a fixed set of choices such as approve, edit and dismiss. Ask the user what the run needs back, and always give the person a way to say they can't decide with what they were shown.

## The connection that reaches the person

1. Call `list_resources` with `type: "connection"`, then each candidate's operations (`type: "connection_operation"`, `filter: {"connection": "<its id>"}`). Offer to reuse, by name, one whose send can carry a message and the link.
2. A send is a write, and the Org may require an admin to approve a write before anything calls it. If the send is waiting for approval, ask the user to approve it on the connection's Operations tab first: a script that calls it can't be attached to the agent, or test-run, until then.
3. For a new one, the Slack and Postmark examples on https://docs.mindset.ai/skills are worked setups. For any other channel, read `get_information` topic `authoring:connection`, and `authoring:connection:provider:<name>` if the platform has a recipe for it.
4. Prove the connection before you build the script on it. A read proves the credential; only a send proves a message arrives, so send one to the user's own address, with their go-ahead.

## Working with the user

- Ask only about what's missing, one or two questions at a time. Play the plan back in plain words and build once the user confirms.
- Say what you're about to build before you build it, and ask for the go-ahead before any test run that sends a real link.
- Test every route with the user, the no-answer route included, as `human-in-the-loop-blocks` describes under "Test it". A stored test set can run the no-answer route; each answer route needs a real link, answered. Tell them what was tested and what wasn't.
- If something fails twice the same way, stop, say what you think is wrong, and ask before trying another route.

## Read more

https://docs.mindset.ai/docs/write-a-script.md and https://docs.mindset.ai/docs/security-model.md explain scripts and approvals for people.

## Done means

The user has answered a real link for each kind of answer, and seen each route, no answer included, land where it should. A saved script isn't done.