Name the decision before you pick the approver
Most human review steps I see in agent design reviews were added because someone in the room was nervous, not because anyone had named a decision. The Power Automate flow has a Start and wait for an approval action in front of every write. The Copilot Studio agent asks for confirmation before it runs any tool. The approver is the requester's manager. Then I ask what the manager is deciding, and the room goes quiet.
So the first thing I do is make the team write the decision as a sentence a person can answer with yes or no. Should this supplier's bank details change to the account named in this email. Should this case close now that the agent believes the customer's question was answered. If nobody can write the sentence, the review step comes out or the agent stops doing that piece of work. A step nobody can describe becomes a click nobody thinks about.
That sentence also fixes the boundary of the automation. Reading the email, finding the supplier, checking the current account number, drafting the change, all of that belongs to the agent. The yes or no belongs to the person. Microsoft's procurement example at PPCC drew this line well, and we wrote up why that approval step earns its place.
Route on a rule you can say out loud
Once the decision is named, the next question is which items reach it. My rule has three parts. A person reviews when the action is hard to undo, when the agent's input came from outside the organisation, and when the agent had to choose between candidates and chose one. Everything else runs and gets logged. Apply that to a first draft and half the approval steps disappear.
The bank details change trips all three, so it stays with a person. Compare an agent that answers order status questions by reading the sales order in Dynamics 365 and drafting a reply. The draft is reversible, so no review there. Sending is not, so the review sits at send, and the reviewer sees the order the agent read next to the exact text it wants to send. The same logic puts the review on closing a case rather than opening one. A duplicate case costs someone a merge. A case closed early costs you the customer.
Put each rule into the flow as a named condition and carry the name into the request. Routed because the supplier match returned two candidates tells the reviewer where to look before they open anything. In six months, when one rule has routed three hundred items and every one came back approved without a comment, you can loosen that rule and leave the others alone. The evidence I would want first is in our agent readiness check.
The reviewer is deciding from the wrong information
Open the Approvals app in Teams on a project that skipped this thinking and the cards say Agent requests approval to update supplier record, with approve and reject underneath. To decide, the reviewer has to open the supplier, work out what the agent intends to change, and compare it with what is there now. Most do not. I have read approval histories where the median time from request to response was under fifteen seconds. Nobody reviewed anything in fifteen seconds. They clicked.
The card needs five things. The source the agent worked from, what it believes it found, the proposed change with the current value beside the new one, the rule that routed it, and what happens if nobody answers. In Power Automate that means building the approval details from real values captured earlier in the run: the sender of the email, the supplier name the agent extracted, the two accounts it matched. In Copilot Studio, when a tool is set to ask before it runs, the confirmation should show the values about to be sent rather than the name of the tool.
Confidence is the part teams get wrong most often. A model score on the card means nothing to a person in accounts payable, and it invites them to approve anything above a number they made up. Say what tripped the rule instead. Two suppliers with the same name in different countries is something a reviewer can settle in a minute. A score of 0.71 is not.
The queue needs an owner and a due date
The failure I see most often has nothing to do with the model. The approver goes on leave. The request sits in their Teams activity feed for three weeks, the flow run waits, and when the approval finally times out the run shows as failed in a run history that nobody in operations opens. The payment went to the old account, and the first anyone heard of it was the supplier's call. Reassignment exists in the Approvals app, but somebody has to know it is their job, and nobody was told.
A run history is a debugging surface, and no operations lead should have to read one. I put every routed item in a Dataverse table with a status, the reason code from the routing rule, the assigned reviewer, and a due date, then give the lead a model-driven view over it. The approval outcome writes back to that row when it arrives. Now the lead can see fourteen items waiting, six of them more than two days old, all from the same rule, and act before the phone rings.
This matters more when the agent runs from a trigger rather than a chat, because there is no user in a conversation to confirm anything. The routed item has to land somewhere a person will look. It is the split we argued for in giving queued work a business owner. Delivering the request is one job. Holding the exception until it is resolved is another, and it needs a name. A pause control belongs beside that view.
Write the answer back where the next person will look
Six months on, internal audit asks why a supplier's bank account changed the week before a large payment. The answer that satisfies them lives on the supplier record: who approved the change, when, what they were shown, and what they wrote. The answer most projects can produce is a flow run that aged out of history weeks ago.
So the last action after the approval, whatever the outcome, writes a decision record back to the business record the agent was working on. A timeline note is the minimum. Better is a small table of agent decisions linked to the supplier or the case, holding the request text exactly as the reviewer saw it, the reviewer, the outcome, the comment, the routing rule, and how long it waited. Timeouts get a row too. That is the row audit finds. That is what a durable process record means in practice.
Rejections carry the most information and get the least attention. A rejection with no comment tells you the reviewer disagreed and nothing else. Make the comment mandatory on reject and read the comments once a month. When one rule's comments are all versions of this was fine, loosen it. When they say wrong supplier again, fix the matching before you send fewer items to people.
What I would check before the next design review
Before the meeting, open the last twenty approvals in the environment and read each request as if you were the reviewer. If the card alone did not give you enough to decide, the card is the first fix. Then look at the median time from request to response. Under a minute means nobody is reading, and a review step nobody reads is worse than none, because the log now says a person agreed.
Then ask the team which sentence the reviewer is answering. If the answer you get is the name of a field, keep asking.
