Auto-approve or manual? Designing AI agent permissions

Thursday, 4:40 p.m. The support agent that went live three hours ago shows 41 actions in its run trail: 22 record updates, 11 tags, 6 tasks opened, and 2 emails sent to a customer. Nobody noticed the first 39, because all of them were right. The last two told a customer "your setup is complete" — when the install had been pushed to the next day. That evening the team switched the agent off and never turned it back on. The problem was not how well the agent reasoned. It was that all 41 actions had been granted the same permission.

This piece is about designing an agent's permissions instead of toggling the agent on and off. We start with why the permission decision comes before the setup, then give three concrete tests for putting an action on autopilot. Next come the jobs that can run automatically from day one, the jobs that need a human, and a decision table that separates them. After that: who the approval gate should sit with, what happens to requests that arrive out of hours, how guardrails differ from an approval gate, how to audit what the agent actually did, how often to revisit the decision, and how to cap the cost as autonomy widens.

Why the permission decision comes before the agent

Most teams get the order backwards: set the agent up, watch it for a few days, then tighten permissions after something goes wrong. That order is expensive, because the learning is paid for by customers. Permission design isn't really about what the agent can do — it's about what happens when it gets something wrong. Whether the agent is right ninety percent of the time or ninety-nine, you decide where the remainder lands: in a record field, or in a customer's inbox.

In Rocketly this is part of setup rather than an advanced setting. The agent can run 74 autonomous actions inside the CRM, and the approval control setting asks the question separately for each action type: should this run on its own, or wait for your sign-off? There is no single state called "the agent is on." What you turn on is a permission list you tick line by line. Leaving that list at its default is also a decision — usually the wrong one.

The thinking here isn't new. You are building the same role and permission matrix you already use to decide which records a teammate can view or edit, only this time for a non-human actor. One difference matters: a person hesitates, asks a colleague, backs out of the screen. An agent does not hesitate. That is why the boundary belongs in configuration, not in judgement.

What actually qualifies an action for autopilot

The debate usually opens with "do we trust the agent?" and goes nowhere, because trust isn't measurable. The action is. Three questions split almost any list in two.

Is it reversible? A wrong tag comes off, a wrong task gets closed, a wrong field reverts. A sent message does not come back. If the cost of undoing it is close to zero, the action is a candidate for autopilot.

Does it touch the outside? Does only your team see the result, or does a customer, a supplier, or an ad platform? Every outward-facing action, when wrong, speaks in the company's voice.

Is it visible? If the action is wrong, will someone catch it within hours, or will it surface in a quarterly report? Quiet errors are more dangerous than loud ones, because they accumulate.

Actions that clear all three go on autopilot. Anything that fails one goes behind an approval gate. It is a simple rule that replaces instinct, and it ends the argument in the room: nobody gets to win it by saying "I trust it."

Which actions can run automatically on day one

Internal record enrichment leads the list. Filling in a blank industry field on a lead, writing in company size, marking the source — reversible, invisible to the outside, and visible on the record itself. The whole logic of auto-completing incomplete records already lives in this safe zone; the agent introduces no new risk there, it just works faster.

The second safe cluster is summarising and note-taking. A call summary landing on the record, an outcome code attached, a next step written down — all internal. Logging meeting and call notes automatically is a natural first job for an agent, because even when it gets something wrong, the person reading it can fix it.

Third: opening internal tasks and reminders. An unnecessary task is annoying but harmless. That said, every task the agent creates needs an owner. Ownerless tasks turn into a queue nobody watches, and they spend the automation's credibility inside your own team.

Which actions need approval because a customer sees them

The line is clear: anything that sends a message, moves money, or declares a status. An email or WhatsApp message to a customer, creating a quote, writing a discount figure, marking a deal as won, raising an ad budget. What they share is that they rest on something the agent cannot know — the context in the room. The person who knows the install slipped is a human on the team, not the agent.

One cluster deserves particular care: customer-facing messages that look harmless. Automatic thank-yous, survey invitations, review requests. Post-purchase review request flows are built with conditions precisely for this reason; a "rate your experience" message sent to someone whose delivery is late is worse than sending nothing at all. The agent will not add that condition on its own — you will.

Discount and pricing decisions are their own category. An agent drafting a quote is reasonable; an agent choosing the discount rate is not. If who signs off on a discounted quote is a written rule for your people, it has to hold for the agent too. Making the agent an exception effectively deletes the rule.

A decision table: which mode for which action

The table below applies the three tests to clusters of actions. It is built to stay on screen during a setup session; add rows to match the action list in your own CRM.

Action cluster	Reversible?	Touches the outside?	Suggested mode
Field, tag and lead score updates	Yes	No	Automatic
Notes, summaries and call outcomes	Yes	No	Automatic
Internal tasks and appointments	Yes	No	Automatic, owner required
Messages and emails to customers	No	Yes	Manual approval
Quote creation and discount figures	Partly	Yes	Manual approval, threshold-based
Ad budget and campaign status	Partly	Yes	Manual approval

The word "threshold" matters. Permission need not be binary: automatic up to a certain rate, approval above it, is the most realistic balance for most teams. You already run the same logic on the human side.

Who should the approval gate sit with?

Tie approval to one named person and the agent stops the week they take leave. Open it to everyone and the gate means nothing. The workable design is a gate attached to a role: whoever holds the sales manager role and is available signs off, and if nobody is, the request waits in a queue rather than disappearing. The lesson from approval workflow automation applies here too — approvals rarely stall because the decision is hard; they stall because it is unclear who owns it.

