Marketing agéntico en 2026: las cuatro cosas que un sistema debe exponer

Respuesta corta: el marketing agéntico es trabajo de marketing realizado por software que elige su propio siguiente paso y luego lo ejecuta. Ahí termina más o menos el acuerdo. Consultamos las once páginas que aparecieron para el término y sus variantes el 18 de agosto de 2026, y ocho de ellas no mencionan en absoluto el protocolo, el uso de herramientas ni el uso de funciones, que es la capa donde un agente deja de ser una ventana de chat y empieza a ser algo que puede cambiar tu comunidad, tu campaña o tus registros de clientes. Así que este artículo define el marketing agéntico por las cuatro cosas que un sistema debe exponer antes de que un agente pueda hacer cualquier trabajo de marketing, cita el Model Context Protocol sobre por qué las etiquetas que esos sistemas publican sobre sí mismos no son de confianza, y evalúa la propia superficie de agentes de Zealy frente a la definición, incluida la parte en la que no la cumplimos.

Divulgación: Zealy publica esta página y Zealy vende aquello de lo que trata. Zealy es una plataforma de comunidad y misiones. Dos de sus funciones son agentes en el sentido que define este artículo: un servidor MCP que una IA externa puede controlar y un revisor de IA dentro del producto. Los tres aparecen a continuación. Todo lo que aquí se dice sobre la propia superficie de agentes de Zealy es de primera mano: leído del repositorio de Zealy, ejecutado contra el propio servidor de Zealy por nosotros, auditado por nadie más. Deberías leerlo con el escepticismo que aplicarías a cualquier proveedor que describe su propio producto.

Última verificación: 18 de agosto de 2026.

¿Qué es el marketing agéntico?

El marketing agéntico es trabajo de marketing realizado por software que elige su propia siguiente acción hacia un objetivo en lugar de seguir un flujo de trabajo que dibujó una persona. Un sistema solo cumple cuando expone cuatro cosas: herramientas con nombre en lugar de una caja de chat, una forma de descubrirlas antes de actuar, un límite de aprobación deliberado y un límite de confianza sobre lo que devuelve.

Esa definición es nuestra y está construida deliberadamente a partir de la maquinaria y no de la ambición. Todas las definiciones publicadas que leímos describen qué intenta hacer el software. Ninguna describe qué debe cumplirse en tu stack antes de que pueda hacerlo. Aquí están las cuatro partes, en el orden en que un sistema debe cumplirlas.

1. Herramientas con nombre, no una caja de texto. Un agente necesita operaciones con nombres, argumentos y formas de retorno, cosas como create_campaign, list_members y send_message, porque un modelo que solo puede producir prosa solo puede producir prosa. El Model Context Protocol es la forma común actual de publicar esa lista, y sus herramientas son lo que llama controladas por el modelo: el modelo de lenguaje las descubre y las invoca por sí mismo, según el contexto y el prompt del usuario. Sin esta capa tienes un asistente de escritura. Es un producto útil; no es este.
2. Descubrimiento antes de la acción. El agente debe poder preguntar qué existe y qué hace cada cosa antes de comprometerse a nada. Una integración codificada donde una persona ya eligió las tres llamadas es automatización con un modelo adjunto al texto.
3. Un límite de aprobación que alguien eligió a propósito. Toda acción o se detiene para que la revise una persona o no lo hace, y en algún lugar hay una regla que decide cuál. La regla puede ser estricta o laxa. Lo que no puede ser es no examinada.
4. Un límite de confianza sobre lo que devuelve. Los resultados de las herramientas son datos escritos por otras personas: miembros, clientes, formularios, páginas extraídas. Si una cadena devuelta puede convencer al agente de su siguiente llamada a herramienta, has construido un sistema que acepta instrucciones de quien sea que rellene tu campo de envío de misiones.

De ahí se derivan dos consecuencias, y son la razón por la que nos molestamos en escribir una definición. Cualquier cosa que carezca de la primera parte es un chatbot con mejor marketing. Y cualquier cosa que carezca de la tercera parte no ha tomado una decisión sobre la autonomía: le ha pasado una. Un límite de aprobación que no elegiste no es una postura de diseño, es un accidente que todavía no te ha costado nada.

Las definiciones que existen y dónde traza cada una la línea de la autonomía

