SYSTEM BUILD

THE AGENTIC SALES BRIEF / SYSTEM 01

An account research agent should make a rep faster without making the rep less certain. That requires more than a prompt that returns a confident company summary.

The useful system is a bounded workflow:

❝

approved inputs → bounded research → human approval → evidence pack

Its most important output is not prose. It is a claim ledger that tells the rep what the system found, where it found it, when the source was checked and whether the claim is safe to use.

This guide shows how to build that system without tying it to one model, enrichment vendor or CRM.

The problem: a polished brief can still be unsafe

Most account research prompts optimise for a readable answer. Sales work needs a different standard.

A rep needs to know:

  • Is this statement a fact, an inference or a vendor claim?

  • Is the source primary and current?

  • Does the source actually support the wording?

  • Is the information about the company, a person or an unrelated entity with a similar name?

  • Can this claim be used in a customer-facing message?

If the brief hides those questions, the rep has to repeat the research or take a risk. The workflow has saved keystrokes, not created reliable sales intelligence.

What the agent is—and is not

The agent's job is to assemble a reviewable research pack for one approved account and one defined sales purpose.

It may:

  • retrieve information from approved internal records and public sources

  • identify potentially relevant business signals

  • extract evidence with source metadata

  • label facts, vendor claims and interpretations

  • draft a short account brief

  • flag missing or conflicting evidence.

It may not:

  • choose new target accounts on its own

  • access unapproved databases or personal accounts

  • infer sensitive personal characteristics

  • turn an inference into a fact

  • write unverified findings into critical CRM fields

  • send outreach

  • change account ownership, stage, pricing or commercial terms.

This is bounded autonomy: the system can complete a multi-step research task, but it cannot decide what the business should claim or send.

1. Define the owner and the decision

Every run needs one accountable owner. In a lean team, that is usually the account executive, founder or RevOps operator who requested the brief.

The owner defines the decision the research should support. For example:

❝

Prepare for a first discovery call by verifying the company's business model, current priorities and two evidence-backed hypotheses about where our offer may be relevant.

That is better than research Acme Corp. It gives the system a purpose and a stopping point.

Write down three fields before the first run:

Field

Example

Account

The exact legal or trading entity

Sales decision

Prepare for a first discovery call

Recency rule

Current facts checked within 30 days; older context dated explicitly

The recency rule should vary by claim. A company founding date is stable. A leadership role, product plan or price can change quickly.

2. Approve the inputs

Use the smallest input set that can answer the sales question.

Internal inputs

  • the CRM account and opportunity record

  • prior meeting notes that the user is authorised to access

  • approved product, ICP and qualification material

  • relevant customer history

  • known exclusions or conflicts.

External inputs

  • the company's official website and documentation

  • official filings, investor material or regulatory records when relevant

  • named executive posts or interviews

  • trusted news and research sources

  • vendor pages, clearly labelled as vendor claims.

Do not give the agent a blanket instruction to search everything it can access. Data minimisation is a useful design principle even before a legal assessment: process only what the workflow needs, keep the purpose explicit and avoid copying personal data into systems without a defined reason. GDPR Article 5 makes purpose limitation, data minimisation and accuracy explicit principles when personal data is processed.

Create an allowlist for sources and tools. If the system needs a source outside the list, it should ask for approval or record the gap.

3. Make the output a claim ledger

The research brief is a view. The claim ledger is the control layer.

For every material externally verifiable claim, store:

claim_id
claim_text
claim_type: verified_fact | vendor_claim | interpretation
source_url
source_title
source_publisher
published_at, if available
retrieved_at
evidence_location
support_status: supported | contradicted | not_verified
confidence_note
review_status
reviewer

“Every claim” does not mean citing connective words or the rep's own recommendation. It means every material external statement that could change the sales decision or appear in a customer-facing message.

Use three plain states:

  • Supported: the source directly supports the wording.

  • Contradicted: a credible source conflicts with the wording.

  • Not verified: the system did not find enough evidence.

Do not turn Not verified into a low-confidence fact. Uncertainty is an output.

4. Separate retrieval from interpretation

Run the workflow in two passes.

Pass A: evidence retrieval

The system collects source records and extracts only what each source supports. It should prefer the account's own current material for claims about its product, team and announcements, while labelling those statements as first-party.

Pass B: sales interpretation

Only after the ledger exists should the system propose implications such as:

❝

Interpretation: the announced hiring focus may indicate pressure to standardise onboarding, but no source reviewed describes the current sales process.

That sentence is useful because it preserves the boundary between evidence and hypothesis. It gives the rep a question to test rather than a claim to repeat.

5. Put the human gate before downstream use

The reviewer should see the brief and ledger together.

