Agente de IA por email: darle a un agente una casilla que funcione

El email es el canal para el que los agentes están mejor preparados y el que casi ninguno llega a tener.

Mejor preparados, porque el email es donde viven los mensajes difíciles. Nadie manda una orden de compra por WhatsApp. Solicitudes de cotización, facturas, confirmaciones de proveedores e hilos de soporte con seis respuestas y un PDF adjunto llegan todos por email, y cada uno es una tarea con suficiente contexto adentro como para que un agente haga el trabajo de verdad.

Casi ninguno llega a tenerlo, porque darle una casilla a un agente significa resolver deliverability, y deliverability es una disciplina con su propia década de dolor acumulado.

Esto cubre lo que hace falta.

Qué necesita de verdad un agente con casilla

Cinco cosas, y solo una es el modelo:

Si te falta el primero no llega nada. Si te falta el último deja de llegar todo, tres semanas después, de golpe.

Configurar el dominio

La autenticación de email son tres registros con tres trabajos. DKIM firma tu correo para que el receptor pueda verificar que salió de ti. SPF dice qué servidores pueden enviar como tu dominio. DMARC le dice al receptor qué hacer cuando los dos primeros no coinciden.

terminal
npx zavudev email-domains add example.com

Eso devuelve los registros a publicar. DKIM es obligatorio para poder enviar. SPF, DMARC y un MAIL FROM propio aparecen como recomendados, lo cual se queda corto: son lo que separa la bandeja de entrada de la pestaña de promociones.

Publícalos en tu proveedor de DNS, y después:

terminal
npx zavudev email-domains verify example.com

Dos notas prácticas. La verificación revisa lo que el proveedor tiene en caché, así que registros correctos pueden seguir apareciendo como pendientes un rato; volver a correr verify no fuerza un re-scan. Y usa un subdominio que puedas permitirte quemar, tipo agent.example.com, en vez de tu dominio corporativo principal. Si el agente se equivoca feo con volumen, el daño queda contenido en un dominio que puedes retirar.

Recibir correo

Enviar es la mitad fácil. Un agente necesita respuestas, y eso significa un registro MX y receiving habilitado en el sender.

La configuración que más importa para agentes es el catch-all. Con eso activo, el sender recibe correo dirigido a cualquier local part de ese dominio, no solo a su propia dirección. O sea que orders@, quotes@, support@ y ticket-4471@ llegan todos al mismo agente, y el destinatario original viene en el data.to del webhook para que el agente sepa cuál se usó.

Esto es lo que hace posible el direccionamiento por hilo. Dale a cada conversación su propia dirección de respuesta y el threading se vuelve exacto en vez de una adivinanza basada en el asunto:

quote-8842@agent.example.com  ->  el hilo de cotización del deal 8842
ticket-4471@agent.example.com ->  el ticket de soporte 4471

Sin parsear Re: Re: Fwd:, sin hacer match por asunto, sin confusión cuando dos clientes abren hilos sobre el mismo producto el mismo día.

El agente

El email entrante llega como un evento message.inbound igual que cualquier otro canal, así que un agente que ya responde en WhatsApp responde en email sin código nuevo.

Cuando quieras comportamiento específico de email, lo describes en vez de escribirlo. Con las skills instaladas, el prompt es:

> Agrega manejo de email a este agente. Las direcciones de respuesta son quote-{dealId}@agent.example.com, así que saca el ID del deal desde el destinatario. Descarga los adjuntos y pásalos a answerQuotation. Responde en el mismo hilo con el PDF generado adjunto.

Lo que escribe:

TypeScript
import { defineFunction } from "@zavudev/functions"
import Zavudev from "@zavudev/sdk"

const zavu = new Zavudev({ apiKey: process.env.ZAVU_API_KEY })

export default defineFunction({
  on: ["message.inbound"],
  handler: async (event, ctx) => {
    if (event.data.channel !== "email") return

    const dealId = event.data.to.match(/quote-(\d+)@/)?.[1]

    // Listar adjuntos es solo REST: Stainless todavía no lo generó en el SDK,
    // así que llama al endpoint directo en vez de a un método que no existe.
    const res = await fetch(
      https://api.zavu.dev/v1/messages/${event.data.messageId}/attachments,
      { headers: { Authorization: Bearer ${process.env.ZAVU_API_KEY} } },
    )
    const { items } = await res.json()

    const reply = await answerQuotation({
      dealId,
      body: event.data.text,
      files: items.map((a: { downloadUrl: string }) => a.downloadUrl),
    })

    await zavu.messages.send({
      to: event.data.from,
      channel: "email",
      subject: Re: cotización ${dealId},
      text: reply.text,
      htmlBody: reply.html,
      attachments: [{ filename: "quote.pdf", content: reply.pdfBase64 }],
    })
  },
})

Dos detalles ahí adentro son toda la razón por la que el email es distinto a cualquier otro canal.

