A Sample Machine-Agent Pilot: CRM Enrichment With Receipts

The first useful machine-agent pilot should be boring.

Not “let the agent run sales.” Not “give it the whole CRM.” Not “connect browser, email, calendar, Slack, and Stripe and see what happens.”

A good first pilot is narrow enough to inspect and valuable enough to matter. My favorite example right now is CRM enrichment: take a small batch of stale leads, verify public company information, write source-linked notes, and queue uncertain matches for a human.

It is not glamorous. That is the point. It touches a real business system, but the blast radius can be controlled.

The pilot

Enrich 25 stale CRM leads by finding each company's current website and one public evidence source. Add a private note with sources. Do not email anyone. Do not change lifecycle stage, owner, score, forecast, or sequence enrollment. Queue uncertain matches for review.

This pilot is useful because it forces the hard production questions without risking irreversible action:

• Can the agent distinguish public source evidence from guesses?
• Can it act only inside delegated CRM fields?
• Can it stop instead of forcing low-confidence matches?
• Can a human inspect what changed after the run?
• Can the team reverse the changes if the policy was wrong?

Workflow-scoped authority

The agent does not get “CRM access.” It gets a workflow contract.

This is the difference between “agent autonomy” and “delegated authority.” The first is vague. The second can be audited.

The source-of-truth rule

CRM enrichment fails when the agent treats any plausible web result as truth. The source rule needs to be explicit:

1. Prefer the official company website or verified domain.
2. Use LinkedIn/company profile pages only as secondary evidence.
3. Do not rely on scraped directory pages as canonical sources.
4. If the company name is ambiguous, queue it.
5. If two sources conflict, queue it.
6. If the source is older than the freshness window, mark it low confidence.

That looks like process overhead until you compare it with the alternative: an agent confidently writing incorrect company data across your CRM.

What the agent should produce

The deliverable should not be “done.” It should be a receipt.

That short receipt gives a human the shape of the run in 30 seconds. Then they can inspect details only where needed.

The exception queue is the product

The most important output may be the six records the agent refused to enrich.

Good agents should not only complete tasks. They should also preserve uncertainty. For this pilot, exceptions might include:

• Two companies share the same name in different regions.
• The official site redirects to a parent company.
• LinkedIn and the company website disagree on current status.
• The lead appears to be an individual consultant, not a company.
• The only available source is a stale directory listing.
• The CRM record is missing enough context to identify the account.

If the agent guesses on those, it looks productive and silently corrupts state. If it queues them, the workflow becomes safer every run.

Rollback and compensation

Before the pilot starts, decide how to unwind it.

For this example, the allowed changes are intentionally reversible:

• Private notes can be deleted.
• Review queue items can be closed.
• No outreach was sent.
• No status or ownership fields changed.
• No durable contact memory was written.

That is why CRM enrichment is a good first machine-agent pilot. It lets the team test browser/SaaS operation, source checking, scoped writes, exception handling, and receipts without giving the agent irreversible authority.

What to measure

Do not measure only records processed. That rewards speed over trust.

Measure:

• Completion quality: enriched records with usable source evidence.
• Exception quality: queued records that really needed review.
• Policy adherence: forbidden field changes, unauthorized actions, missing receipts.
• Human review time: minutes to inspect and approve/reject the run.
• Rollback readiness: whether every external change can be undone or compensated.
• Memory hygiene: whether durable memory writes were proposed, scoped, and approved instead of silently added.

The scaling path

If the pilot works, do not jump straight to full autonomy. Expand one axis at a time:

1. More records, same permissions.
2. More source types, same permissions.
3. Draft outbound messages, but do not send.
4. Allow low-risk status tags only after approval.
5. Only then consider automatic follow-up for a tightly defined subset.

Every expansion should have a new receipt requirement. Autonomy compounds through controlled permission increments, not leaps of faith.

The pattern

This is bigger than CRM enrichment. The same pilot structure works for:

• Invoice intake triage.
• Vendor record cleanup.
• Support ticket classification.
• Recruiting pipeline enrichment.
• Knowledge-base update drafts.
• Renewal-risk research.
• Backlog grooming.

Pick a workflow with real value, reversible changes, clear sources, and obvious exception cases. Then require receipts from day one.