Las definiciones publicadas coinciden en que un agente planifica y actúa por su cuenta, y discrepan sobre cuánta intervención humana puede quedar. Vlerick Business School permite una intervención mínima. Braze describe sistemas que perciben, deciden y actúan. Young Urban Project y Netcore sitúan la línea en la aprobación humana en cada paso. Forrester separa por completo los agentes de la IA agéntica.

Lee la columna central antes que la de la derecha. Quién define la categoría te dice mucho sobre dónde sitúa la línea.

Cada cadena de la columna derecha se comparó con el texto sin procesar de la página enlazada tal como se obtuvo el 18 de agosto de 2026, en lugar de leerse de un resultado de búsqueda. Seis páginas que posicionan para este término no se pudieron leer en absoluto. Salesforce, IBM, Gartner y BCG devolvieron 403 en todos los intentos, y McKinsey y Adobe agotaron el tiempo de espera. Ninguna de ellas se cita aquí.

Tres de las páginas también trazan un límite útil frente a un término vecino, y son las únicas tres que encontramos que merecía la pena conservar.

Frente a la automatización de marketing. Treasure Data escribe que "el marketing agéntico es más estrecho que el marketing con IA y distinto de la automatización de marketing", porque "la automatización de marketing ejecuta flujos de trabajo fijos definidos por humanos". La prueba no es si el software actúa sin ti. Tu herramienta de email ya lo hace. La prueba es si la secuencia de pasos la eligió una persona de antemano.

Frente a la IA generativa. Optimove lo plantea como un contraste entre dos desencadenantes: "La IA generativa crea contenido a partir de indicaciones humanas", mientras que "la IA agéntica actúa de forma autónoma sin esperar indicaciones". Con forma de indicación frente a con forma de objetivo, que es una distinción real y rara vez respetada.

Frente a un asistente. La frase más precisa que escribió alguien del conjunto pertenece a Docket's Arjun Pillai: "Un asistente espera a un usuario, ayuda con una tarea y vive dentro de un flujo de trabajo humano". Su mitad agente es "Un agente actúa hacia un objetivo, toma decisiones acotadas, activa flujos de trabajo y asume parte de la ejecución bajo supervisión". Un pasaje aparte en la misma página aporta el mecanismo que le falta a esa frase: los humanos "definen objetivos, reglas de escalado, restricciones temáticas y umbrales de aprobación. El agente opera dentro de esos límites. Cuando algo queda fuera de ellos, escala". El escalado es el límite de aprobación de nuestra definición, descrito desde el lado del agente.

Merece la pena publicar un desacuerdo en lugar de suavizarlo. Forrester, en una página sobre casos de uso de agentes de IA con Craig Le Clair mencionado en ella, separa los dos términos que todas las páginas de proveedores anteriores tratan como intercambiables: los agentes de IA funcionan con "reglas predefinidas", mientras que "la IA agéntica introduce una autonomía y adaptabilidad más amplias". Aviso justo sobre esa cita: es una página de aterrizaje de un pódcast, no una nota de investigación publicada, y la citamos como el enfoque de una firma de analistas, no como hallazgos.

La capa que ocho de las once definiciones omiten

De las once páginas que obtuvimos para este término el 18 de agosto de 2026, ocho nunca mencionan el Model Context Protocol, el tool calling ni el function calling. Esa capa es la diferencia entre un modelo que te escribe un brief de campaña y un modelo que puede crear una quest, expulsar a un miembro o redirigir tu flujo de eventos a otro sitio.

Las ocho que no mencionan ninguna de esas cadenas: braze.com, cdp.com, docket.io, forrester.com, netcore.ai, tofuhq.com, vlerick.com y youngurbanproject.com. De las tres restantes, hubspot.com menciona el Model Context Protocol pero no es una página definitoria. Optimove es la que se nos quedó grabada: la cadena MCP aparece en su página solo en el menú de navegación, como "The Optimove MCP", y nunca en el cuerpo del artículo que explica la categoría. Un proveedor que ofrece un servidor MCP, cuyo propio explicador del marketing agéntico nunca llega a lo que ofrece. Eso es una afirmación sobre once páginas en un día, no sobre toda la categoría, pero se cumplió en todas las páginas que revisamos.

Dos páginas del conjunto sí nombran la capa que falta, y ambas lo hacen bien.

Duncan Lennox, de HubSpot, escribe: "Pero los agentes no hacen clic en paneles ni navegan por interfaces; llaman a APIs, leen salidas estructuradas y actúan". La misma página enmarca el alcance como "lo que los agentes pueden leer, escribir y sobre lo que pueden actuar", que es la unidad correcta. No "¿puede hacer marketing?", sino qué sustantivos y qué verbos.

