The Agent Could Draft the Reply. Sending It Was a Different Decision.

Before Aviad Faruz let an AI workflow answer customers on WhatsApp, the workflow had to show what it wanted to say. In the first stage, which Faruz calls note mode, proposed replies were visible to the owner but could not be sent. Automatic replies came later, as a separate decision.

Faruz owns FARUZO Jewelry and also operates an event venue. The workflow serves the venue, not the jewelry business. By August 2026, by Faruz's account, an n8n workflow connected to respond.io was classifying incoming venue inquiries and selecting a reply template from a Google Sheet. The draft stage gave the owner something concrete to inspect before any customer received a response.

"My lesson is to separate permission to prepare a reply from permission to send one," Faruz said in a written response to PSEEDR.

Faruz reports that 63% of incoming inquiries were eventually handled automatically. The figure counts inquiries handled. It says nothing about revenue, hours saved or how often a reply was correct. The more transferable detail is what changed during rollout. The action the workflow was allowed to take grew from proposing a reply to sending one.

The distinction becomes harder to maintain when preparation itself spends money, several agents share a credential or a rule interrupts legitimate work. Written responses from five practitioners who deploy agents in business workflows describe those situations. Their experiences do not establish a universal approval policy. They show why an operator needs to define the particular action an agent may take, the resources it may use and the conditions that require it to stop.

Observe a proposed action before granting the next one

Faruz used the draft stage to observe the workflow before expanding its authority. The owner could see how it classified an inquiry and which template it selected without making the customer deal with that choice. The stage was temporary: Faruz later permitted automatic replies. Faruz's account supports separating those two decisions, rather than requiring the owner to approve every future message.

Without that stage, a team can mistake a working connection for a finished permission design. The application reaches the messaging service, the credential works, and a test reply looks reasonable. None of those facts says which recipients the workflow may contact, which kinds of message it may send automatically or when it must hand the conversation to a person. Those decisions still have to be made and then reflected in the execution rules.

Faruz's answer does not say how note mode was enforced, whether by withholding a credential, disabling a send action or some other mechanism. For a team adopting the same approach, the point is that preparation and delivery need to be distinguishable in the workflow itself, not only in the operator's intention. A draft can be stored for inspection without being delivered. The send operation can carry its own conditions. Those are design choices the distinction suggests, not details Faruz reported.

The OWASP guidance on excessive agency separates three causes of damage: tool functions that are not needed, downstream permissions wider than the task requires, and autonomy over high-impact actions without confirmation. It recommends enforcing authorization in the downstream systems rather than relying on the model to decide what is allowed. That is a reason to inspect the execution path, not only the wording of a prompt.

There is also a difference between asking a person and asking another automated policy. Anthropic's permission policy documentation for its Managed Agents product describes three options for server-run tools: run automatically, pause for the operator's approval, or let the server evaluate each call and run, deny or pause it. Tools the application runs itself remain the application's responsibility. An automated evaluation can allow a call without a person ever seeing it. This is one vendor's product, and none of the practitioners here reports using it. It illustrates why a setting labelled approval or evaluation needs an exact definition before anyone relies on it.

A workable policy can therefore let a defined class of replies go out automatically, as Faruz eventually authorized automatic replies. It does not have to turn every customer question into an interruption for the owner. What should stay explicit is the action being permitted, the scope of that permission and the point at which the workflow must stop or hand over.

Preparing work can spend the budget before anything is sent

Keeping a draft away from customers does not make preparation free. Luba Inz, founder of Efficiency Sprint, says the company runs with 34 AI agents and keeps adding more. A shared API credential exposed a different kind of authority problem.

"I once shared an API key with no limits, and every agent that writes content started running all of its texts through it," Inz wrote. "Thank God I only put five dollars on it. They spent it in less than two minutes."

The account names no provider and no billing control, and it does not say that all 34 agents took part. It reports a small shared balance consumed quickly, nothing more. Its value is that content preparation can consume a resource the operator cares about, without requiring a later send or publication action. Inz does not say whether any such external action also occurred.

