The first question in the review is who can stop it
When an agent design comes to me for review, the first thing I ask is who can pause it, how long that takes, and whether that person is in the room. The answer I get most often is that the maker can unpublish the agent in Copilot Studio or set the flow inactive in ServiceNow. Then I ask what happens on a Saturday when the maker is on leave and the service desk lead is watching a queue fill with tickets assigned to the wrong group. Usually everyone looks at the person who built it.
That silence is the finding. A pause control is an ordinary operating control and deserves the same design attention as a hold on a payment run. If the only way to stop an agent is to find the one person who knows where the switch is, you do not have a control. You have a dependency on someone's calendar.
Turning it off is not a pause
Most teams already have a switch. In Copilot Studio it is unpublishing or disabling the agent. In ServiceNow it is deactivating the flow or the agent definition. Both stop new work, and both lose something. On a project last year, a ServiceNow agent was closing resolved incidents and posting closure notes. When it started closing incidents that still had open child tasks, the admin deactivated the flow. That left forty incidents the agent had touched but not finished, and nobody had a list of which forty.
A pause holds work in a state someone can review. The agent stops picking up new items, writes down what it was holding, and leaves those items visible in the queue with a marker that says they were paused rather than processed. When that team rebuilt the control, the agent checked a hold record before each run and, when the hold was set, stamped the incidents it would have processed with a work note and a tag. The next morning the service desk lead filtered on the tag and knew exactly what was waiting.
The same distinction applies in Copilot Studio. An unpublished agent stops answering, but the Power Automate flows it already triggered keep running. If the agent calls actions that change records, the pause needs to sit in front of the action, in the flow or the connector, and it needs to leave a trace. Designing the human review step covers what the reviewer should see when that work lands in front of them.
Put the switch where the accountable person can reach it
The person who should be able to pause an agent is the person who answers for its results. For a triage agent that is the service desk manager. For an agent that drafts supplier correspondence it is the procurement lead. Those people are rarely makers, and in most tenants I have reviewed they cannot reach the switch without raising a ticket to the platform team.
The pattern I recommend is small. Create a table for agent holds, a Dataverse table or a custom ServiceNow table, with the agent name, the current state, the owner, a reason, a timestamp, and the name of whoever set it. Give the business owner write access through a plain form or a UI action on the agent's record. Have the agent read the table at the start of every run and before every action that changes data. Nobody needs elevated rights to set the hold, and nobody needs to know where the flow lives.
This is also an identity decision. The role that can pause an agent should be separate from the role that can build or publish it. In ServiceNow that means a dedicated role granted to process owners rather than a reuse of the admin role. In Power Platform it means a security role on the holds table that the maker does not automatically hold. The identity hub has more on why that separation matters when an agent runs under a service identity that keeps its permissions whether anyone is watching or not.
A pause needs an owner and a written reason
A hold with no reason on it lasts forever. I have seen a Copilot Studio agent sit disabled for four months because someone switched it off during a knowledge source migration and never wrote down why. By the time anyone asked, the person who paused it had moved teams and the safest thing was to leave it alone. Meanwhile the service desk was doing by hand the work the agent had been built to do.
The reason field is the note the next reviewer reads at nine in the morning before deciding whether the agent can come back. It should say what was observed, what someone wants to check, and when the hold should be reviewed. If a pause will last more than a day, it should carry a review date and a named owner, following the same discipline that works for access exceptions with an expiry. An exception with no expiry becomes a permanent state that nobody chose.
In the meeting, I ask for three things to be visible on the hold record without opening anything else: who paused it, why, and when it will be looked at again. If the design cannot show those on one screen, people will use the pause once and then avoid it.
Resume with the facts, not from memory
Resuming is where the real damage happens. An agent paused on Tuesday because its assignment rules looked wrong gets resumed on Thursday by someone who assumes the rules were fixed. In the meantime a colleague renamed the assignment groups in ServiceNow for an unrelated reason, and the knowledge article the agent uses for routing was rewritten. The agent comes back with the original instruction, and by lunchtime two hundred incidents are sitting with a group that no longer exists.
The resume step needs a record of its own. Before the hold is lifted, the reviewer should see what changed while it was paused, which items were held, and whether the instruction the agent was given still describes what the business wants. Flow run history in Power Automate and the execution log in ServiceNow show the last successful run. The rest has to be gathered deliberately, starting with a list of configuration changes made during the hold.
The held items need an explicit decision. Either the agent replays them under the resumed instruction and someone watches the first batch, or they are released to a human queue and worked by hand. What should never happen is a silent reprocess where the items flow through on resume and nobody looks. The operations reviews in where automation ownership breaks down exist for exactly this moment.
What to test before anyone calls it live
Before an agent moves from pilot to something the business depends on, I want to see the pause exercised in a rehearsal, with the actual business owner pressing the actual control. Time it. If it takes more than a few minutes, or if the owner has to message a maker to find out how, the control is not ready. The agent readiness check frames the wider review, and this is the item I refuse to skip.
Then rehearse the resume. Pause the agent, change something it depends on, and have a second person bring it back using only the hold record and the run history. If they cannot tell what was held or whether the instruction still applies, the record is missing something, and that gap is far cheaper to find in a test environment than on a Saturday.
This week, pick the most active agent in your tenant and ask its business owner to pause it in front of you. Watch what they click, how long it takes, and what they can see afterwards. Whatever you learn in those ten minutes belongs in your next design review.