Real Story Group, una firma de investigación de martech que vende evaluaciones de proveedores, aporta la frase que zanja el debate. En un artículo sobre MCP fechado el 11 de junio de 2025, el analista principal Scott Simmons lo llama "una capa de abstracción de API universal creada para agentes de IA", y saca la conclusión de que un agente es "solo tan potente como lo que el proveedor decida exponer".

Esa última cláusula lo resume todo. El marketing agéntico no es una propiedad del modelo que elegiste. Es una propiedad de la superficie que publican tus proveedores. Si las herramientas son de solo lectura, tu agente informa. Si no hay herramientas, tu agente escribe textos. La cuestión de la capacidad y la cuestión de la compra son la misma cuestión, y por eso las definiciones que se saltan esta capa son tan agradables de leer y tan difíciles de aplicar. Si quieres una visión más amplia de los canales en los que actuaría un agente, nuestro pilar de marketing web3 los cubre y explica cuánto cuestan.

Por qué una lista de herramientas es evidencia y una etiqueta de herramienta solo es una pista

El Model Context Protocol responde a la pregunta de qué puede hacerte un agente diciéndote que leas la lista de herramientas del servidor, y luego dice a los clientes que no confíen en lo que esa lista dice de sí misma. La nota que lo indica está en el esquema y no en la prosa, y eso explica en parte por qué tan pocas personas la han leído.

Aquí está el pasaje, de la ToolAnnotations interfaz en el esquema de la especificación en la revisión 2026-07-28:

NOTA: todas las propiedades en ToolAnnotations son pistas. No se garantiza que proporcionen una descripción fiel del comportamiento de la herramienta (incluidas propiedades descriptivas como title).

Y sobre el mismo tema, desde el página de herramientas:

Para confianza, seguridad y protección, los clientes DEBE considera que las anotaciones de herramientas no son de confianza a menos que provengan de servidores de confianza.

Piensa un momento en la forma de eso. La respuesta del protocolo a "cómo sé qué puede hacerme esto" es: lee la lista. Su instrucción inmediatamente siguiente es: la lista es una afirmación de la parte que estás evaluando. La herramienta nombres y schemas son fundamentales, porque el modelo los invoca y el servidor debe respetarlos. Las etiquetas de riesgo asociadas son la propia descripción que hace el servidor de su comportamiento.

Hay cuatro etiquetas de este tipo: readOnlyHint, destructiveHint, idempotentHint and openWorldHint — y dos de ellos, destructiveHint y openWorldHintpredeterminado a true. Por lo tanto, se asume que una herramienta sin etiquetar es destructiva y que toca el mundo exterior, lo cual es la decisión correcta y lo contrario de lo que la mayoría de la gente espera.

La que importa para una definición de marketing agéntico es destructiveHint, por lo que no pregunta. Separa sobrescribir de añadir. El daño es un eje distinto y el esquema no tiene columna para ello, así que una llamada puramente aditiva puede ser lo más consecuente que un agente hace a tu stack y aun así ser etiquetada como segura por un servidor que actúa de buena fe. Lo que significa cada flag en la práctica, y cómo se ve un listado real una vez que aplicas los valores predeterminados, está en el recorrido de al lado.

Esta es también la versión honesta de lo que los marketers siguen llamando agent washing. Young Urban Project lo nombra con precisión: "El fallo más común es el agent washing, tomar un producto de automatización o chatbot existente y rebautizarlo como agéntico sin añadir la capa de planificación o decisión debajo", y añade que "la demo está guionizada para ocultar exactamente la brecha que importa". Una lista de herramientas es mucho más difícil de guionizar que una demo. También es el único artefacto de toda esta categoría que un comprador puede verificar sin la cooperación del proveedor, por lo que escribimos un recorrido aparte de cómo enumerar las herramientas de cualquier servidor MCP antes de conectarte a él.

Dónde va el límite de aprobación y quién se supone que debe ponerlo ahí

El Model Context Protocol dice que siempre debe haber una persona en el circuito con la capacidad de denegar invocaciones de herramientas, y se lo dice a la aplicación cliente como un SHOULD y no como un MUST. Nada en el protocolo obliga al servidor al que te conectas. Dónde se sitúa tu límite de aprobación es una decisión que tomó alguien, y a menudo no fuiste tú.

La frase exacta:

