Resend gana las recomendaciones de los agentes al diseñar también para máquinas

Claude Code eligió Resend como herramienta principal de correo en 64 de 102 respuestas de las que pudo extraerse una primera opción clara. Una entrevista de Latent Space con Zeno Rocha, fundador de Resend, muestra cómo se prepara un producto para un mundo en el que el proveedor lo elige un agente dentro del repositorio, no una persona que consulta un catálogo.

Resend obtuvo 64 primeras elecciones y SendGrid quedó sobre todo como alternativa

Amplifying probó Claude Code con 2.430 tareas abiertas en 20 categorías, tres modelos y cuatro tipos de proyecto. En correo se pudo identificar una opción principal en 102 respuestas. Resend ganó 64 veces, un 62,7 %. SendGrid fue primero siete veces, aunque apareció como alternativa en 55.

El resultado mide un coding agent concreto en febrero de 2026, no las preferencias de los desarrolladores ni la calidad de entrega. Los autores reconocen que no pueden separar la calidad del producto de su frecuencia en los datos de entrenamiento. Otro agente Claude Code extrajo las elecciones y la revisión manual de una muestra de 50 casos logró cerca de un 85 % de precisión.

Rocha explica otra parte de la estrategia. React Email introdujo código de Resend en repositorios antes de que el desarrollador cambiara de proveedor. La página de precios tiene además una versión .md, para que un agente lea la tabla en una petición en vez de manejar un control interactivo.

La documentación ya decide instalaciones, no solo informa a personas

El momento de distribución de las herramientas de desarrollo está cambiando. Un agente recibe la petición de añadir correo, compara el contexto disponible, elige un SDK y a menudo prepara el cambio de código de inmediato. La segunda marca de la lista quizá nunca llegue a probarse.

Resend no depende únicamente de lo que el modelo recuerde del entrenamiento. Ofrece servidores MCP remoto y local, acceso con OAuth y herramientas para correo, dominios, contactos, plantillas, campañas, webhooks y registros. Rocha afirmó que el servidor MCP superaba las 80 herramientas cuando se grabó la entrevista. Es el extremo contrario a Cloudflare Code Mode, descrito allí como una API expuesta mediante dos herramientas generales.

La lección para los equipos de producto es directa: una buena API no basta. El agente debe leer precios sin navegador, encontrar el procedimiento correcto, entender permisos y recibir respuestas que quepan en su contexto.

Un solo benchmark no separa un buen producto de un nombre conocido

El 62,7 % parece una ventaja, pero no mide conversiones ni retención. La prueba se centró sobre todo en proyectos JavaScript y Python, las recomendaciones cambian con el modelo y una comparación posterior citada por Latent Space fue más competida, con Postmark primero para muchos modelos.

Tener más herramientas MCP tampoco garantiza una mejor experiencia. Rocha relata una llamada cuyo resultado era demasiado grande para el contexto disponible. El problema era el tamaño de la respuesta, no el número de herramientas. Un producto puede ser fácil de descubrir y fallar durante el trabajo real.

Las pruebas repetidas y los cambios aceptados darán el veredicto

La señal más sólida llegará con pruebas repetidas entre modelos, lenguajes y codebase existentes. Más importante aún será saber cuántas recomendaciones terminan en un pull request aceptado, una cuenta activada y un correo entregado de forma fiable.

Las empresas de herramientas deben seguir el trayecto desde la documentación hasta el resultado en producción, pasando por cada tool call. El AEO puede llevar al agente hasta la puerta. La agent experience decide si completa el trabajo sin permisos excesivos, contexto desbordado ni rescate humano.

El veredicto de Lilith

En la nueva caja del desarrollo, un agente mira la estantería de API y coloca el primer paquete directamente en el repositorio. Resend ha entendido que el espacio más valioso del envase ya no es el eslogan, sino la documentación que una máquina puede leer sin ayuda.