Sales Agent: Make the CRM True, Then Worry About Selling

Enterprise Agent Mesh Engineering Guides · 09/12 · AI-Agent Factory

Build a Sales Agent that earns the right to assist sellers by first making CRM state trustworthy: every proposed field update is tied to something an external customer actually said or wrote, every change is reviewable and reversible, and commercial authority stays outside the model.

This guide adapts Article 9 of The Enterprise Agent Mesh — Building Twelve Production AI Agents on Claude Code. It preserves the handbook’s central claim: make the CRM true, then worry about selling. The agent’s highest-value job is converting calls, mail and meetings into evidence-backed state—not inventing persuasion at higher volume.

Reference design, not a client case study. The handbook contains one reference deployment’s figures, sample thresholds, implementation sketches and failure modes. They are not independently verified Infinity Technologies client results or universal benchmarks. Notes marked Web-edition qualification identify changes made after checking current official documentation. Code below is reference architecture, not a complete deployable repository. Technical references checked 16 September 2026.

The useful Sales Agent does not manufacture confidence. It converts customer evidence into structured state and makes uncertainty visible.

The Header illustration is shared Enterprise Agent Mesh platform artwork. It is not a Salesforce screenshot, a Sales Agent UI, or a representation of a measured Infinity Technologies deployment.

1. What this agent is actually for

The source treats CRM hygiene as the foundational workflow. Calls, email threads and meetings produce proposed changes on accounts, contacts and opportunities. Those changes carry source evidence and initially go through a field-level human review. The reason is architectural rather than cosmetic: forecasts, territory design, staffing, product prioritisation and compensation all consume CRM state. Generating better sales prose over false state simply amplifies the wrong system.

The handbook reports substantial reference benefits from CRM hygiene, pre-call briefing and RFP assembly. Those figures describe one B2B software reference deployment and are not benchmarks. Measure the local outcome as accepted field changes, correction rate, time-to-review and downstream data-quality lift—not as a generic promise that a CRM agent recovers a fixed number of selling hours.

Hard ceilings

The agent must never quote a price, discount or contractual term outside approved content; promise unreleased product functionality or dates; introduce legal wording outside the approved fallback library; autonomously write StageName, Amount, CloseDate, ForecastCategory, ownership or closed-opportunity state; or send outbound mail without the separately governed customer-contact basis and send policy. Customer-facing commercial paper stays L2 permanently.

Promotion is workflow-specific. The handbook’s six-field safe write-back set can reach L3 only after sustained reviewer acceptance and zero write-scope canary violations. That is a source reference threshold, not a universal promotion rule. A field is eligible for promotion only if its blast radius is bounded, the write is reversible, provenance is complete and the business owner explicitly accepts automated mutation.

Web-edition qualification — sales assistance and forecast probability are separate products. The source intentionally uses the LLM to find missing evidence and risk signals, while a separate statistical model consumes those signals alongside structured features. Do not relabel a language-model “confidence” as a calibrated win probability. If a probability is required, train, calibrate and monitor it as a separate model with its own model-risk and data-science controls.

2. Architecture

Everything begins with events. A call is transcribed, a relevant mail thread arrives, a customer meeting is booked or an opportunity ages past a threshold. Each event creates a bounded unit of work; the orchestrator routes it to one narrow role. The model that proposes a CRM change cannot apply one.

agent.sales.call.transcribed   agent.sales.mail.threaded   agent.sales.opp.stale
             \                         |                         /
              +------------------------+------------------------+
                                       |
                             revops-orchestrator
                       sonnet-class routing / batching
                              NO CRM apply tools
                        /              |                \
                       v               v                 v
            deal-signal-extractor  account-briefer   pipeline-inspector
            haiku / strict schema  read-only         opus / signals only
                       |
                       v
               crm-diff-proposer
               no apply capability
                       |
              propose_crm_update
                       |
              human field review
                       |
       model-free apply service under human identity
                       |
        concurrency check + crm_write_log + revert token

The source uses Haiku-class extraction for rigid classification and span selection, Sonnet-class reasoning for briefs, diffs and drafts, and an Opus-class pipeline inspector for cross-opportunity analysis. Preserve the task decomposition, but treat actual model IDs as deployment configuration gated by evaluation rather than timeless architecture.

