# An AI sales agent should not own the sale > Use an AI sales agent for research, outreach drafts, and timed follow-ups while people keep control of judgment, claims, and live conversations. An AI sales agent should remove clerical delay from a pipeline, not decide whom your company should pursue or what it may promise. The useful version gathers evidence, prepares a draft, watches for an agreed trigger, and hands a salesperson a clear decision. The dangerous version scores a stranger from thin data, invents a personal connection, and sends at machine speed. I have seen teams automate the visible work first because it makes a better demo. A bot sends hundreds of polished messages while the account list, positioning, and suppression rules remain sloppy. Activity rises, replies get stranger, and a good domain develops a bad reputation. Start with the work that makes a human decision faster and better. Earn the right to automate delivery later. ## Automate preparation before judgment The first pipeline tasks to automate are the ones with repeatable inputs, checkable outputs, and a cheap correction path. Research collection fits. Turning approved facts into two draft variants fits. Scheduling a follow-up after a salesperson chooses the sequence fits. Deciding that a company has pain, interpreting an ambiguous reply, or making a commercial claim does not fit. I use four tests before giving a task to an agent: - Can we state the required inputs without asking the agent to guess? - Can a reviewer tell whether the output is correct in under a minute? - Can we reverse a bad action before a prospect sees it? - Does the task avoid consent, legal, pricing, and relationship judgment? A task that fails the first two tests needs a better process. A task that fails the last two needs a person in the loop. This distinction matters because generation and execution are different permissions. Letting an agent write an email is low risk. Letting it choose the recipient, select a mailbox, and press send combines four decisions that should be controlled separately. Many vendors call both cases automation, which hides the part that can damage the business. Build a simple authority ladder. At level one, the agent reads and summarizes. At level two, it writes into a review queue. At level three, it executes an approved action within fixed limits. At level four, it changes strategy. Most sales teams get durable value from levels one and two. Level three belongs only to narrow follow-ups with explicit suppression rules. Level four is management work, regardless of how confidently the model phrases its answer. The correct first milestone is not an autonomous rep. It is a research packet and outreach draft that a competent seller can accept, edit, or reject without opening six tabs. If the packet saves no time, the underlying data and workflow need work. More autonomy will only hide the defect until prospects notice it. ## Research must produce evidence, not synthetic familiarity Automated research should assemble a small evidence packet with sources, dates, and explicit gaps. It should never turn a weak clue into a confident story about the buyer. A funding announcement, a job opening, a product release, and a first-party interview can support a relevant hypothesis. A generic industry trend or an old social post usually cannot support a personalized claim. Define the packet before choosing a model. This compact contract works for many business-to-business teams: ```json { "account": "Northstar Labs", "fit_reasons": [ {"claim": "Hiring two platform engineers", "source_type": "company_careers", "observed_at": "2026-07-30"} ], "trigger": {"claim": "Opened a second region", "source_type": "company_newsroom", "observed_at": "2026-07-22"}, "unknowns": ["current deployment process", "budget owner"], "do_not_claim": ["deployment delays", "approved budget"] } ``` The `unknowns` and `do_not_claim` fields carry more value than another paragraph of generated biography. They stop the draft stage from converting absence of evidence into fake certainty. Require first-party sources for claims about a company's plans. Allow reputable reporting for context, but label it. Treat directories, scraped profile databases, and model memory as discovery hints, not evidence. Freshness also needs a rule. A product launch from last week can justify a timely note. A leadership quote from four years ago may explain positioning but should not appear as if it describes today's priority. Store the observation date next to every fact, then set expiration windows by source type. Job listings might remain useful for weeks. Event attendance becomes stale quickly. There is no universal number, so sales leadership should choose and document the windows. Research agents also need a stop condition. If they cannot find two facts that connect the account to your ideal customer profile, they should return `insufficient_evidence`, not produce a thinner packet. That outcome protects seller time and tells marketing where account data is weak. A system forced to complete every row will manufacture relevance because completion is the objective you gave it. Do not automate collection by violating the source's rules. LinkedIn's official help page says third-party software may not scrape or automate activity on its website. That makes browser bots a poor foundation for an operating process, even before privacy and account restrictions enter the discussion. Use permitted data access, your own CRM history, first-party company pages, and sources your team can defend. ## Relevance beats decorative personalization A good draft explains why this account, why this problem, and why now without pretending the sender knows the recipient personally. Personalization changes surface details. Relevance connects verified business context to a problem your company can actually address. Teams confuse the two because a personalized sentence is easy to see and count, while relevance requires a sound account thesis. First names, school references, sports comments, and praise for a recent post rarely create business relevance. They can make a stranger feel observed. An agent can generate these details cheaply, which encourages teams to use more of them than any salesperson would write by hand. Remove a personalized line and ask whether the remaining message still has a credible reason to exist. If it does not, the account was not ready for outreach. Write an account thesis before a message. It should fit in four fields: observed change, plausible operational consequence, relevant capability, and the question that would disprove the hypothesis. For example, a company opens a second region; releases may now require more coordination; your approved capability addresses release consistency; the disconfirming question asks whether regional deployment changed the process. The thesis makes uncertainty visible and gives the seller a reason to stop when the connection is weak. Role context also matters, but job titles alone are not enough. A chief financial officer, a sales leader, and an engineering leader may all care about the same initiative for different reasons. The agent should select an approved problem frame for the role, then ground it in the same account evidence. It should not invent an individual's priorities from a title. A role suggests which question to ask, not which answer the person must have. Use message variants to test a real choice. Compare a trigger-led opening with a problem-led opening, or a direct question with a request for referral. Do not let the agent produce ten rewrites that differ only in adjectives. Record the hypothesis behind each variant and keep recipient selection stable enough to interpret the result. Small samples will not settle the argument statistically, but reading the replies often shows whether people understood the reason for contact. The call to action should match evidence strength. Strong evidence may support a specific question about a current initiative. Moderate evidence supports a request to confirm relevance. Weak evidence should produce no message. Asking for thirty minutes is not automatically clearer than asking whether the issue belongs to the recipient. The best next action reduces uncertainty without making the buyer do unnecessary work. This approach also gives humans a better review task. Instead of judging whether prose sounds polished, the seller checks the thesis: Is the change real? Is the consequence plausible? Can we make the capability claim? Would the question teach us something? A draft that passes those checks can be plain and still work. A charming draft with no defensible thesis belongs in the reject queue. ## Outreach drafts need a claim budget An outreach agent should draft from approved evidence and a fixed message strategy, with no authority to add a fact. The model's talent for plausible connective tissue is exactly why this boundary matters. It can make an unsupported diagnosis sound courteous and specific. The recipient still recognizes that you guessed. Give each message a claim budget: one verified trigger, one problem hypothesis labeled as a hypothesis, one relevant capability, and one modest call to action. Not every message needs all four. A short note often performs its job with a trigger, a reason for writing, and a question. The budget limits how many ways a draft can become false. A useful drafting record should show the lineage of each sentence: ```text Sentence 1 -> trigger.claim -> company_newsroom -> observed 2026-07-22 Sentence 2 -> approved hypothesis H-14 -> requires cautious language Sentence 3 -> approved capability C-03 -> exact wording checked Sentence 4 -> CTA library Q-02 -> asks for relevance, not a meeting ``` The reviewer can now inspect the risky sentence instead of rereading the internet. If a sentence has no source, hypothesis ID, approved capability, or call-to-action entry, the agent must remove it. This is stricter than a clever prompt, and that is the point. Prompts influence behavior. Records make behavior auditable. Compare two openings. `Your rapid expansion must be putting pressure on deployment reliability` invents both speed and pain. `I saw that you opened a second region. Has that changed how your team handles releases?` uses the observed trigger and asks about the unknown. The second message leaves room for the buyer to correct the premise. That room is the human part of selling, even when software wrote the draft. Keep tone controls concrete. Ban empty compliments, manufactured intimacy, and claims that the agent has followed the recipient's work for years. Set a maximum length. Maintain approved descriptions of your offer and prohibited claims about results, integrations, security, price, or customer outcomes. Have the agent flag rather than rewrite a restricted topic. A salesperson or qualified owner should handle it. Review edits as data. If sellers repeatedly remove the same opening, shorten the same explanation, or reject the same hypothesis, fix the instruction or evidence contract. Do not ask people to clean up the same defect forever. An approval queue becomes useful only when the system learns from patterns in accepted, edited, and rejected drafts. ## Follow-ups belong in a state machine Automate follow-up preparation and timing only after you model the sequence as explicit states. A follow-up is not `send another message in three days`. It depends on delivery, reply status, ownership, consent, opportunity stage, time zone, previous content, and whether another person at your company has already engaged the account. A minimal sequence can use these states: ```text DRAFTED -> APPROVED -> SENT -> WAITING WAITING + no_reply + due -> FOLLOW_UP_REVIEW WAITING + positive_reply -> HUMAN_OWNED WAITING + objection -> HUMAN_OWNED WAITING + unsubscribe -> SUPPRESSED WAITING + bounce -> SUPPRESSED ANY + account_owner_changed -> PAUSED ANY + active_opportunity -> PAUSED ``` The agent may prepare the next draft when an approved transition reaches `FOLLOW_UP_REVIEW`. It should never infer that silence means interest, that an out-of-office message counts as engagement, or that a polite refusal invites a different pitch. Parse automated replies separately. Route ambiguous language to a person. Words such as `later`, `already covered`, or `not me` need context before the system acts. Use event time, not a blind delay. A webinar follow-up sent after the promised recording exists makes sense. A note after a prospect opens an email can feel invasive and open data is noisy anyway. A contract renewal date may justify a task for the account owner, not an automatic sales email. The trigger should have a business meaning that you would feel comfortable explaining to the recipient. Every sequence needs global suppression before message generation. Check unsubscribes, hard bounces, existing customers, open opportunities, legal exclusions, account ownership, recent complaints, and a company-wide contact cap. Perform that check again immediately before send because CRM state changes. A cached approval from yesterday cannot override an unsubscribe received this morning. I prefer review on every cold follow-up until the team has a stable sequence and enough rejection data to see its failure modes. Later, you can auto-send narrow cases such as a promised resource after a human call, provided the content and recipient are fixed. Do not begin with breakup emails or objection handling. Those messages interpret a relationship, and brittle automation makes them sound manipulative. The audit log should preserve the trigger, state transition, suppression result, content version, approver, sender, and timestamp. When a prospect complains, `the AI decided` is not an explanation. Someone must reconstruct why the message existed and which rule allowed it. ## Humans convert when the answer can change the deal Keep a person in control whenever a response can alter discovery, positioning, commercial terms, or trust. This includes the first reply, qualification calls, objections, pricing discussion, security claims, competitor comparisons, negotiation, and any message after frustration or confusion. The seller's job is to notice information that changes the plan. An agent optimized to continue a sequence often misses the moment when the sequence should end. A positive reply deserves human attention even if it contains only three words. `Sounds relevant, Tuesday?` creates scheduling work, but it also signals pace and intent. A person can check who should attend, whether the account has history, and what the prospect likely expects. Automatic booking may be appropriate after the owner confirms the opportunity, but an agent should not turn every soft interest signal into a calendar link. Negative and ambiguous replies matter just as much. `We built this internally` could be a firm rejection, a technical objection, or an opening to discuss maintenance cost. `Talk next quarter` may be genuine timing or a polite exit. The system can summarize and suggest two interpretations. The owner chooses whether to reply, defer, or close. Human touch does not mean typing every sentence from scratch. It means owning the interpretation and consequence. Give the seller the evidence packet, conversation history, draft options, and a clear reason the agent escalated. Then require a meaningful action such as choose a hypothesis, answer the buyer's question, or close the sequence. A ceremonial approve button trains people to approve without reading. Set response service levels for the team, not the agent. Fast automation cannot compensate for unclear ownership. Route replies to a named person, provide coverage when that person is away, and stop all scheduled messages as soon as a human thread begins. Nothing exposes a disconnected sales system faster than an automated nudge arriving while the prospect is negotiating with your colleague. ## Guardrails must control sending, not merely wording A safe AI sales agent needs enforcement outside the model. Instructions such as `do not contact unsubscribed people` are insufficient because the model should never receive the power to override suppression. Put hard checks in the workflow, restrict credentials, separate drafting from sending, and default uncertain records to pause. The sending service should accept a narrow request: approved recipient, approved content version, approved sender, sequence ID, and an authorization that expires. It should reject requests when any of those fields change. It should also enforce per-mailbox and per-account limits, quiet hours, duplicate detection, and a kill switch that sales operations can use without an engineer. Compliance belongs in the design. The US Federal Trade Commission's CAN-SPAM compliance guide says commercial email rules apply to business-to-business messages too. It requires accurate headers and subject lines, a valid postal address, a clear opt-out method, and prompt handling of opt-outs. The guide also says a company cannot contract away responsibility when another company sends on its behalf. An AI vendor does not absorb your obligation. Other countries use different consent and privacy rules, so counsel should define where and how your team may contact people. Deliverability is an operating constraint, not a copywriting trick. Google's Email sender guidelines require authentication and proper message formatting for mail sent to personal Gmail accounts, with added requirements for bulk senders. Those rules can change, so the mail owner should review the current official guidance and monitor the sending domain. Do not let a new agent suddenly multiply volume on the same domain used for customer and operational mail. Run adversarial tests before connecting delivery. Put an unsubscribe in the CRM after approval and confirm the send fails. Change the account owner and confirm the sequence pauses. Feed the reply parser an out-of-office message containing the word `interested` in quoted text. Attempt to insert an unapproved price claim. Reuse the same evidence across two accounts and make sure duplicate or mismatched lineage is rejected. These tests expose authority mistakes that a tone review will never catch. ## Measure decisions and revenue signals Measure whether automation improves seller decisions and qualified pipeline, not whether it creates more messages. Send count, task completion, and draft acceptance can diagnose a workflow, but they do not prove commercial value. A system can maximize all three while annoying the market. Start with a baseline from the manual process. Track research minutes per accepted account, draft edit time, evidence rejection rate, time from a meaningful trigger to human review, positive and negative reply categories, meetings that pass qualification, opportunities created, and suppression failures. Compare cohorts with similar account quality and channel conditions. A before-and-after chart without a control can mistake seasonality or a better list for agent performance. Read edits and replies every week during rollout. Aggregate metrics hide the damaging cases: false personalization, repeated contact across colleagues, a claim that legal never approved, or a follow-up after a clear refusal. Classify failures by source, rule, prompt, model, integration, and reviewer. Fix the layer that created the defect. Watch for displacement rather than savings. If research time falls by ten minutes but sellers spend twelve minutes verifying citations, the agent moved work and added risk. If draft volume doubles while account owners avoid the review queue, you built inventory rather than flow. The useful denominator is accepted opportunities per hour of human attention, with complaint and unsubscribe signals beside it. Do not optimize early experiments on reply rate alone. A vague message can attract curious replies that never become qualified conversations. A provocative subject can lift opens while damaging trust. Define a qualified positive reply in plain language, sample the classification manually, and connect it to later opportunity outcomes. Sales leaders should see both the revenue signal and the cost of corrections. ## Keep the CRM authoritative The CRM should remain the system of record for ownership, consent, stage, and contact history. An agent may propose an update, but it should not silently rewrite fields that control routing or suppression. Otherwise a classification mistake can change the very data used to judge the next action, creating a feedback loop that looks consistent while drifting away from reality. Separate observations from accepted facts. Store `agent_observation` with its source, confidence label, and timestamp. Let a rule or a person promote it into a controlled field such as opportunity stage or account owner. Never let generated notes overwrite raw emails, call records, or the seller's own entry. Append new records and preserve provenance so an operator can compare what arrived with what the agent inferred. Write operations must be idempotent. If a workflow retries after a timeout, it should update the same draft or task rather than create a second one. Use a stable operation ID derived from the account, sequence, trigger, and action type. Reject a second active sequence for the same contact and purpose. Duplicate prevention sounds like plumbing until two nearly identical messages reach one executive from different representatives. Limit what the model can see as carefully as what it can change. A research task rarely needs full call transcripts, billing records, private support tickets, or every field exported from a data provider. Build task-specific views and redact fields that do not affect the output. This reduces privacy exposure and also removes distracting context that encourages the model to invent connections. Data retention needs an owner and a reason. Keep the evidence and decision trail long enough to investigate a complaint and evaluate quality, but do not keep personal data forever because storage is cheap. Define deletion and correction behavior across the CRM, agent logs, vector indexes, and analytics copies. A deletion that touches only the visible contact record is not complete. Finally, make manual correction easy. A seller should be able to mark a fact stale, merge a duplicate, change ownership, or suppress an account without opening an engineering ticket. That correction must invalidate related drafts and pending sends. Human review has little value if the rest of the system continues acting on the version the human rejected. ## Roll out one permission at a time A disciplined rollout starts with research packets for accounts that sellers already selected. For the first sample, compare agent findings with a person's research and reject every unsupported fact. Once source quality is stable, let the agent draft without sending. Record edits and reasons for rejection. Only then add follow-up state tracking, still with human review. Use a permission register with an owner for each capability: - Read approved CRM and source fields. - Write research packets and message drafts. - Create review tasks when explicit events occur. - Send only approved message classes under fixed limits. - Pause sequences globally and preserve an audit trail. Each new permission needs a success measure, a failure test, a rollback method, and a named owner. Review the permission after real use. If the team cannot explain what the agent may do in one page, the scope is too broad. Do not buy autonomy to repair a broken pipeline. If sales and marketing disagree on the ideal customer profile, if CRM ownership is unreliable, or if approved claims live in people's heads, automate the cleanup first. At oleg.is, the Team & AI Audit is the entry point I use to identify that work and quantify where automation can remove cost before a team commits to a wider transformation. The target operating model is deliberately uneven. Machines do the patient reading, formatting, comparison, and waiting. People choose accounts, approve claims, interpret replies, and own the conversation. When the system cannot prove why an action is allowed, it pauses. That rule will feel conservative until the first time it prevents a polished, perfectly timed message from reaching the wrong person.