You will be able to decide which agent actions need human approval and design the approval step.
Marcus's agent was getting good at customer emails. It could look up orders, check stock and draft replies. The next step seemed obvious: let it send the replies and issue refunds itself, so he could stop checking every one. He tried it for a day on a test account. Most actions were right. One refund went to the wrong order, because a customer had mentioned two order numbers and the agent picked the other one. One reply promised next-day delivery to Johor Bahru, which Marcus does not offer.
None of these would have been a problem if a person had glanced at them before they went out. This lesson is about where to put that glance so it catches mistakes without making the agent pointless.
Sort everything your agent can do into three groups.
Read actions look things up and change nothing. Checking an order, searching documents, reading stock levels and converting a price are all reads. The worst a wrong read does is feed the agent bad information, which you catch elsewhere.
Draft actions prepare something without sending or changing it. Writing a reply to a customer, filling in a refund form or preparing a calendar invite are drafts. A draft can be wrong, but nothing has happened yet.
Act actions change the world. Sending an email, issuing a refund, cancelling an order, posting a message, updating a record, making a booking: each of these has an effect outside your app, and some cannot be undone.
The rule follows from the groups. Let the agent read and draft freely, as much as the task needs within the limits from lesson 5.2. Before any act, the agent stops and a person approves. This builds on the confirmation step from lesson 4.3, Check every argument before you act on it, and applies it across a whole agent run.
An approval step is only as good as what the approver sees. "The agent wants to issue a refund. Approve?" is useless. The person cannot tell whether it is right without redoing the work.
Show the exact action with the exact data. Marcus's approval card for a refund shows the customer's name, the order number, the item, the amount in Singapore dollars, the card it goes back to, and the customer's original message, with the sentence that prompted the refund highlighted. For an email, it shows the full text, the recipient and the subject, exactly as they will be sent. Then two buttons: approve or reject. Rejecting asks for a one-line reason, which goes back into the agent's notes.
Make approving quick. If each approval takes three minutes of digging, people start clicking approve without reading, and the step stops protecting anything. One screen, all the facts, one click.
And make sure the approval cannot be skipped. The button press must be handled by your code, which then runs the action. The model should never be able to call the act tool directly, or to mark something approved on its own.
Every approval and rejection gets logged: what the action was, the exact data, who approved or rejected it, when, and the reason for any rejection. Keep this with the agent's step log from the same run.
The record does two jobs. When something goes wrong, you can trace it. Was the agent's proposal wrong, or did a person approve a wrong proposal without reading it? Those need different fixes. And over time, the record shows you how often each kind of action is approved unchanged, which is what the next section needs.
Approving everything forever is tiring, and the temptation is to remove approval as soon as the agent seems reliable. Do it with evidence, one action type at a time.
Look at the approval log. If Marcus has approved two hundred order status replies without changing one, sending those automatically is a reasonable step. If refunds are rejected or edited one time in twenty, they stay behind approval. Start with actions that are low risk and easy to undo, and keep anything involving money, deletion or legal commitments behind a person far longer.
Even then, keep a way back. Marcus sends automatic replies but samples ten a week to read, and if he finds a bad one, that reply type goes back behind approval.
Before you can set rules like these, you need a list of everything your agent could do. The activity below asks you to write it.
List every action your agent could take and mark each as read, draft or act, with the approval rule for each.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).