The separation between proposal and apply is the important control. crm-diff-proposer can call a tool that writes a review queue entry but has no capability to mutate Salesforce. A separate non-LLM service applies approved fields using an authenticated human context and records before/after values, evidence, approval and a revert token.

Cross-agent work is event-driven. Non-standard terms become an event for Legal; closed-won state can wake an Operations workflow; Marketing-qualified leads arrive with their own evidence payload; Supply Chain or Operations risk can become an account-team signal. These payloads are data, not instructions, and receiving agents keep their own tools, ACLs, evals and evidence-ledger entries.

3. Repository layout and CLAUDE.md

sales-agent/
  .claude-plugin/plugin.json
  .mcp.json
  CLAUDE.md
  agents/
    deal-signal-extractor.md
    crm-diff-proposer.md
    pipeline-inspector.md
    proposal-drafter.md
  skills/
    meddicc-audit/SKILL.md
    meddicc-audit/reference.md
    pre-call-brief/SKILL.md
    rfp-assembly/SKILL.md
  hooks/
    hooks.json
    crm_write_gate.py
    claim_approval.py
    mailbox_consent.py
  mcp/
    crm/server.py
    conversation/server.py
  evals/
    golden/calls_300.jsonl
    golden/proposals_120.jsonl
    canary/write_scope.jsonl

Stable invariants belong in CLAUDE.md; procedural detail belongs in skills; customer-facing claims, pricing, battlecards and contract language belong in approved retrieval. The source keeps fiscal-calendar semantics, currency, stage names, MEDDICC mapping and the evidence rule resident because they affect almost every turn.

# Sales Agent — operating invariants (web-edition excerpt)

## CRM truth
Stage is human-owned. Report unmet exit criteria; never change StageName.
Never write Amount, CloseDate, ForecastCategory, OwnerId or a closed opportunity.
A field proposal must be based on a named external speaker's statement or external message,
with an immutable source reference. Inference is not write evidence.

## Evidence states
stated        -> may enter a field proposal if the field is eligible
inferred      -> visible to a reviewer, never a write candidate
not_discussed -> explicit absence; do not fill from prior probability or seller summary

## Commercial authority
Prices, discounts, terms, SLAs and competitive claims come only from approved,
unexpired content. No unreleased product or roadmap commitment.
Non-standard terms -> event to Legal and stop.

## Data handling
Keep customer utterances and seller paraphrases distinct.
Unknown speaker affiliation is not customer evidence.
Every enrichment datum carries as_of and provenance.

The source’s seven fixed stages are a reference-deployment configuration. A production agent must ingest the organisation’s approved stage vocabulary and field map as reviewed configuration; do not bake another company’s stage semantics into the model.

4. Subagents

Deal-signal extractor

deal-signal-extractor reads one transcript or mail thread and returns structured MEDDICC and deal-state signals. It does not summarise the call or judge deal health. For each field it returns stated, inferred or not_discussed. Only stated can enter the CRM proposal path.

---
name: deal-signal-extractor
description: Extract evidence-backed MEDDICC and deal-state signals.
tools: mcp__conversation__fetch_transcript, mcp__conversation__extract_deal_signals
disallowedTools: Write, Edit, Bash, mcp__crm__apply_crm_update
model: haiku
maxTurns: 6
---
Use only utterances with authoritative party=external for customer evidence.
For stated evidence preserve speaker, source id, timestamp and verbatim quote.
Never combine speakers or treat the rep's recap as a customer statement.
A metric requires an explicit number, unit and business object.
Unknown attribution -> not_discussed or a data-quality finding.

The extractor’s output is only accepted after code verifies the quoted text against the authoritative transcript around the claimed timestamp. Structured output gives shape; verification gives literal provenance. A failed quote invalidates the extraction run rather than quietly dropping one difficult field and accepting the rest.

CRM diff proposer

crm-diff-proposer rereads the current opportunity, captures the concurrency token and field-level human-edit metadata, discards inferred signals and prepares a small reviewable diff. A human correction newer than the evidence wins by default. Strong conflicting new evidence becomes an explicit human_edit conflict for review, not an overwrite.

The source caps one conversation at eight proposed field changes. Treat that as a reference blast-radius limit. The general rule is that the review unit must be small enough for a human to inspect individually; a 20-field diff invites bulk approval and defeats the purpose of field-level evidence.

