An AI assistant that drafts a follow-up email is useful. An agent that sends it, updates the CRM and books a meeting can remove more work—but it also needs clear boundaries.
For a business team, the question is straightforward: which steps can run on their own, and which should stop for a person to review?
The answer depends on the action, not just how confident the AI sounds. Reading an approved document and sending that document to someone outside the business are different decisions.
Start with the job, then list the actions
Imagine a hypothetical sales assistant preparing follow-ups for inbound enquiries. Its job might involve reading the enquiry, checking a product guide, drafting a reply, updating a lead record and sending an email.
Do not treat that list as one permission called “handle leads.” Separate it into actions your team can understand:
- Read the enquiry and approved product information.
- Draft a suggested reply for review.
- Propose a change to the lead’s status.
- Send the final message to a named recipient.
This makes the automation easier to discuss. A team may allow the first two actions while keeping the last two behind a review step during a pilot.
There is also a simpler option: use a fixed workflow for predictable steps and AI only where interpretation helps. Anthropic’s Building effective agents, published in December 2024, distinguishes predefined workflows from agents that choose their own steps. That distinction remains useful when deciding how much freedom a task needs; it is established guidance, not a new release.
Use three questions to place a review step
Does the action affect someone outside the system? Sending a message, publishing content or inviting a customer to a meeting deserves more consideration than preparing an internal draft. Check the recipient, content and timing before it leaves the business.
Can you undo it cleanly? An internal tag may be easy to correct. A message already delivered cannot be made unread. Even a reversible record change can trigger other automations, so consider what happens next.
Does the action make a commitment or use sensitive information? A price exception, promise about delivery or disclosure of private records should follow the business’s actual authorization rules. Do not let a model’s confident wording become permission.
These questions are a practical starting point, not a substitute for the policies that apply to your organization.
Make approval specific enough to mean something
A button that says “Approve action?” gives the reviewer little to assess. A useful review screen shows the actual proposed result.
For the hypothetical follow-up assistant, display the recipient, subject, full message, relevant source information and any proposed CRM change. If the message includes an attachment, show which file will be sent.
Let the reviewer edit, reject or approve that proposal. If the recipient, attachment or material content changes after approval, send it back for review. Approval of one proposal should not silently authorize a different action.
When possible, keep the permission narrow in the connected system too. An assistant that only needs to prepare replies does not need broad access to delete customer records or change account permissions.
Anthropic’s April 2026 Trustworthy agents in practice explains why control depends on the model, instructions, tools and operating environment together. It also describes the risk of hostile instructions hidden inside material an agent reads. An incoming email is input to the task; it should not be allowed to rewrite the business’s rules.
Avoid turning review into a rubber stamp
Asking people to approve every harmless step can create a queue they stop reading carefully. Reserve attention for decisions where it adds value.
Group related information into one clear proposal instead of presenting a series of vague pop-ups. Route it to someone who understands the decision. Define what happens if nobody responds: for example, leave the reply as a draft rather than sending it automatically after a timeout.
Keep a record of what was proposed, what was approved and what actually happened. A reviewer should be able to distinguish an approved message from a failed delivery or a later manual edit.
Pilot the boundary before expanding autonomy
Start with a small set of representative enquiries and a reviewer. Include straightforward requests, missing information and a request that asks for something outside the assistant’s authority.
Check whether the system pauses at the right moment, whether the review screen contains enough context and whether rejection actually stops the action. These are suggested checks, not tests we have performed for this article.
If the team spends most of its time correcting the same issue, improve the inputs or narrow the task before removing review. If a low-impact action becomes predictable, consider automating it within explicit limits while retaining a way to inspect and stop the workflow.
Lesscode’s workflow automation services cover the systems and integrations behind this kind of operation. The useful design goal is a clear division of work: let software prepare and coordinate the routine steps, and put human judgment where a decision needs it.