The big idea

An agent that writes into a shared, trusted system

Unlike a personal email inbox, a CRM is a SHARED system of record — every rep, sales manager, and automated report depends on it being accurate. An agent here isn't just risking one user's data; a bad write corrupts something many people and processes trust. And for anything relationship-sensitive (an actual sales conversation), the agent needs to stay a suggester, not an autonomous actor.

We'll build around those two constraints: multi-source enrichment with real provenance tracking, lead scoring, rigorous write-back validation before anything touches the shared CRM, and a suggest-don't-act default for outreach.

How to read this: Each step opens with a real design decision — make the call before I show you what ships. Watch the diagram grow, hover the boxes, and at the end kill the write validator and feed it stale data to see the safeguards actually catch problems. Hit Begin.

Step 1 · The baseline

Manual research, lead by lead

Simplest version: a rep manually researches each lead — company background, contact role, recent news — one at a time. What's the real cost?

Design decision: Reps manually research every lead individually. What's the actual cost of this approach?

The call: Reps spend a large share of their limited time on research and data-gathering rather than actual selling and relationship-building — the highest-value use of a rep's time. — Every minute spent manually looking up company details or a contact's role is a minute not spent on the conversations and relationship-building that actually drive sales — automating the research (not the relationship) targets exactly this misallocation of a scarce resource: rep time.

Manual research consumes a large share of a rep's limited time on data-gathering rather than the actual selling and relationship work that drives revenue. Automating research — not the relationship itself — targets this specific misallocation.

Automate the work, not the relationship: The design goal isn't replacing what a rep does with a customer — it's eliminating the research and admin overhead that competes with their time to actually do it.

Step 2 · Multi-source enrichment with provenance

Sources disagree and go stale

Automate lead enrichment by pulling company and contact data from multiple external sources. Different sources can disagree with each other, and any of them can go stale. Should the system just trust whichever source it checks first?

Design decision: Multiple external data sources are used for enrichment, and they can disagree or go stale. How should this be handled?

The call: Track SOURCE PROVENANCE explicitly for every piece of enriched data — which source it came from and how recently it was verified — so downstream consumers (scoring, drafting) can weigh reliability and freshness rather than treating every fact as equally trustworthy. — Explicit provenance tracking means every downstream use of enrichment data can account for how reliable and how CURRENT it actually is — a fact from a frequently-updated, generally-reliable source is treated differently than a stale or less-reliable one, rather than flattening all enrichment data into equally-trusted facts.

Track Source Provenance explicitly — which source supplied each fact, and how recently it was verified — rather than treating every enriched data point as equally trustworthy. This gives downstream consumers the information needed to weigh reliability and catch staleness before acting on outdated data.

Not all data is equally trustworthy — track why you believe it: Aggregating multiple sources without tracking provenance loses exactly the information needed to later catch a stale or unreliable fact — provenance is what makes a downstream freshness check (Step 8) possible at all.

Step 3 · Score and prioritize leads

Focus effort where it's actually likely to pay off

A rep has far more leads than time to pursue each equally. Should all leads get equal attention?

Design decision: A rep has many more leads than time allows pursuing equally. Should attention be spread evenly?

The call: No — score leads by predicted likelihood-to-convert (based on enriched firmographic and behavioral signals) and prioritize rep effort toward the highest-scoring ones. — Lead scoring directs a rep's genuinely scarce time toward leads statistically most likely to actually convert, using the enrichment data already being gathered — a materially better use of limited effort than spreading it evenly regardless of likelihood.

Add a Lead Scoring model that ranks leads by predicted conversion likelihood, using enriched signals, and surfaces that priority to the rep — directing scarce time toward the leads statistically most worth pursuing.

A different ranking problem than inbox triage: Email triage classifies urgency of something that already exists; lead scoring PREDICTS a future outcome (will this convert) from available signals — a genuinely different, more predictive problem, even though both exist to direct limited human attention efficiently.

Step 4 · Protect the shared system of record

A bad write corrupts something everyone trusts

Enriched and scored data needs to be written back into the CRM. Should writes happen automatically and immediately, with no validation?

Design decision: Enrichment writes need to land in the shared CRM. Should they write immediately with no validation?