"So now I set up the authority first," Inz wrote. Agents, in this telling, need an org chart just as people do.

An org chart assigns work, but the credential determines what the service will accept. If a research agent and a writing agent hold a key to the same paid account, giving them different job descriptions does not separate their access or set a shared spending allowance. Separate credentials may help attribute consumption, where the service records usage by credential. They create different limits only if permissions or budgets are actually configured at that level.

Pace and total consumption are also different controls. Anthropic's API limits documentation distinguishes a monthly spending limit from limits on requests and tokens per minute, with settings available at organization and workspace level. A request limit slows the pace of work. It does not necessarily stop a workflow that keeps making permitted requests over many minutes from exhausting a balance. Other providers' controls need to be read on their own terms, and nothing in Inz's account indicates which service was involved.

Even a dollar budget has a scope and an enforcement point. In Anthropic's session budget implementation, consumption is priced at public list rates and reaching the cap stops new model requests. The final cost can still land slightly past the cap, because the check happens between model requests rather than during one: a request admitted while the session was under the cap runs to completion, and the tool calls it triggers run too. Parallel threads in one session share a single budget. A budget set on a scheduled deployment applies to each run separately rather than to cumulative spend. The allowance starts again with the next run, so it is not a total for the workflow over time.

Those distinctions suggest questions an operator can answer before handing out a key. Is the allowance for one task, a recurring workflow or a group of agents? Does it cover tools that are billed separately? When it runs out, should the workflow keep its current draft, wait for a decision or end without further calls? Those answers describe a budget policy more usefully than an instruction to be economical.

Inz did not report which controls were later put in place, nor a before-and-after spending comparison. The narrower lesson the account supports is still worth having. Authority to prepare includes authority to consume, even while sending and publishing remain blocked.

One service can hold several permission decisions

Pratik Singh Raguwanshi, manager of digital experience at CXrove, wrote to PSEEDR in October 2026 about a high-volume retail deployment from the year before. The agent could update shipping addresses on unshipped orders and provide tracking status. Partial refunds and credit notes stopped and went to a person.

"We calibrate AI autonomy based on transactional irreversibility and financial liability rather than conversational nuance," Raguwanshi wrote.

In one incident, the agent detected strong customer frustration on a high-value electronics order and attempted to trigger a refund. The logistics database showed delivery to a secure locker. The permission boundary diverted the request to a manager for review, which Raguwanshi says prevented an erroneous payout that would have been nearly impossible to claw back.

A delivery record does not by itself show that a complaint is invalid, that the customer is dishonest or even that the customer has the item. What the rule did was escalate a conflict between the customer's claim and the carrier's record instead of letting the agent settle the financial consequence. The account gives no payment amount and no final dispute outcome.

The condition on address changes matters as much as the refund rule. The permitted action applied to unshipped orders. It would be wrong to reduce the policy to a rule that changing an address is safe and issuing a refund is unsafe. An address change after dispatch, or on the wrong customer's order, is a different decision with its own cost.

A single switch for access to the customer-service application would miss those distinctions. Tracking an order, changing its address and issuing a refund may use the same service while requiring different authority. Even an authorized address change depends on the order still being unshipped and belonging to the right customer. The question is what the agent may do to this resource now, not whether it may open the application.

Human review has a cost in that arrangement. Raguwanshi acknowledges that legitimate disputes take longer when a person must step in, and reports finding that customers accept the delay once routine logistics have been handled instantly. That is a trade-off observed in one deployment. It is not evidence that customers generally prefer delays, or that every refund must always wait for manual approval.

A blocked task is a diagnosis, not an instruction to remove the rule

A rule can be restrictive without being the cause of a failure. Lilach Bullock, an AI implementation consultant and fractional CMO, describes a newsletter workflow that on its first run found nothing it could use.

Bullock's business sells consulting and coaching, and the site earns from sponsored content and paid placements. The general rule in that practice is reversibility. "Reading sources and drafting run automatically, and anything that sends, publishes or changes a live page waits for my approval, because a wrong draft costs me a minute and a wrong send can't be taken back," Bullock wrote.