The gate has four decisions:

  1. Approve supported claims for internal preparation.

  2. Restrict a claim to internal use only.

  3. Correct the wording or entity match.

  4. Reject the claim and stop it from reaching outreach or the CRM.

Require explicit approval before:

  • a material claim enters a customer-facing draft

  • a new field is written to the CRM

  • the system changes an existing source-of-truth field

  • the brief is shared outside the authorised team.

The system should never treat silence or a timeout as approval.

6. Design the tools as replaceable components

The workflow needs capabilities, not a specific vendor stack:

  1. Trigger: a user requests research for an approved account.

  2. Identity resolver: confirms the correct legal or trading entity.

  3. Retrieval layer: queries approved internal and external sources.

  4. Reasoning layer: extracts claims and proposes interpretations.

  5. Evidence store: saves the ledger and source metadata.

  6. Review interface: lets a human approve, correct or reject.

  7. Output layer: produces an evidence pack and, optionally, approved CRM suggestions.

Keep credentials scoped to read-only access during the first pilot. A research system does not need permission to send email or edit opportunities.

7. Handle failure visibly

Define failure states before the first real account.

Failure

System response

Human fallback

Entity is ambiguous

Stop and ask the user to confirm

Select the correct entity

Source is unavailable

Record URL and access failure

Review manually or use another approved source

Sources conflict

Mark contradicted; show both

Decide which source is authoritative

No publication date

Flag recency as unknown

Approve only if the claim is stable

Model cannot support wording

Mark not_verified

Rewrite as a question or remove

Internal data lacks permission

Do not retrieve or copy it

Request access through the normal process

Tool or model outage

Save the run as incomplete

Use the existing manual research checklist

Log the run ID, user, account, source list, tool calls, model/version where available, approvals, corrections and final export. Avoid logging secrets or unnecessary personal data.

NIST's voluntary AI Risk Management Framework and Generative AI Profile organise risk work around governance, mapping, measurement and management. For a lean sales team, the practical translation is simple: assign an owner, map the workflow and affected people, measure quality and risk, and define how the system is controlled or stopped.

8. Measure quality before speed

Track three layers.

Quality

  • material-claim support rate

  • incorrect entity matches

  • contradicted claims per brief

  • human corrections per brief

  • share of claims left Not verified.

Efficiency

  • median time from request to review-ready pack

  • human review time

  • manual source searches still required.

Commercial usefulness

  • briefs used in real call preparation

  • rep rating of decision usefulness

  • discovery questions created from verified evidence

  • qualified next steps influenced by the research.

Do not optimise for the longest brief or the highest number of sources. A smaller pack with five relevant, supported claims is usually more useful than a dense report that hides uncertainty.

9. Run a 30-day pilot

Start with one owner and one use case.

Week 1: build the evaluation set

Choose 10 accounts the team already knows. Create a manual reference pack for each. Include easy, ambiguous and sparse-data cases.

Week 2: run in shadow mode

Generate briefs without writing to the CRM or affecting outreach. Compare the ledger with the reference packs.

Week 3: allow reviewed internal use

Let reps use approved briefs for call preparation. Record corrections and missing evidence.

Week 4: decide

Continue only if the system meets the agreed support-rate and entity-match thresholds without unacceptable privacy or trust failures. Do not invent a universal target. Set it from the risk of your sales motion and the quality of the manual baseline.

10. Define the shutdown path

The owner must be able to:

  • disable the trigger

  • revoke tool credentials

  • stop all scheduled runs

  • prevent new CRM suggestions

  • retain or delete logs according to policy

  • return immediately to the manual research checklist.

Test the shutdown before production use. A system is not controlled if the team does not know how to stop it.

The build checklist

  • One account and one sales decision per run

  • Exact entity confirmed

  • Approved source and tool allowlist

  • Material claims stored in a ledger

  • Facts, vendor claims and interpretations separated

  • Not verified is a valid output

  • Human gate before CRM changes or customer-facing use

  • Failures and conflicts visible

  • Quality, efficiency and commercial metrics defined

  • Trigger and credentials can be disabled safely

Build your first bounded workflow

The free Agentic Sales System Starter Kit gives you the System Canvas, Permission Map, Human Gate, Failure and Fallback sheet, Evidence Card and 30-Day Test used in this design.

Scope one bounded AI sales workflow with a clear owner, human gate, fallback and 30-day test.

Get the free Starter Kit

Sources and further reading

This article provides general operational guidance. Data protection, recording, marketing and employment rules vary by use case and jurisdiction; get qualified advice for your situation.

Build systems your team trusts—and your pipeline can prove.

© 2026 Agentic Sales Lab.
beehiivPowered by beehiiv