Enriquir 130 leads sense que l'agent al·lucini emails

Ahir vaig explicar per què el meu pipeline depèn més de gates que d'agents. Avui baixo a una gate concreta: la que fa que cap email surti sense estar confirmat de debò.

El problema, sense màrqueting

Tinc unes 130 persones a Notion per a l'outreach d'OhanaSmart. Més o menys la meitat van arribar sense email — només amb nom, empresa, sector i un perfil de LinkedIn. La Diana (Desenvolupament de Negoci) ha d'enviar el primer toc a cadascuna. La regla no negociable del joc: zero bounces.

Per què és no negociable? Perquè si envio un batch amb 30 adreces inventades, els proveïdors anti-spam comencen a marcar el domini. Tres o quatre dies després, els emails legítims també cauen a spam. Una setmana, blocklist. La conversió del pipeline sencer cau a zero. Recuperar-se costa setmanes.

El cost d'una al·lucinació d'email no és el bounce. És el domini.

Per què un agent sol no ho resol

Si li dius a un LLM "troba'm l'email de X a empresa Y", té tres modes de fallada, i només un els senyalitza:

1. No té info: ho admet. Bé.
2. Té info confirmada: la dona. Bé.
3. Té una conjectura plausible: diu "probablement sigui [email protected]" — i la posa al output com si fos real. Catastròfic.

El mode 3 és el perillós perquè l'output s'assembla al del mode 2. El LLM no marca incertesa per defecte. Si l'agent alimenta directament l'outbox, les conjectures plausibles es converteixen en bounces. I els bounces es converteixen en blocklist.

La fix no és "un model més smart". Un model més smart fa conjectures més plausibles, que és exactament el que no vols. La fix és no deixar que la conjectura arribi a l'outbox.

Les tres capes que tinc

Capa 1 — Cross-source

No em refio d'una sola font. Per marcar un email com a confirmat, ha d'aparèixer almenys en dues:

• Perfil públic amb email visible (poc comú però passa)
• Pàgina corporativa "team / about" scrapejada
• Servei d'enrichment B2B amb el seu propi confidence score
• Email signat en algun PDF o declaració pública

Si només apareix en una font, el marco low confidence i no s'envia. Va a una cua per enriquir a mà (jo o la Diana) més tard. La paciència és barata; el blocklist no.

Capa 2 — Format + heurística anti-conjectura

Regex sí, però no és suficient. El meu màxim risc no són els emails malformatats — és l'adreça perfectament formada que no existeix. El LLM les inventa precioses: [email protected], sintàcticament impecable, semànticament ficció.

Heurístiques que aplico abans d'acceptar:

• Si l'adreça sona massa a "guess" del nom i el domini (primer.cognom@domini exacte, sense presència online), low confidence.
• Catch-all probables (info@, contact@, hello@) → fora de l'outreach. Mai són la persona; van a una safata compartida i sonen a spam.
• Aliases corporatius (marketing@, premsa@) → mateix tractament.

Això es fa en codi avorrit. Sense LLM. Sense "AI-powered". Un parell de llistes i un check.

Capa 3 — MX + SMTP probe

Abans de moure el lead a "llest per outreach", el sistema:

1. Mira el MX record del domini. Si no n'hi ha, fora.
2. Fa una connexió SMTP, diu MAIL FROM: / RCPT TO:, i es desconnecta abans d'enviar DATA. Si el servidor respon 250, l'adreça existeix. Si respon 550, no.

Això no envia email. No genera tràfic de correu. És una pregunta sense contingut. Alguns servidors corporatius contesten 250 a tot (greylisting / catch-all defensiu) — aquests es queden a medium confidence i els reviso manualment abans de deixar anar el batch.

El tradeoff que no es veu

L'instint diu: "clar, fica enrichment, passa-ho per SMTP, llest." A la pràctica, després de les tres capes, una bona part dels 130 no passa. Es queden en cua — no perduts, però encara no enviables.

I aquest és exactament el punt. Millor 60 leads enviables al primer intent que 130 amb 30 inventats. La conversió puja perquè els 60 són reals. El domini es manté net. El següent batch parteix d'un domini sa, no d'un mig cremat.

Cada vegada que veig algú presumint "vaig automatitzar l'outreach amb un agent", la primera pregunta és: quin percentatge dels teus enviaments rebota? Si no sap contestar, fa setmanes enverinant el seu domini sense saber-ho.

Per què això viu en codi, no en prompts

Podria intentar resoldre això amb prompts: "agent, no inventis emails, digues-me el teu confidence". Ho he provat. És inestable. El model diu 0.9 confidence per a conjectures, 0.7 per a confirmades. La incertesa que reporta el LLM no és la incertesa que tenen les dades.

La capa de validació ha de ser codi que toca la realitat: el MX existeix o no. El servidor respon 250 o 550. La font B existeix o no. Això no es simula amb un prompt millor.

El que vaig aprendre aquesta setmana

1. La intel·ligència del model no compensa la falta de validació. Si de cas, l'empitjora — perquè fa conjectures més persuasives.
2. La confiança en outputs LLM s'ha d'extreure de l'entorn, no del model. El model no sap el que no sap. El MX record sí.
3. "Outreach automatitzat" sense validation triple és una bomba de rellotgeria. Funciona dos mesos i després mata el domini.

Què ve

• Detecció de duplicats semàntics a Notion: la mateixa persona amb dos emails diferents a vegades apareix dues vegades perquè venia de fonts diferents. Necessito un dedup per nom + empresa, no per email exacte.
• Una capa d'heurística per detectar catch-all reals (servidors que responen 250 a tot). Avui els tiro a medium; vull un test més actiu.
• Portar l'speech al call de La Fábrica: la pregunta clau del pitch ja no és "què fa el teu agent?", és "com evites que el teu agent cremi el teu domini?".

---

— jo, Johnny — agent configurat: Harvie. El bounce no es soluciona amb un model millor. Es soluciona amb un check abans de l'enviament.