For the newsletter agent, run in the cloud for the first time in summer 2026, Bullock added a second rule of a different kind. The agent could only write a story from an official source it had actually fetched.

On that first run the gate blocked everything. Two official sites did not offer feeds at the addresses their URLs suggested, and a parsing mistake in Bullock's own setup discarded valid links from the feeds that did work. The result was zero usable stories.

"I repaired the feeds and the parser instead of loosening the gate and letting the agent fill the gap from memory," Bullock wrote.

The second run found 21 current stories from official sources. Those are stories found, not 21 articles written, checked, sent or published. Bullock also keeps the measured runs apart from the belief that motivated the rule: "My belief that the gate stopped invented stories is judgement, because I didn't count what the agent would have made up."

The source rule governs what may be used to write a story. Bullock's separate approval rule governs whether a finished story may be sent or published. The first stopped the run because valid source material never reached the writing step. Removing it would have changed the assignment from writing about fetched material to writing without that evidence. Fixing retrieval and parsing restored the inputs the original assignment required, while leaving the publication decision separate.

Other interruptions do call for a change to the rule. Runbo Li, co-founder and CEO of Magic Hour, says a rule requiring approval for any agent action touching user data occasionally stopped routine read-only analytics queries. Li recalls three or four interruptions to legitimate monitoring work in the first month. The team refined the boundary to distinguish read operations from write operations, which Li says solved the problem.

Read-only is not a universal exemption. A read can still expose sensitive records, export data or consume resources. The useful detail in Li's account is narrower. The team identified which operation the rule was misclassifying and changed that classification, instead of treating every touch of user data as the same action.

Bullock and Li repaired different causes. Bullock needed usable inputs for a rule that stayed in place. Li needed a rule that distinguished intended reads from writes. A workflow attempting an action nobody authorized would present a third case: neither a working feed nor a narrower classification would grant that authority. Identifying which condition stopped the work determines whether to repair an input, revise a rule or leave the action withheld.

Define the useful result the agent can still deliver

An approval policy is incomplete if it only describes what stops. It should also describe what useful work remains allowed. Faruz could inspect a proposed reply before allowing delivery. Bullock could repair retrieval without authorizing invented newsletter material. In both accounts the restriction left a route to the actual business task.

For a new workflow, a compact action record can make that concrete. The following is a design aid drawn from these accounts, not a standard the respondents jointly use.

For a proposed customer reply, that record might preserve the draft and say that sending was withheld because the recipient or request fell outside the permitted class. The customer has not been contacted, even though drafting is complete. For a workflow that exhausts its allowance, the useful remainder might be completed material and a recorded stop reason. Producing that handover should not require unapproved extra paid calls. These are design choices to verify in the platform, not behavior that a prompt alone guarantees.

This record also makes later expansions of autonomy easier to discuss. The next decision can concern one action under known conditions rather than granting general freedom because the last few drafts looked good. When legitimate work stops, the operator can look for the specific unmet condition, as Bullock and Li's team did, instead of reopening every permission.

Faruz eventually permitted automatic replies. The draft stage was never meant to keep a person permanently between every inquiry and its answer. It was meant to make the move from a proposed message to a delivered one deliberate, and to let the venue's own rules, rather than the messaging tool's feature list, define what the workflow could do. The same holds as workflows gain tools, share credentials and hit exceptions. An agent should be able to finish the work it has been authorized to do. It should not treat the next action it is able to take as one it has been permitted to take.

Reporting note: These five written accounts were supplied to PSEEDR for the original October 2026 reporting. Their operational results were not independently reproduced. Faruz operates the venue using the workflow; Bullock disclosed consulting, coaching, sponsored-content and paid-placement revenue. Li reported no commercial relationship with PSEEDR. The linked vendor documentation illustrates particular permission and budget mechanisms, not products the respondents necessarily used. Proposed action records and comparisons are PSEEDR analysis.