Pipeline inspector

pipeline-inspector searches for reasons to disbelieve the forecast: no external economic-buyer engagement, champion movement, single-threaded activity, missing security review, legal not engaged, stale mutual action plan, persistent competitor, missing next step and stage-age outliers. Each signal names the query/call evidence and distinguishes a real absence from a possible data gap.

It is explicitly forbidden to output close probability. The downstream warehouse model owns calibrated probability; the LLM owns evidence discovery and narrative explanation. That structural split prevents a fluent probability from becoming an untested forecast feature.

Proposal drafter

The fourth role produces customer-facing proposal language only from the approved-content store. It cannot retrieve draft, deprecated or expired commercial content. Every substantive customer-facing sentence carries a source marker until a Stop-stage verifier checks approval state, expiry and entailment, then removes those internal markers from the deliverable.

5. Skills

Pre-call brief

The pre-call brief is read-only and intentionally current. It resolves attendees to CRM contacts, displays recorded deal state and recent field changes, retrieves up to a small set of verbatim customer quotes, names qualification gaps, proposes grounded questions and surfaces open support escalations, overdue invoices and active risk signals.

Brief order
1. Who is in the room — invite attendee -> CRM contact, role, last interaction.
2. State of the deal — stage, amount + ISO code, close date, days in stage, recent edits.
3. What the customer said last time — verbatim external quotes with timestamps.
4. Open gaps — MEDDICC fields that remain not_discussed.
5. Grounded questions — each tied to a real gap and prior customer evidence.
6. Watch-outs — support, invoice and risk signals.

Enrichment must carry an as_of time. The handbook labels data older than 90 days unverified and omits data older than 180 days. Those are reference thresholds; production policy should be source-specific. The durable rule is that a generated org chart cannot erase freshness metadata.

MEDDICC audit

The audit distinguishes evidenced, asserted-only and absent. asserted-only is especially useful because it identifies a populated CRM field with no retrievable customer evidence behind it. The skill does not compute a qualification score; averaging dimensions can hide the one missing factor that matters.

Stage exit criteria and labelled borderline examples live in a progressively loaded reference file rather than in every context. The same principle should be used for segment-specific sales methodology: load the detailed rubric when adjudication is required, not for every call ingest.

RFP assembly

RFP answers are retrieved from the approved answer library with version and owner metadata. A match may be drafted; a gap routes to a named content owner. The system never fills a security or contractual gap from generic model knowledge merely to improve completion rate.

6. Integrations and MCP layer

Salesforce: current authentication and API reality

The handbook uses an OAuth JWT bearer connected-app pattern. For new integrations, Salesforce now recommends External Client Apps: creation of new Connected Apps is restricted as of Spring ’26, while existing Connected Apps continue to work. The Salesforce REST API authorization guide is the source of truth for this transition. JWT bearer remains appropriate for non-interactive server-to-server authentication where the selected app type and org policy support it.

Monitor limits instead of copying a fixed request number into a prompt. Salesforce’s API limits reference documents org-level rolling allocations and the Sforce-Limit-Info header; the /limits resource exposes current allocation. Batch deliberately. Composite supports up to 25 subrequests, while sObject collection operations have their own record bounds. Use Bulk API 2.0 for large snapshots rather than fanning out one model-driven request per opportunity.

Web-edition qualification — optimistic concurrency. The handbook proposes SystemModstamp plus conditional requests “where supported.” Keep the first part. Salesforce’s conditional request documentation shows that strong ETag validation is resource-limited, while time-based If-Unmodified-Since is broader but still a weak timestamp check. The apply service should re-read authoritative state and fail closed on stale proposals; do not advertise generic ETag compare-and-swap for every opportunity resource.

Microsoft 365 mailbox scope

The source uses Microsoft Graph application permissions and refers to Application Access Policies. Microsoft now labels those policies legacy and states that RBAC for Applications in Exchange Online replaces them for granular resource-scoped app access. For new mailbox-reading designs, use current App RBAC with an explicit resource scope and avoid combining broad Entra application consent with a narrower rule in a way that accidentally expands effective access.

Mailbox enrolment remains a governance decision, not just an OAuth configuration. Restrict which mailboxes can be read, which folders/messages are eligible for ingest, what evidence is persisted, and how employees are informed. Works-council and privacy review depend on jurisdiction and actual monitoring use; they are not solved by the transport layer.

