Resend: cómo diseña su API para agentes de IA

En 64 de 102 recomendaciones de API de email que un estudio de AEO logró extraer, Claude Code eligió a Resend en primer lugar. SendGrid quedó primero solo siete veces, aunque apareció como alternativa en 55. Esos números salieron de una conversación de 86 minutos entre el podcast Latent Space y Zeno Rocha, cofundador y CEO de Resend, publicada el 10 de noviembre de 2026, y lo que revelan no es una táctica de marketing: es una decisión de producto tomada años antes de que existieran los agentes.

Para un founder, la implicancia es incómoda y directa. Si un desarrollador le pide a su agente que implemente el envío de email y acepta el primer patch que recibe, la segunda opción de la lista casi nunca se prueba. El agente se convirtió en un canal de adquisición con efecto trinquete.

¿Por qué un agente de IA recomienda un proveedor de email y no otro?

La conversación separa dos disciplinas que suelen confundirse. AEO (answer engine optimization, la optimización para que un motor de respuestas cite tu producto) es una cosa; agent experience es otra: diseñar la herramienta para que el agente la use bien, no solo para que la mencione.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El primer estudio citado mide la mención. El segundo, más amplio, muestra un escenario mucho más disputado, con Postmark adelante para la mayoría de los modelos. Es decir: el ranking de recomendaciones se mueve. Lo que no se mueve es el código que el agente ya dejó escrito en el repositorio del cliente.

Ahí está el aprendizaje de negocio. Optimizar para aparecer en una lista es una apuesta táctica sobre un ranking que cambia. Optimizar para que el agente ejecute bien tu API es una apuesta sobre el costo de cambio del cliente, que es mucho más durable.

El wedge que empezó antes de que existieran los agentes

La ventaja de Resend con agentes no nació de un esfuerzo de AEO. Nació de un problema de documentación. Mientras construía la API de envío, el equipo recibía la misma queja: montar el template del email y hacerlo renderizar bien dolía. La respuesta fue React Email, una biblioteca para armar templates con componentes React.

El movimiento fino vino después: Resend documentó cómo enviar esos templates hasta por otros proveedores, incluido SendGrid. En la práctica, cuando un desarrollador cambiaba de proveedor, parte de su código ya venía de un proyecto de Resend.

Eso es distribución en el sentido más literal: el producto entra en el repositorio antes de convertirse en decisión de compra. Y un agente que barre repositorios y documentación encuentra ese rastro con total naturalidad. No hay pitch de ventas en ese recorrido, solo código que ya funciona.

¿Cómo se convierte una página de precios en una interfaz para agentes?

La página de precios de Resend, que según su propia web estructura la oferta en cuatro planes (Free, Pro, Scale y Enterprise), funciona con un slider: la persona arrastra hasta el volumen de envíos que necesita y lee el valor. Un agente no arrastra sliders.

Rocha cuenta que basta agregar .md a la URL de la página para que el agente reciba una tabla en texto plano que lee en una sola petición, en vez de intentar interpretar un componente interactivo renderizado en JavaScript.

Es un test que cualquier equipo de producto puede correr hoy sobre su propia web: abrir la tabla de precios, dársela a un modelo y preguntarle si puede responder la duda de un cliente solo con ese contenido. Si la respuesta depende de una interacción visual, el agente probablemente va a inventar un número. Y un precio inventado por un agente en una demo frente a un comprador es un problema comercial, no técnico.

80 herramientas o dos: ¿cómo se diseña un servidor MCP?

El servidor MCP de Resend (Model Context Protocol, el estándar que permite a un agente conectarse a herramientas externas) creció de unas 20 herramientas en el lanzamiento a más de 80 en el momento de la grabación. La lógica de Rocha es replicar en el chat lo que el usuario hace en el panel: enviar un email resuelve la demostración, pero invitar a un colega, revisar el consumo y gestionar la cobranza también pasan en el dashboard.

La apuesta opuesta es la de Cloudflare con Code Mode, que expone la API entera con solo dos herramientas, search() y execute(): el agente busca lo que necesita y ejecuta código contra la API en lugar de elegir entre decenas de funciones predefinidas. Según InfoQ, Code Mode se presentó en septiembre de 2025 y la compañía reportó que convertir un servidor MCP en una API tipada y hacer que los agentes escriban código contra ella redujo el uso de tokens en 81% frente al patrón tradicional de llamadas a herramientas; su propio servidor MCP expone toda la API de Cloudflare en dos herramientas y menos de 1.000 tokens.

