4.2 Human-in-the-Loop Agent Flows

Why human-in-the-loop is a first-class agent skill

Agents that only chat are incomplete for enterprise work. The moment an agent or flow creates a purchase order, releases a claim payment, or changes a production record, organizations require human judgment at defined gates. Copilot Studio agent flows support this with Human in the loop / Human review actions: the run pauses, a person acts, and the flow continues with structured outputs available as dynamic content.

On AB-620, “create a human-in-the-loop agent flow” means you can design that pause correctly—who is notified, what they must supply, how first-to-respond works, how AI stages interact with manual stages, and how responsible-AI policy keeps people in control for sensitive decisions.

HITL action families in agent flows

Microsoft groups human intervention under agent flow action types alongside AI capabilities, built-ins, and connectors. Practically you will see:

The Human in the loop connector (advanced approvals) is available in Copilot Studio regions and exposes actions such as Request for information and Run a multistage approval. Multistage approvals are documented as available exclusively in agent flows (not ordinary cloud-flow-only authoring paths).

Request for information (RFI) deep dive

RFI is the streamlined way to collect structured human input mid-flow—not merely approve/reject.

Capabilities:

1. Pause execution at the RFI action
2. Collect inputs from designated reviewers
3. Reuse those inputs in later actions (and even later AI approval stages)

How to add it

1. Open or create an agent flow (Flows → New agent flow, or open existing)
2. Insert action → under Human review, choose Request for information
3. Configure required fields:
   • Title — email subject (for example, Missing information on claim ABC123)
   • Message — context for the reviewer
   • Assigned to — one or more emails (in-tenant)
4. Add an input for each value you need

Supported input types (current Microsoft documentation):

You can mark fields optional, set placeholder help text, and for text inputs define dropdown single-select or multi-select lists so reviewers pick controlled values.

Runtime behavior (memorize for scenarios):

• Requests are sent via Outlook (additional channels may appear later)
• Assignees must be inside your tenant—not external guests for RFI delivery as documented
• If multiple people are assigned, the first response wins; later responses are ignored
• After submit, the flow resumes and each input becomes dynamic content for subsequent steps
• Testing: save/publish, Test, watch the pause, complete the Outlook form, confirm downstream mapping

Authoring tip: avoid spaces in input names when you see values wrapped in double braces ({{ }})—Microsoft notes this known issue when parameter names include spaces.

Scenario — insurance claim: An automated claim flow detects missing damage assessment. RFI assigns a field adjuster with inputs: assessment date, summary text, damage amount (number), and a yes/no “photos uploaded to claim file.” A later AI or manual approval stage consumes Damage amt. and Summary without re-asking the chatbot user.

Multistage and AI approvals

Beyond simple approve/reject, Run a multistage approval lets you design a process with:

• Manual stages — human stakeholders; approval type such as first-to-respond or everyone-must-approve; title, assigned to, details
• AI stages — model evaluates instructions plus documents/images/text and returns approve/reject with rationale (requires sufficient Copilot Credits in the environment)
• Conditions — between stages, evaluate inputs (for example expense amount) to auto-approve, reject, skip, or route to another stage

Input mapping rule: inside the multistage designer you cannot drop arbitrary flow tokens directly into stage text without first defining inputs (string/number/boolean). After save, those inputs appear on the action card in the flow designer so you map Dataverse fields, RFI outputs, or connector fields into the approval.

Important multistage constraints:

• Do not assign the same approver to multiple stages (documented failure mode)
• AI stages should use clear, non-contradictory instructions; conflicting rules can yield Analysis failed
• For sensitive cases (large finance, legal, HR actions), configure paths so a human stage still decides even if AI approved
• File content for AI stages is expected in base64 when not already provided that way by a connector
• Some ALM/share limitations exist for advanced approvals—recreate multistage configuration after import/share when docs say so

Example path: AI expense screening → condition (amount > 5000?) → manager manual stage for large amounts → AI budget check → finance manual stage → flow posts payment only on final approve.

Escalation and “wait for response” patterns

Think of HITL as controlled waiting, not as abandoning the automation:

Do not confuse agent handoff (live conversation transfer) with flow HITL (workflow pause with structured outputs). Exam stems that mention “continue the automation after the manager supplies the cost center” point to RFI/approvals in a flow, not only a handoff node.

Responsible AI oversight patterns

HITL is a responsible AI control, not a UI nicety. Design patterns that map to Microsoft guidance:

1. Human ultimate control — for high-impact outcomes, ensure a manual stage remains on the path even when AI stages exist; use “Next step based on decision” so AI approve still routes to a person when policy requires it.
2. Least privilege assignees — assign only the roles that should see the data in the approval email/details.
3. Structured over free-form — prefer typed RFI inputs and dropdowns so downstream systems receive clean values.
4. Transparency — approval identity shows the flow creator in details to prevent spoofing; design titles/messages so reviewers understand why they were contacted.
5. Logging and review — use run history and approvals history (and prompt builder activity for AI stages) so decisions and rationales are auditable.
6. No silent irreversible action — place HITL before the connector action that commits money, access, or irreversible deletes.
7. Tenant and environment boundaries — RFI stays in-tenant; multistage responders should exist in the environment to avoid failures when users live elsewhere.

Scenario: Contoso vendor onboarding

Contoso’s agent collects vendor self-service data. Risky design: agent writes “approved vendor” to ERP immediately from generative confidence. Exam-correct design:

1. Agent or form trigger starts an agent flow
2. Dataverse staging row created as Pending
3. RFI to procurement for tax ID verification status and risk tier (dropdown)
4. Multistage approval: AI checks uploaded W-9 readability/completeness → condition on risk tier → manual legal stage for high risk
5. Only on final approve does a connector create the ERP vendor and notify the requester

This pattern demonstrates pause/resume, structured human data, AI assist with human authority, and connector side effects after oversight—exactly the HITL skill AB-620 measures.

HITL authoring checklist

1. Identify which steps are irreversible or regulated—insert HITL before those actions.
2. Choose RFI vs approval vs multistage based on whether you need data, a decision, or a multi-gate process.
3. Write clear titles/messages; assign correct in-tenant people; prefer first-to-respond only when that is acceptable.
4. Map every human output to later actions; test the pause with Test runs.
5. For AI stages, write non-conflicting instructions, test with sample files, and keep a human stage on sensitive paths.
6. Document capacity: AI stages and flow actions still consume Copilot Studio resources.

Human-in-the-loop turns agent flows from “fast automation” into governed automation—the standard enterprises expect when Copilot Studio agents touch real systems.