CRM + agent: a safe first workflow and checklist

Start read-only, keep writes as drafts

The safe first workflow reads a named set of CRM fields and produces something a person approves—a meeting brief, a suggested internal note, a short list of records that look stale. Nothing it writes takes effect on its own. That one boundary, draft-not-commit, is what keeps a first pass reversible: a weak brief costs a glance to discard, while a wrong write costs a hunt through the history to undo.

How to judge it: if the worst outcome of a bad run is a draft you delete, you are in the safe zone. The moment a run can change a record, move a stage, or reach a customer without you, you have left it.

The whole workflow fits five checkpoints. Read them top to bottom before you connect anything:

The realistic failure is social, not technical: the agent connects cleanly, produces a useful brief, everyone relaxes—and the write scope gets flipped on that same week to “save a step.” The trade-off you are protecting is speed against reversibility. Read-only is slower to feel impressive, but it is the only stage where a mistake is free.

Name the exact fields the job needs

Write the field list before you open the connection screen. For a meeting brief that might be company, opportunity stage, the last three notes, and the next activity—four fields, not the whole account. Grant read on those and nothing else. The principle is the same one behind least privilege and data minimisation: the access you never granted cannot leak, be misread, or surface where it should not.

How to judge it: you should be able to name every field the agent can see and point to the line of the output that uses it. A field you cannot tie to an output line is a field to remove.

The failure to avoid is the convenient “all account fields” grant. Now the agent can read a private churn-risk note, a personal mobile number, or a half-finished deal you were not ready to discuss—and it will happily fold one of them into a brief you forward to a partner. The trade-off is honest: naming four fields is more work than one “grant everything” checkbox, but only the narrow grant stays easy to explain and easy to revoke.

Write the write-rules before any write

A write changes the shared memory, so settle the rules before you switch any write on—not after the first surprise. Five questions cover most of it:

• Which fields may it change? Name them; everything else stays read-only.
• May it overwrite a value, or only fill a blank one? Filling blanks is far safer than replacing what a person typed.
• What still needs your approval? Stage changes, owner changes, and anything a customer will see.
• How are duplicate notes prevented? A rule that stops the same note being appended on every run.
• Where is the previous value recorded? So any change can be read back and undone.

How to judge it: for every field the agent can write, you can state the rule out loud and show where the old value lives. If you cannot, that field is not ready to be writable.

The classic failure is the duplicate-note loop: with no dedup rule, a weekly job appends “Prepared brief” to the same contact until a dozen identical notes bury the real history. The overwrite question hides a genuine trade-off—overwriting keeps a field tidy but destroys what a human entered, while appending preserves history but can clutter. For a first workflow, prefer fill-blank and append-with-dedup over overwrite.

Test on the messy records, not the clean ones

Clean records make any setup look finished. The information you actually need comes from the messy ones, so build a small test set on purpose: a record with a missing owner, one with two notes that contradict each other, an opportunity that closed eight months ago, and two contacts with nearly the same name. Run the workflow against those before you trust it on the live pipeline.

How to judge it: on an ambiguous record, the right answer is usually “needs review,” not a confident guess. An agent that always returns a clean, certain output on messy input is not being careful—it is hiding the ambiguity from you.

The failure this catches early: two contacts named “J. Smith,” and the agent quietly attaches the meeting note to the wrong one, so next quarter you prep from someone else’s history. The trade-off is patience—routing ambiguous cases to review is slower than letting the agent decide, but a confident wrong write costs far more to find and reverse than a “needs review” flag costs to clear.

Promote one write at a time

Trust is earned one permission at a time, not granted in a batch. Once the drafts have been accepted without correction for a stretch of runs, promote the single narrowest write—usually adding a clearly tagged internal note, the kind of change a person can read at a glance and delete in seconds. Keep stage changes, customer contact, and any deletion behind an explicit approval.

How to judge it: widen the scope only after three consecutive runs you would have approved unchanged. If run four still surprises you, you promoted too early—step back to draft.

The tempting mistake is skipping straight to stage automation because it looks like the biggest time-saver. It is also the change other people trust most and notice least, which is exactly why it belongs behind approval the longest. The trade-off never fully disappears: every write you automate removes a checkpoint, so spend that trade only where a wrong value would be cheap to spot and quick to undo.