Custom conversation and CRM tools

The conversation tool returns a schema-constrained object, but code re-verifies every quote against the transcript. The CRM tool accepts only a named writable set and rejects forbidden fields, non-stated evidence and oversized diffs. propose_crm_update creates a review artifact; it does not mutate Salesforce.

# Reference contract — organisation-owned tool, not Salesforce native API
propose_crm_update(
  opportunity_id,
  source_event_id,
  concurrency_token,
  idempotency_key,
  proposed = {
    field_name: {
      state: "stated",
      value: typed_value,
      evidence: {source_id, speaker, party, timestamp_ms, quote}
    }
  }
)

server rules:
  reject forbidden or unknown fields
  reject anything except state=stated
  verify source evidence belongs to this opportunity
  surface newer human edits as conflicts
  cap proposal blast radius
  write immutable proposal + evidence digest
  NEVER apply the CRM change from this tool

7. Retrieval design

Corpus 1: approved customer-facing content

Customer-facing generation uses an approved-content store: fallback clauses, standard SOW language, RFP/security answers, legal-approved competitor battlecards, pricing policy, product documentation, win/loss analyses and reviewed proposal content. Content carries approval state, owner/version and expiry.

approval_state: draft | approved | deprecated | withdrawn
approved_by: principal-id
approval_version: immutable-version
expires_at: timestamp

customer-facing retrieval predicate:
  tenant = authenticated tenant
  AND ACL intersects caller principals
  AND approval_state = approved
  AND expires_at > transaction time

The source uses a 90-day battlecard expiry as a reference policy. The general requirement is fail-loud staleness: expired comparative content should disappear from the allowed generation set and create an explicit gap, not remain silently available because its vector still matches.

Sentence-level provenance

A proposal sentence maps to an approved source chunk and version or it does not ship. The source uses internal trailing markers and a Stop-stage verifier that re-fetches cited chunks, checks approval/expiry and evaluates entailment before removing markers. Boilerplate is allowlisted separately. This is much stronger than asking the draft model to “use only approved claims.”

An LLM judge in that critical path must itself be versioned and tested. Deterministic checks still own chunk existence, approval state, expiry, tenant/ACL and marker coverage; the judge answers only the semantic entailment question it is actually needed for.

Corpus 2: conversations

Fixed 800-token windows are a poor unit for transcript evidence because they cut across speaker boundaries. Chunk by speaker turn, merging consecutive turns by the same speaker up to a bounded size and never merging speakers. Prefix each chunk with a generated contextual header naming the call, account/topic and attendees, while retaining immutable call and offset metadata.

Index external-customer utterances separately from seller utterances. Sales reps frequently paraphrase a customer more fluently than the customer spoke, so a mixed index can rank the rep’s interpretation above the source statement. A party filter is therefore part of retrieval, not a prose reminder.

The handbook’s recall/nDCG targets are reference evaluation thresholds. Preserve the discipline—measure approved-content recall and customer-utterance recall separately—but set release gates from your curated corpus and business risk. Keep evidence bounded; dumping a full transcript into context makes attribution harder, not safer.

8. Guardrails

Field-write gate

A write-shaped request is accepted only if every field is in the eligible set, evidence is stated, the quote is verified from an external party and the current CRM revision still matches the proposal. Forbidden commercial/forecast fields fail before the model can negotiate around the restriction.

FORBIDDEN = {
  "StageName", "Amount", "CloseDate",
  "ForecastCategoryName", "OwnerId", "Probability"
}

proposal accepted only when:
  field in reviewed_safe_set
  AND state == "stated"
  AND evidence.party == "external"
  AND evidence.quote_verifies == true
  AND proposal_record_version == current_record_version

apply accepted only when:
  authenticated_human_approval binds exact proposal digest
  AND human currently has field-level entitlement
  AND approval not expired
  AND record has not changed incompatibly

The applying identity and proposing identity remain separate. Tool names and hook decisions are defence-in-depth; the backend must enforce the same boundary. A model-supplied user id is not human approval.

Customer communication gate

Outbound messages need policy checks outside the language model: permitted contact basis, approved sender, channel/region rules, unsubscribe/opt-out handling where applicable, and scanning for forbidden forward-looking product or unapproved commercial statements. The handbook’s example regex is a backstop, not a legal compliance engine.

