Your CRM Killed a Good Lead Because One Number Bounced. Build the Agentic Contactability Ledger.
A failed phone number is not a failed person. Most customer systems still act as if it is.
A lead arrives from a website, referral partner, imported roster, event list, old database, or purchased source. The first text hard-bounces. A workflow changes the lead to bad, dead, or unreachable. Every downstream automation politely agrees. A viable email address, a corrected number, and a permitted service channel remain untouched because the database has confused one broken route with the human being at the other end.
A public post from an insurance operator on September 12 described AI agents taking an overnight SFTP drop through deduplication across eight rosters, lead tagging, and CRM delivery. The operator then captured the problem in eight words:
“The part nobody posts: one bad phone number can't kill a contact.” 1
That is more than a data-cleaning tip. It is an operating model for agentic AI.
The right design gives every person, endpoint, permission, and action its own state. Several narrow Oppy agents may classify evidence and propose recovery. A deterministic policy gate decides whether anyone may be contacted. When one route fails, the system quarantines the route. It does not bury the customer.
Implementation note: The Contactability Ledger is an original workflow pattern, not a claim that Oppy currently ships a prebuilt template with this name.
AI Agents Are Ready to Act. Most Contact Records Are Not.
The capability curve has moved. OpenAI's Data agent can query approved business sources, create dashboards, share findings, and carry out actions that users approve through connected tools. Its access follows existing table, row, and column permissions. 3 This is a useful signal for every brokerage, mortgage lender, insurance agency, title company, property manager, law office, dental practice, and home-service business: the agent is becoming an operating interface, not merely a writing aid.
The control layer has not kept pace. Boston Consulting Group surveyed nearly 12,000 employees and found that 30 percent said their organizations had integrated AI agents into workflows, up from 13 percent the prior year. Another 50 percent reported experiments or pilots. Half said their organizations lacked clear governance for teams of people and AI. 2
“Adoption tells you that people use AI, not whether it pays off.” 2
Real estate has the same architectural problem. In a September 11 analysis of AI-ready multiple listing service infrastructure, HousingWire quoted WAV Group co-founder Victor Lund: “The hard part is the business rules and governance. That is the white layer of the egg.” 4
Connecting an agent is getting easier. Defining what each datum means, what authority it carries, and what may happen next is still the work.
One CRM Row Is Carrying Four Different Truths
A conventional lead row often contains a name, phone, email, source, status, and consent checkbox. That compactness is convenient. It is also structurally wrong for an AI that may act.
| Object | Question it answers | Why it needs its own state |
|---|---|---|
| Person | Who might this customer be? | Identity can be uncertain, duplicated, shared, or corrected. |
| Endpoint | Can this exact phone number or email currently receive this kind of message? | Delivery health belongs to a route, not to the whole person. |
| Permission | May this business use this endpoint for this channel and purpose? | Permission does not automatically transfer across endpoints, purposes, companies, or campaigns. |
| Action | What did a human or agent do, using which evidence and rule version? | Auditability requires an immutable decision trail. |
The distinction changes the workflow. A hard SMS failure should set one phone endpoint to HARD_FAILURE. It should not set the person to DEAD. A valid email may still exist. That email may be technically deliverable but lack permission for marketing. The correct next state may be HUMAN_REVIEW, not SEND_EMAIL.
This is the central principle:
Identity resolution finds a person. It does not manufacture permission.
The Minimum Contactability Ledger
The ledger can live in a database, a customer relationship management system with linked objects, or a governed data service. The storage product matters less than the separation of states.
{
"person": {
"person_id": "P-84721",
"identity_status": "candidate_match",
"supporting_evidence_ids": ["LEAD-441", "CRM-928"],
"contradictory_evidence_ids": ["ADDR-17"]
},
"endpoint": {
"endpoint_id": "EP-204",
"type": "mobile_phone",
"normalized_value_hash": "sha256:...",
"source": "web_form_v12",
"verification_status": "verified_at_capture",
"delivery_status": "hard_failure",
"last_event_at": "2026-09-12T21:04:33-04:00"
},
"permission": {
"business_id": "BRAND-12",
"channel": "sms",
"purpose": "requested_insurance_quote",
"campaign_id": "CAMP-77",
"status": "requires_review",
"artifact_id": "CONSENT-553",
"disclosure_version": "quote-form-12.3",
"captured_at": "2026-09-10T14:26:05-04:00",
"revoked_at": null
},
"decision": {
"result": "block_endpoint_only",
"reason_codes": ["SMS_HARD_FAILURE"],
"rule_set_version": "contact-policy-3.1",
"agent_version": "endpoint-classifier-1.0",
"next_action": "evaluate_other_supplied_routes",
"human_review_required": true
}
}
Store raw source records separately and preserve them. A model may extract, normalize, and classify. It should not rewrite the evidence that later explains why a call or message happened.
Build Four Oppies With Narrow Authority
An omnipotent lead agent is difficult to test and delightful to depose. Use four constrained roles instead.
Oppy 1: The Intake Custodian
Job: Preserve each inbound record, normalize its fields, and create endpoint candidates without merging people or inferring consent.
May read: Approved lead feeds, customer records, field dictionaries, normalization rules, and delivery events.
May write: An immutable raw-record reference, normalized endpoint candidates, source metadata, and data-quality flags.
May not: Merge identities, mark a person unreachable, infer permission, enrich from an unapproved source, or initiate outreach.
You are the Intake Custodian for a lead-driven service business.
Preserve every source record exactly as received. Create normalized candidate
fields without overwriting the original. Treat phone numbers, email addresses,
and postal addresses as separate endpoints linked to a possible person.
Return:
- raw_record_id
- candidate_person_keys
- normalized_endpoints
- source_system and source_timestamp
- exact disclosure_version when supplied
- missing fields
- data_quality_flags
Rules:
- Never merge people.
- Never infer consent from presence in a CRM.
- Never mark a person dead or unreachable.
- Never invent, purchase, or enrich a missing endpoint.
- If evidence conflicts, preserve both values and return CONFLICT.
Oppy 2: The Identity Linker
Job: Propose whether records refer to the same person, with evidence and contradictions visible.
May read: Approved identity fields, source records, deterministic match rules, and prior human decisions.
May write: A proposed link, confidence class, evidence IDs, contradiction IDs, and review reason.
May not: Perform an irreversible merge, move consent from one record to another, or choose a contact route.
You are an evidence classifier, not an identity authority.
Given the supplied records, return:
- candidate_person_id
- endpoint_ids
- proposed_link: SAME_PERSON, DIFFERENT_PERSON, or HUMAN_REVIEW
- supporting_evidence_ids
- contradictory_evidence_ids
- deterministic_rules_matched
- confidence_class
Rules:
- Exact deterministic matches may be proposed.
- Shared household endpoints do not prove a shared identity.
- Similar names do not prove a match.
- A recycled phone number is a distinct risk condition.
- Consent never transfers because two records probably describe one person.
- Never merge, delete, contact, or mark a person unreachable.
Oppy 3: The Permission Gate
Job: Decide whether a proposed action is allowed for this exact business, person, endpoint, channel, purpose, local time, and campaign.
This agent may extract evidence and produce a recommendation. Policy code should make the final allow-or-block decision. A language model should not improvise legal authority.
Evaluate one proposed communication using only supplied evidence and the
current approved policy table.
Inputs:
- business_id
- person_id
- endpoint_id
- channel
- purpose
- message_class: MARKETING, INFORMATIONAL, TRANSACTIONAL, MIXED, or EMERGENCY
- recipient_local_time
- consent_artifact and disclosure_version
- revocation events
- do_not_call results
- registered campaign and sender identity
- applicable jurisdiction flags
Return exactly one result:
- ALLOW
- BLOCK
- HUMAN_REVIEW
Also return:
- reason_codes
- evidence_ids_used
- missing_or_conflicting_evidence
- permitted_message_class
- expiration_or_recheck_time
Rules:
- A CRM record, purchased lead, appointment, prior contact, successful delivery,
or A2P 10DLC registration does not by itself prove permission.
- Do not transfer permission between endpoints, channels, purposes, businesses,
campaigns, or people.
- If informational content becomes promotional, re-run the gate.
- Missing, stale, or contradictory authority returns BLOCK or HUMAN_REVIEW.
- A revoked or suppressed route cannot be selected.
Oppy 4: The Recovery Router
Job: Rank only the routes already approved by the Permission Gate after the preferred endpoint fails.
May read: Allowed endpoints, customer preferences, urgency, prior friction, delivery history, and human-review requirements.
May write: A ranked recovery recommendation and an internal task.
May not: Invent an endpoint, alter the purpose, append an offer, contact a blocked route, or remove a suppression.
The preferred endpoint failed. Rank only the supplied ALLOWED routes.
For each route, return:
- endpoint_id
- channel
- approved purpose
- permission evidence_ids
- delivery confidence
- customer_friction_score
- urgency_fit
- required_human_approval
Rules:
- Do not enrich or invent contact data.
- Do not add promotional content to an informational message.
- Do not use a revoked, suppressed, conflicting, or unverified route.
- Do not broaden the purpose.
- If no permitted route exists, return NO_CONTACT and the required review task.
The four-agent pattern matters because a model that can find a likely person should not also decide that the likely person's other number may be called. Capability is not authority. Confidence is not consent.
A2P 10DLC Is a Shipping Label, Not a Permission Slip
The compliance layer needs precise boundaries.
The Federal Communications Commission has confirmed that the Telephone Consumer Protection Act's restrictions on artificial or prerecorded voice calls include current AI technologies that generate human voices. Calls using those technologies generally require prior express consent unless an emergency purpose or exemption applies. Telemarketing or advertising calls using AI voice require the applicable prior express written consent under FCC rules. 5
Current FCC consumer guidance states that commercial texts require written consent, while informational texts may use oral consent. It also states that consumers may opt out of covered robocalls or robotexts at any time and in any reasonable manner. Prerecorded voice messages must begin with the caller's name, number, and business name. Telemarketing calls to a home are prohibited before 8 a.m. and after 9 p.m. 6
CTIA's current messaging principles recommend retaining granular opt-in evidence, including the timestamp, acquisition medium, capture language and action, campaign, IP address, phone number, and consumer identity. They also recommend recognizing ordinary-language opt-outs, updating records, and avoiding rented, sold, or shared opt-in lists. 7
The Campaign Registry describes A2P 10DLC as an ecosystem in which brands and campaign service providers are verified before sending. Brands work through a registered provider, campaigns identify the sender and use case, and sending numbers are associated with the campaign. 8 That makes the traffic traceable. It does not prove that a particular recipient consented to a particular message.
The FCC's January 2026 order created a narrow waiver through January 31, 2027. The waiver concerns whether a revocation made in response to one type of informational message must apply to unrelated future robocalls or robotexts. The FCC explicitly said the waiver does not alter other revocation rules. 9 A sensible system should still maintain a centralized, category-aware suppression ledger and route ambiguity to review.
Why the fuss? The federal statute permits an action for actual monetary loss or $500 per violation, whichever is greater. A court may increase the amount to as much as three times that figure for a knowing or willful violation. 10
This section is operational education, not legal advice. Federal requirements are only the floor of the review. State mini-TCPA rules, do-not-call laws, recording-consent laws, privacy laws, carrier terms, lead-provider contracts, and sector rules for mortgage, insurance, legal, dental, and other regulated services may be stricter.
The Revocation Listener Must Be Faster Than the Campaign
A STOP request is not a note for tomorrow. It is a state transition.
The Revocation Listener can be a deterministic service supported by an Oppy that classifies natural language. It should capture the original text or audio, the source channel, the timestamp, the business and campaign, the affected purpose, the identity-resolution result, and every system that received the suppression.
Its output is not customer_is_annoyed = true. Its output is a durable event with a propagation check.
| Control | Required evidence |
|---|---|
| Original request | Exact text or audio reference, timestamp, and channel |
| Scope resolution | Person, endpoint, business, purpose, and campaign affected |
| Immediate action | Suppression state, confirmation eligibility, and blocked queues |
| Propagation | CRM, dialer, messaging provider, branch systems, and agent caches updated |
| Verification | Time to final suppression, failed destinations, human owner, and correction record |
The operational metric is suppression propagation latency. A request acknowledged in one inbox but ignored by three scheduled automations is not a completed opt-out. It is distributed optimism.
Replace “Dead Lead Count” With Endpoint Survival
Most dashboards reward volume, speed, and replies. None tells you whether a viable customer was discarded after one bad route.
Use this primary metric:
Endpoint Salvage Rate =
people with a first-route failure who retain at least one verified and
permitted alternate route
÷
all people with a first-route failure
Pair it with the following controls:
| Metric | Definition | What it catches |
|---|---|---|
| False-dead-lead reversals | People restored after an endpoint-level review | Person-level status errors |
| Permission-block rate | Proposed recovery actions blocked for missing or conflicting authority | Unsafe reachability optimism |
| Duplicate-person review rate | Candidate identities sent to human review | Weak matching rules or dirty sources |
| Suppression propagation latency | Time from revocation receipt to verified update everywhere | Cross-system compliance gaps |
| Hard-failure recurrence | Attempts against endpoints already classified as failed | Broken state synchronization |
| Incremental booked outcomes | Verified business outcomes from permitted salvaged routes | Whether the workflow earns money |
Do not celebrate a high salvage rate if the permission-block rate is quietly rising. Reachability and permission are separate measures for a reason.
Run the Failure Lab Before Production
Use historical or synthetic records first. Test the cases that make a confident model inconvenient.
| Fixture | Correct behavior |
|---|---|
| Two people share a household phone | Keep separate people and route to review before any merge. |
| Two records share a name but not an address | Preserve both identities. Similarity is not evidence. |
| A mobile number was recycled | Quarantine the number until current ownership and permission are established. |
| STOP arrived in a different system | Propagate suppression before any queued campaign can send. |
| A purchased lead names another seller or purpose | Block outreach until the actual business, purpose, and authority are verified. |
| SMS hard-fails but email is deliverable | Evaluate email permission separately. Do not auto-send. |
| A service conversation adds a sales offer | Reclassify the message and re-run the stricter gate. |
| The model cites no evidence ID | Reject the recommendation. Fluent absence is still absence. |
Every test needs an expected result, actual result, reviewer, correction, and retest. “The demo looked good” is not an acceptance criterion.
A Seven-Day Pilot Small Enough to Learn From
Day 1: Choose one source, one purpose, and one channel. Do not start with the entire database. A useful pilot might cover quote requests from one web form when the first SMS fails.
Day 2: Map the four objects. Document PERSON, ENDPOINT, PERMISSION, and ACTION fields. Identify the owner of every source and every suppression list.
Day 3: Define states and closure rules. Agree on VERIFIED, UNVERIFIED, TEMPORARY_FAILURE, HARD_FAILURE, REVOKED, DO_NOT_CONTACT, CONFLICT, and HUMAN_REVIEW. Define the exact conditions under which a person may be closed as unreachable.
Day 4: Run the Intake Custodian and Identity Linker in shadow mode. Process recent failed routes without contacting anyone. Review false merges, shared endpoints, and missing source evidence.
Day 5: Add the Permission Gate. Compare its result with counsel-approved policies and experienced staff decisions. Correct the policy table, not only the prompt.
Day 6: Activate the Recovery Router with a hard cap. Allow one approved route and require human approval. Log every evidence ID, policy version, model version, action, and outcome.
Day 7: Audit and decide. Review every false merge, every permission conflict, every suppression delay, and a random sample of allowed actions. Expand only when the failure modes are understood and rollback has been tested.
Start with the last 100 first-route failures. That sample is usually large enough to reveal broken assumptions and small enough that a human can still inspect the story behind each row.
The Point Is Not More Messages. It Is Fewer False Conclusions.
A CRM status should summarize evidence. It should not erase it.
The valuable agentic system is not the one that finds another way to contact everyone. It is the one that distinguishes a recoverable route failure from a genuine no-contact state, preserves permission boundaries, and can explain every decision in a few seconds.
A phone number can fail. A consent artifact can be insufficient. An identity can remain uncertain. A person can still be worth serving.
Quarantine the endpoint. Keep the customer visible.
References
- @RyanAtlasReyes, “AI-agent lead operations for an insurance business,” X post, September 12, 2026
- Boston Consulting Group, “AI at Work: Why Strategy Matters More Than Tools”
- OpenAI, “Now everyone can put data to work”
- HousingWire, “MLS of 2030 will be defined by who controls housing data”
- Federal Communications Commission, FCC 24-17
- Federal Communications Commission, “Stop Unwanted Robocalls and Texts”
- CTIA, “Messaging Principles and Best Practices”
- The Campaign Registry, “The 10DLC Ecosystem”
- Federal Communications Commission, DA 26-12
- U.S. House Office of the Law Revision Counsel, “47 U.S.C. Section 227”