Workflows

Where Rules End and Judgment Begins in Sales Automation

An architecture argument for sales buyers: fixed rules own commitments and exclusions, model judgment handles evidence and language, shown through one reply that contains a referral and a stop request.

Here is a reply, written for this article, that is harder to handle than it looks:

I'm not the right person for this, and please take me off your list. Dana Whitfield in procurement handles vendor reviews.

It contains an instruction and an opportunity that pull in opposite directions. A workflow that branches on the first match will do one of two things. If the opt-out branch fires, the sender is suppressed and the referral disappears. If the referral branch fires, Dana is enrolled with an opener about a colleague's suggestion, and the person who asked to be left alone may remain in another campaign. A loosely supervised agent can fail differently: it reads a cordial tone and sends a warm thank-you to someone who has just asked for no more messages.

The reply is a good test of a design because handling it forces the system to show which decisions are fixed in advance and which are inferred. My position is that commitments and exclusions belong to fixed rules, evidence and language belong to model judgment, and a clear line marks where a person decides.

Workflow and Agent Loop, Fairly Described

A workflow is a path defined in advance: a trigger, conditions and actions. Its routing can be deterministic, although external tools and embedded models may still vary or fail. It can be tested and inspected. Its limit is anticipation: a poorly designed first-match workflow can lose part of a compound message, while a well-designed workflow can preserve and handle multiple intents.

An agent loop gives a model a goal and a set of tools, lets it act, shows it the result and lets it choose the next step until the work is done. It can read a message nobody planned for, look something up and adapt. Its limit is that the path varies between runs, so correctness has to be enforced on outcomes; it cannot be assumed from the route.

Real products mix the two. Outreach now presents AI agents across prospecting, deal execution, coaching and forecasting. The category on the label says little about architecture. Ask which decisions are fixed, which are inferred, and which wait for a person.

One Reply, Step by Step

When the reply arrives, a fixed rule pauses every scheduled message to that contact on every channel. No model is consulted. The contact moves from active to awaiting interpretation.

The model then reads the reply and returns what it found, with the supporting text: a stop request from the sender, and a referral naming a person and a function with no contact details. This is judgment, properly placed, because real replies phrase both things in endless ways. From there each element takes its own path.

Element Who Decides Resulting State
Stop request Fixed rule, triggered by the model's reading Contact suppressed on all channels; scheduled sends cancelled
Scope of the stop Rule defaults to the person; a human may widen it Account flagged where wording is ambiguous
Reply to the sender Fixed rule None sent
Referral Model extracts; a human approves Proposed contact, pending review, not enrolled
Message to the referral Model drafts; a human approves Draft attached with its provenance

Two choices deserve explanation. The first is asymmetry. The model may add a suppression on its own reading, even an uncertain one, and may never remove one. Lifting a suppression takes a named person and a recorded reason. An over-cautious stop costs one possible conversation; a missed one breaks a commitment to someone who was explicit.

The second is where the rules live. The model should be able to send a message only through a tool, and that tool should check suppression itself and refuse. An instruction in a prompt to respect opt-outs is a request. A send function that cannot deliver to a suppressed contact holds whatever the model concluded.

The Review Boundary

Dana's record is created with its history attached: named in a reply by a contact who also asked not to be contacted, on this date, in these words. It starts as proposed and can only move to approved or declined; nothing is sent while it waits. Before anyone looks, the model can check Dana against exclusions, look for evidence that procurement does run vendor reviews at this company, and draft a first message.

A person decides two things: whether to contact Dana at all, and whether to mention the colleague. The reply endorsed nothing, and its author wanted out of the conversation, so a draft that opens with a recommendation overstates what happened at that person's expense. A neutral line saying a colleague pointed to procurement is defensible; so is leaving the name out. The call sits with a human because it concerns a relationship, the scope of permission is uncertain, and the cost of a mistake lands on someone outside the system. Controls like these are advertised: Artisan, for one, lists an approval mode, escalation rules and exclusions. Validate them with this exact reply, by inspecting what ends up in the records.

When It Goes Wrong

Three failures are worth designing for.

The model misses the stop request and reports only a referral. The pause-on-reply rule limits the damage, because resuming contact requires an affirmative reading that the reply held no objection, and a sample of those readings should go to a person. When a miss is found, the state is corrected and the reply joins a test set replayed whenever the prompt or model changes.

The suppression write fails because the CRM times out. The agent's account of its own work may still say the contact was removed. The system needs to confirm the stored state, use bounded retries where safe, and hold all sends to that contact until suppression is confirmed or a person resolves the failure. Anthropic's engineering guidance on agent evaluations makes the general point: grade the resulting state as well as the transcript, since the two can disagree.

The reply is processed twice after a sync retry, and Dana is proposed twice. Persist an idempotency key for each intended action derived from the original message. A retry can then recognize a completed action while allowing unfinished steps to resume.

Where This Is the Wrong Design

If a person reads every reply within the hour and volume is modest, this is more machinery than the job needs; a checklist and a suppression list will do. The fixed rules are also blunt. “Stop sending the PDF and just call me” will trip a cautious stop detector and land in review. I would accept that cost. Keep the uncertain interpretation in review and the send paused. Predictable enforcement matters most when the system might otherwise violate an explicit stop.

Make sales better with every conversation.

Request early access

In development. Invites will go out as the product becomes available.

Privacy