Pricing and competitive statements are governed by retrieval. If there is no approved, current chunk that entails the claim, the sentence cannot ship. Non-standard contractual terms route to Legal through an event and stop the Sales Agent’s action path.

Mailbox privacy boundary

Read only mailboxes and message classes that are intentionally enrolled. Filter irrelevant/private content before model access; persist extracted evidence rather than full mail bodies where the retention design permits; and record data lineage. The source warns that retained quotes become business records subject to discovery and retention. Treat monitoring-law and works-council review as an implementation prerequisite where applicable.

Web-edition qualification — hooks are not the perimeter. The current Agent SDK hook documentation confirms that PreToolUse can block or modify calls. Use it. But backend scopes, service identity, field-level permissions and separate apply services remain authoritative. A runtime callback cannot safely replace system-of-record authorisation.

9. Production deployment

Call ingest is a bounded event worker: one call event, one extraction, one proposal artifact. A content-based idempotency key ties the logical work to the call and opportunity. The worker never exposes the apply tool.

# Reference excerpt — dependencies and organisation-owned services omitted.
from claude_agent_sdk import ClaudeSDKClient, ClaudeAgentOptions

OPTIONS = ClaudeAgentOptions(
    model="<pinned-sales-worker-model>",
    mcp_servers={"crm": crm, "conversation": conversation, "corpus": corpus},
    allowed_tools=[
        "mcp__conversation__fetch_transcript",
        "mcp__conversation__extract_deal_signals",
        "mcp__crm__read_opportunity",
        "mcp__crm__diff_crm",
        "mcp__crm__propose_crm_update",
    ],
    disallowed_tools=["Bash", "Write", "Edit", "mcp__crm__apply_crm_update"],
    permission_mode="default",
    max_turns=18,
    include_hook_events=True,
)

# event handler must atomically claim logical work before running the model;
# completion and the outbound review-queue record are committed together.

The handbook’s max_budget_usd=0.45 per call and larger brief budget are reference deployment circuit breakers, not pricing commitments. Set cost/turn/time ceilings from observed local traffic and treat abnormal consumption as an operational signal.

Do not describe “check then mark processed” as exactly-once. An event consumer can crash after creating a proposal and before marking success. Use an atomic job claim or unique logical key, terminal states and an outbox/reconciliation pattern. A redelivered event should recover the same proposal or safely determine that the source state has changed, not open a second review diff.

For CRM apply, use a model-free service. Re-read the opportunity, compare the stored proposal version with current state, validate human approval and write only the approved field list. Record before, after, proposal/evidence references, human identity, timestamp and revert condition. A revert succeeds only if the field still holds the value written by that operation; otherwise it becomes a new reviewed change.

10. Evaluation

The handbook’s golden set combines labelled calls, proposal drafts and a write-scope canary, refreshed from live traffic because seller behaviour adapts to the extractor. Preserve that distribution-aware design: a frozen benchmark can look better while the field population in production gets worse.

These thresholds are source reference values, not reported Infinity client performance. Absolute gates such as citation validity and forbidden-field writes should remain strict on the test set, while the organisation separately reports test coverage and production incidents. “100% on this suite” is not a guarantee that all future calls are safe.

Signals, not LLM probabilities

For opportunities that slipped or closed lost, measure whether the evidence signals were present at the defined lookback horizon. Do not score language-model probability calibration if the LLM does not produce probability. The downstream statistical model owns calibration, Brier/log-loss or whatever forecast metrics the data team chooses.

Adversarial and canary slices

Include vague-budget phrasing, rep paraphrases, unknown speaker roles, diarisation degradation, stale enrichment, human-edited CRM fields, closed opportunities, unapproved battlecard text, prompt injection in external content, stale proposal versions and customer communications containing unapproved commitments. Canary tests should assert that forbidden fields never leave the proposal boundary.

The source uses an Opus-class judge for proposal-sentence entailment and brief quality. Validate that judge against expert labels and keep deterministic assertions—quote verification, approval state, expiry, write scope, ACL and record revision—outside the judge.

11. Failure modes described in the handbook

Budget inferred and written as fact