Los adjuntos llegan como archivos guardados, no como bytes en el webhook. GET /v1/messages/{messageId}/attachments devuelve un downloadUrl firmado y de vida corta por archivo, generado fresco en cada request. Descárgalo pronto, no cachees la URL. Ahí es donde suele estar el pedido real: la especificación, la orden de compra, la foto del producto dañado. Ojo: hoy este endpoint es solo REST. El SDK de TypeScript cubre enviar adjuntos pero no listarlos, así que llámalo con fetch como arriba.

Enviar adjuntos acepta base64 o una URL. O content con los bytes en base64, o path con una URL que el servidor descarga, hasta 40MB en total. Y content_id te deja incrustar una imagen inline, referenciada desde el HTML como cid:tu_content_id, que es la forma en que un agente manda un gráfico en vez de describirlo.

Las fallas que solo pasan en email

El loop de reply-all. Tu agente responde a una dirección que a su vez es un autorespondedor. Responde. Tu agente responde. Para la mañana tienes cuatro mil mensajes y un problema de reputación de dominio. Nunca respondas a una dirección que ya fue respondida en los últimos minutos, y nunca a noreply@ ni a mailer-daemon@.

Responder la pregunta equivocada. Los hilos de email cargan historia, y el mensaje más nuevo suele ser "dale, adelante" con el pedido real cuatro respuestas más arriba. Dale al agente el hilo, no el último mensaje. El direccionamiento por hilo de arriba es lo que hace confiable recuperar el hilo correcto.

Deliverability que se apaga de a poco. Nada falla de forma visible. Las tasas de apertura simplemente bajan, después dejan de llegar respuestas, y para cuando alguien investiga el dominio lleva un mes en la carpeta de spam. Los controles que importan: enviar solo a direcciones que lo pidieron, honrar las bajas de inmediato, y validar listas antes de envíos grandes.

terminal
curl -X POST https://api.zavu.dev/v1/introspect/email \
  -H "Authorization: Bearer $ZAVUDEV_API_KEY" \
  -d '{"emails": ["maria@example.com", "info@deaddomain.example"]}'

Eso devuelve deliverable, risky o undeliverable por dirección, con el motivo: sintaxis inválida, un dominio sin registros MX, una casilla desechable, una dirección de rol, o una dirección que ya está en tu lista de supresión por un rebote anterior. Descarta las undeliverable antes de enviar, y una tasa de rebote que habría tumbado tu dominio se queda plana.

En los envíos individuales, las direcciones que serían un rebote duro garantizado se marcan como fallidas antes del despacho en vez de enviarse, con errorCode en EMAIL_INVALID_RECIPIENT, EMAIL_DOMAIN_NOT_FOUND o EMAIL_RECIPIENT_SUPPRESSED. Las señales de advertencia como direcciones de rol no bloquean el envío, y por eso vale la pena correr el chequeo por lote de arriba antes de cualquier cosa grande.

El agente que responde todo. Al email llegan campañas en frío, newsletters, facturas y clientes de verdad. Un agente que trata todo eso como una tarea que completar va a negociar felizmente con un bot de spam. Clasifica primero, actúa después.

Cuánto cuesta

El email en Zavu se cobra del balance prepago en bloques de 1.000: USD 0,40 por cada 1.000 emails transaccionales y USD 0,80 por cada 1.000 emails de marketing o broadcast. El bloque se cobra cuando tu conteo mensual cruza cada límite de 1.000. Los equipos en Free arrancan con USD 2 de crédito y tienen un tope de 3.000 emails al mes y 100 por día, que alcanza para construir y probar un agente y no alcanza para correr una campaña.

Para un agente que maneja unos cientos de conversaciones al mes, la línea de email es un error de redondeo al lado de los tokens del modelo. El costo que importa en este canal es un dominio quemado, y por eso el paso de validación vale más de lo que parece.

Cuándo el email es el canal equivocado

Si la respuesta es una línea y se necesita ahora, el email es el lugar equivocado. Nadie mira su casilla como mira WhatsApp, y una respuesta en dos horas que técnicamente es rápida se lee como lenta.

Si necesitas una decisión dentro de una conversación, usa un canal con turnos. Los hilos de email son asincrónicos por diseño, y un agente que necesita tres aclaraciones va a tardar tres días en conseguirlas.

Si quien recibe es un consumidor en LATAM, Brasil, India o el sudeste asiático, está en WhatsApp y tu email va a una pestaña que abre los martes.

El email gana en contexto largo, adjuntos, B2B y todo lo que necesita quedar registrado. Que es bastante, y es justo la parte en la que los agentes son mejores.

Para seguir leyendo

• Cómo crear un agente de IA: el loop y después deployado en un canal.
• Frameworks de agentes de IA comparados: dónde encaja el email en el stack.
• Ejemplos de newsletter: el lado marketing del mismo setup de dominio.
• Agentes de IA para WhatsApp, SMS y email: un agente, todos los canales.