What Should an AI Be Allowed to Send on Your Behalf?

The demonstration went well. The agent found the accounts, wrote the emails, prepared the follow-up, and nobody in the room touched a keyboard. The question you did not ask, because asking it out loud sounds like nerves, is what happens the first time it writes to the finance director at your largest account and gets something wrong. You would not find that out from a dashboard. You would find it out from the customer.

That is the right thing to worry about, and it has a precise answer. Not a trust setting, a model choice or an assurance that the system is careful, but a written list of every action the agent can take, each carrying its own permission, agreed before anything is switched on.

Why the answer is usually vague

Ask where the approval line sits and the reply is often the word "autonomous" followed by a change of subject. Vagueness is commercially convenient, because a permission list is harder to sell than a promise. It also moves the risk quietly onto you. If nobody has written down what the agent may send, the first to find out what it sent is the person who owns the account.

Authority is granted per action, not per agent

There is no single dial marked trust level. Every action an agent can take is placed on a ladder deliberately, and the same agent normally sits on several levels at once. It may create an internal task unattended and still require an explicit approval from a named person before one email leaves the building.

Nothing starts high. Higher autonomy is earned through evaluation and operating evidence, never assumed at launch, and an action can be moved back down after release.

What genuinely runs unattended

The list is longer than nervous buyers expect and narrower than a demonstration implies:

• reading approved records in the CRM and the systems connected to it;
• assembling account and meeting briefs from material that already exists;
• research against an agreed list of sources;
• preparing internal queues, so the work arrives sorted rather than discovered;
• creating and updating internal tasks;
• flagging conditions you have agreed are worth attention, with the evidence attached and any inference labelled as inference;
• drafting.

Everything on that list shares one property: none of it is visible to a customer. That is the working test. If an unattended action can be seen from outside your business, it is on the wrong level.

What always needs a named person's sign-off

Two categories, and neither has useful exceptions.

Every external message. Every channel, every recipient, however routine it looks, including replies to messages the customer started. Not because the drafting is unreliable, but because nothing tells you in advance which message lands on the wrong desk on the wrong day. A first approach to a cold account and a reply into a live renegotiation look identical to a queue, and are not the same commercial event.

Any CRM write to a field the business reports on. Stage, value, owner and close date roll up into a forecast people are held to. An agent may prepare those updates and show the evidence. A person sets them. Below that line, field-level authority is agreed property by property: which an agent may set, which it may only propose, and which it may never touch. That list belongs in the build rather than in a user role, because an integration inherits whatever the connected account can already do.

Sign-off means a named individual answerable for it. A shared inbox is not a sign-off route.

What is hard-blocked

Hard-blocked means the capability is absent, not that a warning appears and someone confirms.

• Bulk and destructive changes. Merging or deleting records, mass property updates, wholesale reassignment. These are done by a person with a rollback plan, or not at all.
• Anything invented. A contact, a job title, an event, a date, a prior conversation, an agreement nobody made. If it does not exist in an approved source, it does not appear in a draft.
• Anything outside the agreed source list. Open-web research included, unless a specific source has been approved for a specific purpose. You cannot attribute what you cannot trace, and an unattributable sentence in a customer-facing draft is a problem you meet in public.
• Sending through an unapproved route. A personal mailbox, a new sending domain, an unlogged channel. The route is part of the permission, not an implementation detail.

Draft is a legitimate permanent setting

The ladder is not a staircase, and reading it as one is how these projects fail. Plenty of sales workflows should sit at draft or recommend permanently, and saying so is often the difference between a programme that holds up in month nine and one that quietly gets switched off.

Consider what each level actually buys. A rep who accepts a good draft in fifteen seconds has been handed back the twenty minutes of assembly behind it. Promoting that action to unattended saves the fifteen seconds and removes the only quality control in the workflow. That is a poor trade in any month, and a bad one in the month the message is wrong. Human accountability for a workflow is never removed.

Approval fatigue is the real risk, not missing approval

Here is the failure nobody demonstrates. Route everything to one person in one queue and they will approve without reading. A signature applied without reading is worse than no signature, because it manufactures a record of scrutiny that was never exercised, and that record is what gets produced afterwards as evidence somebody checked.

So the design work is in the routing, not the gate:

• Route by consequence, not by volume. The high-consequence queue stays small enough that reading all of it is realistic on a normal Tuesday.
• High-volume, low-consequence work either stays unattended and internal, or it is restricted. It does not get poured into the same queue as the messages that matter.
• Instrument the queue itself. Approval rate, time to decision and override reasons tell you whether anyone is reading. A queue where almost everything is approved within seconds is not a governed workflow, it is a formality with a timestamp.

An approval gate nobody reads is a fault in the routing, not a failure by the person clicking.

Outbound rules are set by people, and the agent works inside them

Consent, suppression, audience definition and send frequency are business rules. Someone in your organisation owns each one, they are written down, and they are reviewed on a schedule. The agent operates inside them. It does not widen an audience, add a channel, raise frequency or reach a suppressed record on its own initiative.

Suppression has to be enforced at the point of send, not only when the audience was assembled, because a record can be suppressed in the hours between the two. Checking at queue time looks correct in testing and fails on the day someone opts out.

Logging, so you can reconstruct what happened and why

The standard to build to is reconstruction, not record-keeping. Six weeks later, from the log alone, you should be able to answer why this message went to this person on this day: what the agent read, which rule fired, which version of the instructions was live, who approved it, and when.

Most logging captures the output, which is the least useful part: by the time you are looking, the customer has already forwarded it to you. The inputs and the path tell you whether this was one bad draft or a rule about to do the same to forty other accounts. The engineering detail on the CRM side is set out in governing AI write access to your CRM.

Why this is easier inside the CRM you already run

A separate outbound tool arrives with its own user list, its own permission model, its own copy of your contacts and its own log. You then hold two permission models to keep aligned and two audit trails to reconcile, manually, after something has already gone wrong. The compliance question sits with you rather than with the supplier.

Built inside the CRM your team already works in, the permission set, the record and the audit trail are one thing. The person who approves a message is a real user with a real role, and the evidence the draft was built from sits on the record it relates to. That is the argument for sales agents built into your HubSpot estate rather than bolted on beside it, and it is a governance argument before it is a technical one.

How you would know the boundaries are set correctly

Not by how the system feels in week two. By four things you can read off:

• the accepted draft rate, and the reasons given when a draft is rejected;
• time to decision on the approval queue, watched for the point at which it collapses towards zero;
• the number of actions moved back down a level after release, because a programme that never demotes anything is not measuring;
• the count of actions currently running unattended, which should be small and every one of them nameable.

That last one is worth applying now, before you buy anything. If nobody can name every action an agent runs unattended, the boundary has not been set. It has been assumed.

The next step

Setting these lines for your own pipeline is a scoping exercise, not a proposal, and it starts with the state of the data underneath the workflows that carry real commercial consequence. The AI and Data Readiness Assessment covers that ground. It is one of five fixed-scope assessments on our diagnostics page, it is short, and it carries no obligation. If your records will not support any of this yet, you get that answer plainly, which is cheaper to hear now than in month four.

Sales is the default first quarter of AI Accelerator, our 12-month programme delivered one department at a time. A standard wave puts two agents into production, and the boundaries for every action they take are agreed before either runs. Where a sales wave sits in the wider programme is covered in the rollout sequence we recommend.