“We have something set aside this year” becomes a numeric budget and a confirmed flag. The mitigation is structural: an explicit metric requires a number with a unit and business object; inferred evidence cannot reach the write path. Vague-budget adversarial examples belong in every release suite.

Overwriting a rep’s correction

A human fixes the economic buyer after the call, then replaying the old call proposes the stale value again. Field-level human-change metadata and optimistic concurrency ensure newer human edits win by default. Genuine conflict is surfaced for review rather than overwritten.

Diarisation flips who said what

A customer objection attributed to the seller can disappear; a seller’s summary attributed to the customer can become false evidence. Party affiliation comes from authoritative meeting/transcript metadata, not from the LLM’s guess. Unknown-party utterances cannot support CRM writes, and degraded diarisation reduces or disables the writable field set.

Stale enrichment becomes a confident org chart

Every enrichment field carries as_of and source. Stale information is visibly qualified or omitted under source-specific policy. Never remove freshness metadata when rendering a pre-call brief.

The plausible but unapproved competitor claim

A model can generate a persuasive comparison that legal never approved. Only approved, current battlecard chunks are retrievable for customer-facing comparative copy, and the sentence-level provenance gate blocks anything unsupported. Expiry turns maintenance failure into a visible content gap.

Goodhart arrives on schedule

Once sellers discover which phrases populate MEDDICC fields, completion can rise without deal quality improving. Refresh evaluation data from live calls, monitor suspicious per-rep distribution shifts and never feed extraction completeness directly into compensation or a manager scorecard. The moment people are paid for “making the extractor green,” the system measures gaming.

12. Build order

Week 1: read-only CRM truth

Start with a least-privilege Salesforce integration, read_opportunity and bounded read queries. Build deal-signal extraction with strict schema and verbatim verification before any write path. Ship the pre-call brief read-only. This creates user value while producing real evidence about identity resolution, transcript quality and stale data.

Month 1: reviewable write proposals

Add propose_crm_update, field-level review UI, immutable crm_write_log, revert semantics, record-level rate limits and a forbidden-field canary suite. Operate at L2 with a small team and label every accept/reject decision. That review phase is the cheapest time to build the local golden set and identify fields that should never be automated.

Quarter 1: governed generation and forecast signals

Add approved-content retrieval with expiry, proposal drafting behind the sentence-approval verifier, the pipeline inspector and the separate statistical forecast model. Promote only the specifically approved safe CRM fields to L3 after sustained clean live evidence. Complete mailbox access/privacy and employee-representation review before scaling to regions that require it.

The week/month/quarter sequence is a source implementation order, not a delivery commitment. The invariant is sequencing: truth and provenance first, reversible field proposals second, customer-facing generation and higher autonomy last.

Sources and implementation notes

Primary source: Article 9, “The Sales Agent: Make the CRM True, Then Worry About Selling”, plus the shared Agent Gateway, identity, corpus, evidence-ledger, evaluation and message-bus patterns in The Enterprise Agent Mesh — Building Twelve Production AI Agents on Claude Code, September 2026.

Explicit web-edition qualifications: new Salesforce integrations should account for the Spring ’26 shift toward External Client Apps; API quotas are runtime org facts rather than constants; conditional-request capabilities are resource-specific; Microsoft Application Access Policies are now legacy and App RBAC is the current Exchange mailbox-scoping control; mailbox privacy/works-council review cannot be reduced to an OAuth setting; event idempotency requires an atomic business-state design rather than a pre-check; and hooks remain defence-in-depth rather than the system-of-record authorisation layer.

• Salesforce REST API: External Client Apps, Connected Apps and OAuth.
• Salesforce API request limits and monitoring, Composite API, and conditional request headers.
• Microsoft Exchange Online: RBAC for Applications and the legacy Application Access Policies page documenting the replacement.
• Claude Code custom subagents and Agent SDK execution hooks.
• Claude Agent SDK overview. Runtime and model configuration must be pinned and revalidated against the deployed version.

Explore the enterprise series

This is guide 09/12 for the business-function agents in Infinity Technologies’ AI-Agent Factory hexagonal mesh. It is separate from the InfinitySDLC engineering-agent series.

Previous: 08 Customer Support Agent — Containment Quality, Not Deflection Rate.

Next: 10 Marketing Agent — Generation Is the Commodity, the Constraint System Is the Product. Forthcoming; no unpublished page is linked here.