Por confianza, seguridad y protección, ahí SHOULD siempre debe haber una persona en el circuito con la capacidad de denegar invocaciones de herramientas.

La misma sección de seguridad pide a los clientes que "muestren las entradas de las herramientas al usuario antes de llamar al servidor, para evitar exfiltración de datos maliciosa o accidental" y que "validen los resultados de las herramientas antes de pasarlos al LLM". Ambas van dirigidas al cliente: lo que se ejecuta de tu lado, el arnés de Claude, ChatGPT o interno que contiene el modelo. Así que, en una lectura literal del protocolo, la seguridad de tu marketing agéntico es responsabilidad de tu cliente, y el servidor al que te conectaste no te debe nada más allá de una lista de herramientas honesta.

La categoría lo sabe y no tiene muy claro qué hacer al respecto. Las guías de proveedores suelen definir un agente por la ausencia de una persona y luego, más abajo en la misma página, te dicen dónde volver a poner a la persona; desmontamos una de esas páginas en ¿puede un agente de IA gestionar realmente tu comunidad. Ambas mitades son sinceras. La definición está escrita para el mercado y la instrucción está escrita para el despliegue, y la brecha entre ambas es donde realmente se toma cada decisión real sobre la autonomía.

La versión que vale la pena defender no es ni la "autonomía total" ni "aprobar todo". Es que el límite es una configuración por decisión con un costo en ambos lados, y que el mecanismo que lo aplica es en sí mismo software que puede fallar — como lo demostró el fallo de moderación de Discord a principios de este año, donde el paso de revisión humana existía en el diseño publicado y un error lo sacó del flujo. Escribimos sobre qué significa eso para permitir que un agente gestione una comunidad por separado, porque merece más que una cláusula.

Ahora también hay una respuesta medida a que las llamadas merecen la puerta, y no es la que te da la intuición. SABER: pequeñas acciones, grandes errores — protección de los pasos mutables en agentes LLMpor Alejandro Cuadron, Pengfei Yu, Yang Liu y Arpit Gupta y enviado el 26 de noviembre de 2025, estudia dónde una trayectoria incorrecta de un agente que usa herramientas realmente te cuesta. Informa que "En contraste, las desviaciones en acciones no mutantes tienen poco o ningún efecto". La frase inmediatamente anterior a esa da el otro lado: cada desviación adicional en un mutando action reduce las probabilidades de éxito hasta en un 92% en uno de sus dos dominios y hasta en un 96% en el otro, para modelos de última generación. Los fallos se concentran en las llamadas que cambian el estado.

La conclusión de diseño es poco glamurosa y barata: restringir las escrituras, dejar las lecturas en paz y dejar de tratar "humano en el bucle" como un único dial con un único ajuste. El servidor de Zealy resulta que funciona así, y debemos dejar claro que no lo derivamos de este artículo: el artículo llegó después del diseño y está de acuerdo con él, lo cual es algo más débil que la ingeniería guiada por evidencia y más fuerte que nada. Una advertencia acompaña a la cita: SABER documenta errores de anotación en el benchmark sobre el que se construye y publica una versión corregida, lo cual es una buena razón para no citar puntuaciones antiguas de benchmarks de agentes de herramientas como si todavía describieran los modelos actuales. La otra razón para ser cuidadoso con un único número aquí es que el fallo de los agentes es en gran medida un problema de varianza: la investigación multiturno divide la degradación en una pérdida menor de aptitud y un gran aumento de la falta de fiabilidad, lo cual es un problema de gestión distinto al de un modelo que simplemente no es lo suficientemente bueno.

El mismo patrón de "dejado al implementador" se repite una capa más abajo, en la cuarta parte de nuestra definición. Descargamos siete páginas de especificación y seguridad el 18 de agosto de 2026 y las buscamos: el modelo de amenazas de la especificación es un modelo de amenazas de autorización y transporte, que cubre el confused deputy, el token passthrough, la falsificación de solicitudes del lado del servidor y un servidor local comprometido, entre varios otros, mientras que el ataque a la capa del modelo se deja a los implementadores. En las páginas que descargamos, la frase "prompt injection" no aparece; las cuatro coincidencias de "injection" en el documento de buenas prácticas de seguridad son cross-site scripting, inyección de comandos de shell y ejecución remota de código. Eso no es una queja sobre una especificación de transporte, que tiene derecho a delimitar su alcance. Es una afirmación sobre qué mitad del problema heredas en el momento en que conectas algo, y sobre por qué un límite de confianza en los datos devueltos tiene que ser el trabajo explícito de alguien en lugar de una propiedad asumida del protocolo.