Los trade-offs, en concreto:

Muchas herramientas específicas (Resend, 80+): mapea 1:1 con el panel, pero infla el contexto y la lista de opciones que el modelo debe sopesar.
Pocas herramientas genéricas (Code Mode): contexto más liviano, pero exige que el modelo escriba código correcto contra la API en vez de invocar una función lista.

La conversación no resuelve cuál gana, y ese es justamente el punto para quien está diseñando hoy: no existe un único diseño correcto de servidor MCP.

El hábito más barato del artículo: abrir los tool calls

Rocha describe una práctica que vale copiar: abrir las llamadas a herramientas colapsadas en las propias sesiones para ver qué hizo el agente realmente. En una de esas inspecciones descubrió que el resultado de una llamada era demasiado grande para caber en el contexto. Reducir la cantidad de herramientas no habría arreglado nada, porque el problema estaba en el tamaño de la respuesta, no en el número de opciones.

El experimento cuesta una tarde: tomar una llamada que el equipo ejecuta a diario, expandir el resultado completo y medir cuánto de eso el modelo usa antes de decidir cortar herramientas o recortar el payload. La mayoría de los equipos optimiza la lista de opciones cuando el cuello de botella está en el otro lado.

¿Qué pasa después del «enviar»? Entregabilidad y riesgo compartido

Hacer que el agente elija la API correcta resuelve la primera mitad. La segunda es llegar a la bandeja de entrada. Rocha usa el rastreo de clics como ejemplo: cuando el proveedor reescribe los links por un dominio de tracking compartido entre clientes, basta que un cliente use ese dominio para phishing para que lo bloqueen, y con eso cae la entregabilidad de todos los que comparten el dominio.

Por eso Resend introdujo dominios de tracking personalizados, que aíslan el riesgo de reputación por cliente. La empresa también mantiene un plan gratuito aun sabiendo que atrae spammers, una decisión que Rocha vincula a lo que la conversación denomina el compromiso de seguridad de US$3 millones de la compañía: moderar el abuso cuesta caro, pero cerrar la puerta de entrada gratuita también tiene costo en adopción.

¿Qué tan grande es la base y qué quedó sin responder?

En el momento de la grabación, Resend tenía 4,3 millones de usuarios y 120 mil clientes pagantes, según Rocha, que cuenta haber descubierto a Warner Bros. Discovery como cliente revisando dominios .com cortos en la base un sábado. La anécdota muestra el tamaño de la base, pero no reemplaza un dato de adopción específico de agentes: la conversación no dice qué porción de esas 120 mil cuentas pagas llegó por un flujo iniciado por un agente en lugar de una búsqueda tradicional.

Qué significa esto para tu startup

Si tu producto tiene API o estás por publicar un servidor MCP, el recorte práctico de esta conversación tiene poco que ver con AEO y mucho con ergonomía.

Publica una versión legible por máquina de tus páginas críticas. Precios, límites, cuotas y endpoints en texto plano o markdown accesible por URL. Un .md al final de la ruta es la implementación más barata que existe, y elimina la dependencia de un componente interactivo que el modelo no puede operar.
Corre la prueba del agente sobre tu pricing hoy. Pídele a un modelo que responda la duda de un cliente usando solo el contenido de esa página. Cada respuesta que improvise un número te marca exactamente dónde falta información estructurada.
Audita payloads antes que cantidad de herramientas. Revisa tus logs de tool calls y mide tokens devueltos contra tokens realmente usados por el modelo. El recorte suele estar en la respuesta, no en el catálogo de funciones.
Diseña herramientas que reflejen tareas, no endpoints. Enviar, invitar a un miembro del equipo y revisar el consumo son tareas distintas de un mismo panel; si el agente solo puede hacer una, va a improvisar las otras por fuera de tu producto.
Aísla el riesgo de reputación si compartes infraestructura. Un dominio de tracking o de envío compartido entre clientes convierte el abuso de uno en el problema de todos.

Ninguna de esas decisiones depende de aparecer en un estudio de ranking. Dependen de abrir el log, mirar qué hizo el agente y ajustar la superficie desde ahí.