Define the action before choosing the agent
An agent that drafts an email has a different responsibility from one that sends it. A workflow that compares a purchase order with a quote has a different responsibility from one that releases the order.
Start by listing the actions the system needs to take. For each, decide what it may read, what it may prepare and what it may change. Then decide which actions require a person to approve them.
Use approvals where the consequences justify them
Routine internal summaries may be suitable for automatic delivery. Changing payment details, releasing an order or sending an external commitment may need explicit review.
These are design choices, not a universal rule that every action must be approved or that every action can run unattended. n8n's human review documentation describes selective approval for individual agent tools. The workflow can pause while an approver accepts or rejects the proposed action.
The important implementation question is whether the action is technically blocked until approval, rather than relying only on an instruction in a prompt.
Plan for uncertainty
Consider an order that references two quotes, a message with an unreadable attachment or a customer name that matches several records. Agree what happens in each case.
We recommend routing uncertainty to a named person with the source material and the reason for escalation. Decide how overdue approvals, failed integrations and repeated errors become visible. Avoid a workflow that appears successful simply because it stopped reporting problems.
Check the data route
Draw a simple map of the systems, automation services and AI providers involved. Record the information sent to each, the access permissions and applicable retention settings.
Do not assume that keeping a CRM as the main record means information is never processed elsewhere. The actual architecture and provider terms determine that.
Test a small process before expanding
Choose one process and representative examples, including awkward cases. Compare results with a person doing the same work. Check missed exceptions, unnecessary escalations, correction time and operational cost.
For example, a quote-checking pilot could prepare a proposed order without releasing it. Your team can inspect the checks and resolve exceptions while you learn which parts are reliable.
Ask for evidence you can inspect
A scripted demonstration can explain a proposed experience. A production pilot must establish that it works with your systems, permissions and information.
Ask to see the source behind a finding, the action proposed, who approved it and what happened next. Those details make an agent easier to manage and give you a sounder basis for deciding what to automate.
The design recommendations and pilot example are PlatformWorks editorial guidance, not n8n or vendor guidance.