Zealy incumple su propia definición, y aquí es donde

Según las definiciones más estrictas de este artículo —la de Young Urban Project, "sin que un humano apruebe cada paso individual", y la de Netcore, "sin requerir aprobación humana en cada paso"—, Zealy no está haciendo marketing agéntico. Cada escritura a través de la superficie de agentes de Zealy se detiene ante una persona, y las escrituras están desactivadas hasta que un operador las activa.

Preferimos decir eso que perder la discusión más adelante. Aquí está la tarjeta de puntuación completa frente a nuestras propias cuatro partes, de primera mano y sin auditar.

Las cuatro están presentes, que es la parte fácil. La tercera está configurada al revés para la etiqueta. El servidor de Zealy pone la puerta de aprobación del lado del servidor, lo cual es más de lo que el protocolo exige a un servidor y más de lo que permite una definición estricta de marketing agéntico. La superficie de herramientas en sí es lo bastante grande como para merecer una auditoría — 72 herramientas con nombre en el momento en que las contamos —, pero el número no es lo importante. El ajuste sí lo es.

Tampoco podemos reclamar coherencia en todo el producto. Zealy también ofrece un revisor de IA que cierra una reclamación de quest por sí solo, sin ninguna persona en ese camino: la misma empresa, el ajuste opuesto, en una decisión que afecta a si un miembro cobra. Ambas elecciones son defendibles; lo que no podemos decir honestamente es que haya una única respuesta a nivel de empresa sobre cuánta autonomía es apropiada.

Así que quita la etiqueta. Lo que Zealy ofrece en realidad es una superficie legible para agentes con un paso de confirmación humana, que es un nombre aburrido para lo que la mayoría de los equipos debería querer primero. Si quieres la mecánica para conectarlo, la documentación de integración MCP es la canónica y este artículo deliberadamente no la repite; si quieres la superficie más antigua y amplia que hay debajo, la documentación de la API la cubre. Y si nunca has usado el producto, qué es Zealy es la ruta más corta para entrar.

Qué preguntar antes de comprar algo llamado marketing agéntico

Pide la lista de herramientas. Un proveedor que vende marketing agéntico puede mostrarte las operaciones con nombre a las que accede un agente, con los permisos adjuntos, o no puede. Todo lo demás —el lenguaje de planificación, el lenguaje de búsqueda de objetivos y la demo— es compatible con un chatbot conectado a un formulario, y Young Urban Project tiene un nombre para eso.

Cinco preguntas, en el orden que te da más información por el menor tiempo de reunión:

1. "¿A qué operaciones accede el agente, por nombre?" Si la respuesta es una frase de capacidades en lugar de una lista, ya tienes tu respuesta. Si es una lista, léela buscando verbos. Leer, escribir, eliminar, enviar, publicar, pagar.
2. "¿Cuáles de ellas pueden actuar sin mí?" No "¿hay un humano en el bucle?": esa pregunta recibe un sí de todos. Pregunta qué llamadas concretas omiten a la persona, y quién eligió esa división.
3. "¿Qué pasa con el texto que escribió un cliente cuando el agente lo lee?" Estás preguntando si los resultados de las herramientas se tratan como datos o como posibles instrucciones. Un proveedor que haya reflexionado sobre esto responderá de inmediato, porque es el modo de fallo que mantiene despiertos a sus ingenieros.
4. "¿Qué significan sus etiquetas de riesgo?" Luego contrasta la respuesta con la especificación en lugar de con la presentación comercial, y pregunta cuáles son los valores predeterminados: la mayoría los adivina al revés.
5. "¿Qué no puede hacer?" Una lista de límites es la señal de credibilidad más barata posible y casi nadie publica una. Su ausencia no prueba nada. Su presencia vale mucho.

Lo último que hay que decir es sobre la secuencia, porque la decisión de compra aquí suele llegar en mal momento. La mayoría de los equipos que evalúan marketing agéntico aún no han escrito cuáles de sus tareas recurrentes son seguras de delegar y cuáles no, y esa decisión es la misma tanto si las manos son de un contratista, de un moderador o de un modelo. Cómo delegar tareas de comunidad lo aborda con personas, y el análisis se traslada casi sin cambios. Hazlo primero. El agente seguirá ahí, y sabrás qué herramientas quieres que tenga realmente.