Guides / Guide

Giving a Copilot Studio agent real actions: human-in-the-loop is not a checkbox

10 September 2026 · AI & Copilot

Background

A chatbot that answers questions has one failure mode: it says something wrong. An agent wired up to actually do things - create a ticket, update a record, send an email, kick off a Power Automate flow - has a completely different one: it does something wrong, and unlike a person, it will do it confidently, at speed, and at scale.

Most of the Copilot Studio rollouts I've seen treat "human-in-the-loop" as a box ticked once during setup, not a control that has to actually hold under pressure once people start trusting the agent to just get on with it. That's the gap this is about.

Setup

  • Scope the connector, not just the action. "Can update SharePoint items" is not a permission - it's every list in every site the connection account can reach. Build a dedicated service account or connection scoped to exactly the lists/tables the agent needs, nothing wider "in case it's useful later."
  • The approval step has to interrupt, not just log. A Teams adaptive card that says "the agent wants to do X - approve?" only works as a control if someone actually reads it before clicking. If the same person approves fifty of these a day, you've built a rubber stamp with extra steps, not a control.
  • Every agent action writes an audit entry before it executes, not after - what it's about to do, on whose authority, with what input. If the action fails halfway, you still know what was attempted.
  • A kill switch that isn't "someone remembers where the toggle is." Disabling a misbehaving agent should be one action, documented, tested before go-live - not a support ticket to the Copilot Studio admin who's currently on annual leave.
User request
     │
     ▼
Agent decides on an action + generates the input
     │
     ▼
Approval step (a real person, genuinely reviewing - not rubber-stamping)
     │
     ▼
Audit entry written (what, why, who approved)
     │
     ▼
Action executes via a scoped connector

Edge Cases & BCP

  • Approval fatigue turns the control off without anyone deciding to turn it off. If people are approving forty near-identical requests an hour, they stop reading and start clicking. Monitor approval time, not just approval count - a median approval time of two seconds on an action that should take thirty is the tell.
  • The agent is right 99% of the time, which is worse than being right 90% of the time. A control that only matters for the 1% gets weaker every week it isn't triggered, because nobody's ever seen it catch anything. Deliberately test the failure path - feed it a request it should refuse or flag - on a schedule, not just at launch.
  • What happens when the underlying model changes? Microsoft updates the model behind Copilot Studio on its own timeline, not yours. Behaviour that was safe last month isn't guaranteed to stay that way. Re-test the agent's boundary cases after any known model update, and monitor for behaviour drift generally, not just after an update you were told about.
  • Can you actually prove what happened, after the fact? If an agent did something wrong and the only record is a Teams message that's since scrolled off, you don't have an audit trail - you have a chat log. Decide where the durable record lives before you need it, not while reconstructing what happened from memory.

← All guides