A second separation: the person approving should not be the person who configured the agent. If the builder signs off on their own actions, the gate is a formality, not a control. In a small team full separation may be impractical; at minimum, keep the two-person rule for anything a customer sees.

Third, how the request reaches a screen. A request that lands in team chat with its context attached gets answered in minutes; one that lands in a separate approval console waits for hours. Because the agent also works inside team chat in Rocketly, you can put the request where people are already looking.

What happens to approvals waiting out of hours?

The hours an agent is most valuable are the hours nobody is at a desk. Answering an enquiry that arrives at midnight, keeping a lead warm until morning, triaging a weekend request. Those are exactly the hours with nobody to approve anything. If your permission design ignores that gap, the agent effectively only works nine to five.

There are three legitimate answers. Time-conditional permission: an action that runs with approval during the day simply does not run at night. Narrowed autonomy: after hours the agent may send only informational replies that commit to nothing, and anything that makes a commitment waits. Or a queue: the agent prepares the action, holds it unsent, and presents a batch for approval first thing in the morning.

Whichever you pick, the customer still needs to see a response. Business hours and automated greeting messages are the agent's complement here: the agent gathers context without committing, and the greeting states when someone will come back. Silence is the worst option after a wrong answer.

Are guardrails and approval gates the same thing?

No, and conflating them is a common mistake. An approval gate says "you may do this, but ask first." A guardrail says "never do this under any circumstances." One is a delay, the other a prohibition.

In Rocketly, guardrails define that second layer declaratively, and the boundaries are enforced at run time — the agent does not ask, the path simply is not open. What belongs here is usually a company commitment: don't interpret legal terms, don't promise anything about warranty periods, don't declare a refund decision. What belongs behind an approval gate is a business decision: discounts, sends, closures.

There is a third layer that often gets skipped: what the agent is allowed to read. With agent knowledge routing you pick the sources each agent can reach one by one — the sales agent reads the price list, the support agent only the documentation. Thinking about permission purely on the write side leaves a gap; an agent cannot say something wrong about a source it cannot open.

How do you audit what the agent did?

Without an audit, permission design is just a list of assumptions. You only learn whether you got the settings right by looking at the runs. That is what the run trail is for: every agent's runs in one stream, with each action's parameters, result, duration and approver on record. The approver field is not incidental — whether an action ran automatically or someone signed for it is the first question anyone asks afterwards.

Read the trail for three things. One: action types sitting in the approval queue for a long time — either they should never have been gated, or they are attached to the wrong role. Two: types that get approved almost every time — those are ready for autopilot. Three: types that get rejected often — those should not be the agent's job at all, and belong in a guardrail.

Turning those three signals into a weekly habit doesn't require opening yet another screen; scheduled automated reports can bring the approval-queue summary to your inbox. Nobody opens a dashboard unprompted, but people do read a digest that arrives.

When should the permission decision be revisited?

The right approach is staged expansion. Week one, only internal record actions run automatically. Over weeks two and three, action types that get approved every single time move to autopilot one at a time — not as a batch. That way, when something breaks, you know which change caused it.

Don't skip the step before go-live either. The test and preview panel lets you run the agent against real scenarios and see both its replies and its actions before customers do. Trialling a permission change there rather than in production builds team confidence in an hour instead of a week.

Decide up front which data will drive the expansion call, too. Conversations resolved, handover rate to a human, and share of rejected approvals are enough for this. Who sees those metrics and at what level of detail is a separate design problem; the core question of dashboard design holds here as well — what decision will the person looking at this screen make?

How do you cap the cost as autonomy widens?

More autonomy means more runs, and runs show up directly in consumption. Expanding without a ceiling means the agent stops mid-month. A per-agent credit cap lets you set a monthly ceiling for each agent; a run that would exceed it is stopped before it starts. That is a budget decision rather than a brake: the team decides how much allowance each agent gets.

The second cost line is the invisible one: unnecessary runs. Having the agent respond to defined triggers rather than every message cuts both consumption and noise. Defining the order of actions with a step-by-step playbook instead of leaving it to the model does the same job — conditional steps and a side-effect-free dry run keep the agent from wandering.

Finally, think once more about where human judgement enters. Agent autonomy and the wait-for-approval step in a workflow are two answers to the same need: one gates a model's decision, the other pauses a rule-based flow on a person. Sorting which job belongs to which makes both run better.

Once the permission list is right, the agent stops being a source of risk and becomes capacity; to draw up your own action list, start a free Rocketly account and run the first agent with internal-record permissions only.

FAQ

What do I lose by gating every action?

Speed and after-hours coverage. Most of an agent's value comes from moving work forward when nobody is watching. Gating everything reduces it to a draft generator — a legitimate use, but a much narrower one. Putting reversible internal actions on autopilot keeps the gate free for decisions that matter.

How long should the agent hold an action awaiting approval?

You decide, and you should. A request that waits indefinitely dies in the queue. A practical design: after a set window the request expires, the agent hands the conversation to a person, and the trail records that. Not deciding is also a decision; the system should not swallow it quietly.

How do I undo an action the agent got wrong?

Reversibility is a property of the action, not the system. Field updates and tags come back; a sent message does not. That is why the split happens up front. From the run trail you can see the action's parameters and result, work out what changed, and correct by hand what is correctable.

With several agents, are permissions defined separately for each?

Yes, and they should be. A sales agent and a support agent do not carry the same risk. Separate action permissions, separate knowledge sources and separate credit caps per agent are both safer and more measurable than one agent that does everything. Getting a request to the right agent is handled separately, on the routing side.