The call: No — validate every write (checking for duplicates, consistency with existing trusted data, and provenance quality) before it commits to the shared CRM, failing closed if validation is unavailable. — Because the CRM is a shared system of record many people and automated processes depend on, a bad write is far more consequential than a bad write to one person's private data — validating before commit, and blocking writes entirely if the validator itself is down, protects the shared asset from corruption.

Add a Write Validator that checks every enrichment write for duplicates and consistency before it commits to the CRM — and fails closed: while the validator is unavailable, writes queue rather than risking corruption of a system of record that many people and downstream processes trust.

The stakes of a bad write scale with how many things trust the data: A write to one user's private data affects one user. A write to a shared system of record can silently propagate bad data into every report, every other rep's view, and every downstream automation built on top of it — the validation rigor should scale with that blast radius.

Step 5 · Suggest, don't act

The agent proposes; the rep decides

The system has enriched, scored, and can draft outreach for a lead. Should it autonomously send that outreach, or something else?

Design decision: A drafted outreach message is ready for a promising lead. Should the agent send it autonomously?

The call: No — the agent SUGGESTS the next action (a drafted email, a recommended call) and the rep remains the one who reviews and actually sends or acts, keeping a human as the primary actor for relationship-sensitive interactions. — Defaulting to suggestion rather than autonomous action respects that sales outreach carries relationship stakes an automated check can't fully capture — the rep's judgment stays in the loop for the actual send, while the agent still saves them the drafting and research effort.

Default the Outreach Drafter to suggestion, not autonomous action: it proposes a next-best-action (a drafted email, a recommended call) but the rep remains the one who reviews and actually sends or acts. This keeps a human as the primary actor for anything relationship-sensitive, while still eliminating the drafting and research burden.

A different default posture than an approval-gated agent: Where an email agent might auto-execute well-established low-risk patterns and gate only consequential ones, THIS agent's default is suggest-first for anything relationship-facing — reflecting that sales outreach carries relationship stakes that make "propose, human decides" the more appropriate baseline than "auto-execute unless flagged."

Step 6 · Personalize at scale without genericness

Real data, not mail-merge

Drafting outreach for many leads at once risks reading as obviously mass-produced, generic content — the opposite of what makes outreach effective.

Draft outreach using actually-relevant enrichment data — recent company news, a specific role-based pain point, a concrete detail from provenance-tracked research — rather than templated mail-merge with only a name swapped in. The scale comes from automating the RESEARCH and drafting effort, not from producing identical content with superficial substitution.

Scale the effort, not the genericness: The value of personalization comes from genuinely relevant specifics, not from the mechanical act of inserting a name into a template — using real enrichment data is what lets outreach scale in VOLUME without scaling down in actual relevance.

Step 7 · Automatic activity logging

Pipeline visibility without manual data entry

Sales pipeline reporting depends on accurate records of every call, email, and meeting. Should reps be responsible for manually logging every interaction?

Automatically capture and log every interaction — calls, emails, meetings — into the Activity Log, feeding back into the CRM without requiring reps to manually re-enter what already happened. This keeps pipeline reporting accurate and current without adding administrative burden that competes with the actual selling time this whole design exists to protect.

Don't reintroduce the burden you just removed: A system that automates research but then requires extensive manual activity logging has just moved the time cost, not eliminated it — automatic capture keeps the net time savings real.

Step 8 · The sharp edges

Stale facts and a scoring model that drifts

Two real risks: enrichment data that was accurate when gathered but is now outdated (a contact changed roles months ago), and a lead-scoring model whose predictions quietly degrade as market conditions shift.

Apply freshness thresholds using the Source Provenance data — enrichment past a certain age gets flagged for re-verification before it's used in outreach, catching exactly the kind of stale-fact embarrassment (congratulating someone on a role they've left) that undermines trust in the whole system. For scoring, apply the same drift-monitoring principle used for any production ML model: track the scoring model's real-world accuracy over time and re-validate or retrain as market conditions shift, rather than assuming a model validated once stays accurate indefinitely.

Design for the unhappy path: Write validator down → fail closed, protects the shared CRM. Stale enrichment → freshness thresholds catch it before it's used. Scoring model drift → the same ongoing-monitoring principle as any production ML model. A CRM agent that only works with perfectly fresh data and a permanently-accurate scoring model is a demo; one that catches its own staleness and drift is a product.

You did it

You just designed a sales CRM agent.

• M — a
• M — u
• L — e
• W — r
• T — h
• P — e
• A — u
• F — r