Marketing agêntico em 2026: as quatro coisas que um sistema precisa expor

Resposta curta: marketing agêntico é trabalho de marketing realizado por software que escolhe seu próprio próximo passo e então o executa. É mais ou menos aí que o consenso termina. Buscamos as onze páginas que retornaram para o termo e suas variantes em 18 de agosto de 2026, e oito delas nunca mencionam o protocolo, chamada de ferramentas ou chamada de funções — que é a camada em que um agente deixa de ser uma janela de chat e passa a ser algo capaz de mudar sua comunidade, sua campanha ou seus registros de clientes. Então este post define marketing agêntico pelas quatro coisas que um sistema precisa expor antes que um agente possa realizar qualquer trabalho de marketing, cita o Model Context Protocol sobre por que os rótulos que esses sistemas publicam sobre si mesmos não são confiáveis, e avalia a própria superfície de agentes do Zealy contra a definição, incluindo a parte em que falhamos.

Divulgação: o Zealy publica esta página e o Zealy vende o produto sobre o qual ela trata. O Zealy é uma plataforma de comunidade e quests. Duas de suas funcionalidades são agentes no sentido que este artigo define: um servidor MCP que uma IA externa pode operar, e um revisor de IA dentro do produto. Todos os três aparecem abaixo. Tudo aqui sobre a própria superfície de agentes do Zealy é de primeira mão: lido do repositório do Zealy, executado contra o próprio servidor do Zealy por nós, auditado por mais ninguém. Você deve lê-lo com o ceticismo que aplicaria a qualquer fornecedor descrevendo seu próprio produto.

Última verificação: 18 de agosto de 2026.

O que é marketing agêntico?

Marketing agêntico é trabalho de marketing realizado por software que escolhe sua própria próxima ação rumo a um objetivo em vez de seguir um fluxo de trabalho desenhado por uma pessoa. Um sistema só se qualifica quando expõe quatro coisas: ferramentas nomeadas em vez de uma caixa de chat, uma forma de descobri-las antes de agir, uma fronteira de aprovação deliberada e uma fronteira de confiança sobre o que retorna.

Essa definição é nossa, e é deliberadamente construída a partir da mecânica e não da ambição. Toda definição publicada que lemos descreve o que o software tenta fazer. Nenhuma delas descreve o que precisa ser verdade na sua stack antes que ele possa fazê-lo. Aqui estão as quatro partes, na ordem em que um sistema precisa satisfazê-las.

1. Ferramentas nomeadas, não uma caixa de texto. Um agente precisa de operações com nomes, argumentos e formatos de retorno, coisas como create_campaign, list_members e send_message, porque um modelo que só consegue produzir prosa só consegue produzir prosa. O Model Context Protocol é a forma comum atual de publicar essa lista, e suas ferramentas são o que ele chama de controladas pelo modelo: o modelo de linguagem as descobre e invoca por conta própria, com base no contexto e no prompt do usuário. Sem essa camada você tem um assistente de escrita. É um produto útil; não é este.
2. Descoberta antes da ação. O agente precisa poder perguntar o que existe e o que cada coisa faz, antes de se comprometer com qualquer coisa. Uma integração codificada em que um humano já escolheu as três chamadas é automação com um modelo anexado ao texto.
3. Uma fronteira de aprovação que alguém escolheu de propósito. Toda ação ou para para uma pessoa ou não para, e em algum lugar há uma regra decidindo qual. A regra pode ser rígida ou frouxa. O que ela não pode ser é não examinada.
4. Uma fronteira de confiança sobre o que retorna. Resultados de ferramentas são dados escritos por outras pessoas: membros, clientes, formulários, páginas raspadas. Se uma string retornada pode convencer o agente a fazer sua próxima chamada de ferramenta, você construiu um sistema que aceita instruções de quem preenche seu campo de envio de quest.

Duas consequências decorrem disso, e são o motivo de termos nos dado ao trabalho de escrever uma definição. Qualquer coisa que careça da primeira parte é um chatbot com marketing melhor. E qualquer coisa que careça da terceira parte não tomou uma decisão sobre autonomia — ela aconteceu com ele. Uma fronteira de aprovação que você não escolheu não é uma posição de design, é um acidente que ainda não lhe custou nada.

As definições que existem, e onde cada uma traça a linha da autonomia

As definições publicadas concordam que um agente planeja e age por conta própria, e discordam sobre quanta participação humana pode permanecer. A Vlerick Business School permite intervenção mínima. A Braze descreve sistemas que percebem, decidem e agem. Young Urban Project e Netcore colocam a linha na aprovação humana a cada passo. A Forrester separa agentes de IA agêntica por completo.

Leia a coluna do meio antes da da direita. Quem está definindo a categoria diz muito sobre onde eles colocam a linha.

Cada trecho da coluna da direita foi comparado com o texto bruto da página vinculada, conforme obtido em 18 de agosto de 2026, em vez de lido a partir de um resultado de busca. Seis páginas que se classificam para este termo não puderam ser lidas de forma alguma. Salesforce, IBM, Gartner e BCG retornaram 403 a todas as tentativas, e McKinsey e Adobe deram timeout. Nenhuma delas é citada aqui.

Três das páginas também traçam uma fronteira útil em relação a um termo vizinho, e estas são as únicas três que consideramos dignas de manter.

Em relação à automação de marketing. A Treasure Data escreve que "o marketing agêntico é mais restrito que o marketing com IA e distinto da automação de marketing", porque "a automação de marketing executa fluxos de trabalho fixos, definidos por humanos". O teste não é se o software age sem você. Sua ferramenta de e-mail já faz isso. O teste é se a sequência de etapas foi escolhida antecipadamente por uma pessoa.

Em relação à IA generativa. A Optimove apresenta como um contraste entre dois gatilhos: "A IA generativa cria conteúdo com base em prompts humanos", enquanto "a IA agêntica toma ações autônomas sem esperar por prompts". Em forma de prompt versus em forma de objetivo, o que é uma distinção real e raramente respeitada.

Em relação a um assistente. A frase mais afiada que alguém do conjunto escreveu pertence a Docket's Arjun Pillai: "Um assistente espera por um usuário, ajuda em uma tarefa e vive dentro de um fluxo de trabalho humano." Sua metade agente é "Um agente age em direção a um objetivo, toma decisões limitadas, dispara fluxos de trabalho e é responsável por parte da execução sob supervisão." Uma passagem separada na mesma página fornece o mecanismo que falta nessa frase: os humanos "definem objetivos, regras de escalonamento, restrições de tópico e limites de aprovação. O agente opera dentro desses limites. Quando algo fica fora deles, ele escala." O escalonamento é o limite de aprovação da nossa definição, descrito do ponto de vista do agente.

Uma divergência vale a pena ser impressa em vez de suavizada. A Forrester, em uma página sobre casos de uso de agentes de IA com Craig Le Clair nomeado nela, separa os dois termos que toda página de fornecedor acima trata como intercambiáveis: agentes de IA funcionam com "regras predefinidas", enquanto "a IA agêntica introduz autonomia e adaptabilidade mais amplas". Aviso justo sobre essa citação — é uma página de destino de podcast, não uma nota de pesquisa publicada, e a citamos como o enquadramento de uma empresa de análise, não como descobertas.

A camada que oito das onze definições deixam de fora

Das onze páginas que obtivemos para este termo em 18 de agosto de 2026, oito nunca mencionam o Model Context Protocol, chamada de ferramentas ou chamada de funções. Essa camada é a diferença entre um modelo que escreve um briefing de campanha para você e um modelo que pode criar uma quest, banir um membro ou apontar seu fluxo de eventos para outro lugar.

As oito sem menção a nenhum desses trechos: braze.com, cdp.com, docket.io, forrester.com, netcore.ai, tofuhq.com, vlerick.com e youngurbanproject.com. Das três restantes, hubspot.com menciona o Model Context Protocol, mas não é uma página definicional. Optimove é a que ficou conosco: o trecho MCP aparece em sua página apenas no menu de navegação, como "The Optimove MCP", e nunca no corpo do artigo que explica a categoria. Um fornecedor que entrega um servidor MCP, cujo próprio explicador de marketing agêntico nunca chega à coisa que ele entrega. Isso é uma afirmação sobre onze páginas em um dia, não sobre toda a categoria — mas valeu para todas as páginas que verificamos.

Duas páginas do conjunto nomeiam a camada ausente, e ambas o fazem bem.

Duncan Lennox, da HubSpot, escreve: "Mas os agentes não clicam em dashboards nem navegam por interfaces; eles chamam APIs, leem saídas estruturadas e tomam ações." A mesma página enquadra o escopo como "o que os agentes podem ler, escrever e sobre o que podem agir", que é a unidade correta. Não "ele consegue fazer marketing", mas quais substantivos e quais verbos.

A Real Story Group, uma empresa de pesquisa de martech que vende avaliações de fornecedores, fornece a frase que encerra o argumento. Em um artigo sobre MCP datado de 11 de junho de 2025, o analista principal Scott Simmons o chama de "uma camada de abstração de API universal criada para agentes de IA", e tira a conclusão de que um agente é "tão poderoso quanto o que o fornecedor escolhe expor".

Essa última cláusula é a questão inteira. O marketing agêntico não é uma propriedade do modelo que você escolheu. É uma propriedade da superfície que seus fornecedores publicam. Se as ferramentas são somente leitura, seu agente relata. Se não há ferramentas, seu agente escreve textos. A questão da capacidade e a questão da contratação são a mesma questão, e é por isso que as definições que pulam essa camada são tão agradáveis de ler e tão difíceis de aplicar. Se você quer o panorama mais amplo dos canais em que um agente estaria agindo, nosso pilar de marketing web3 cobre eles e quanto custam.

Por que uma lista de ferramentas é evidência e um rótulo de ferramenta é apenas uma dica

O Model Context Protocol responde à pergunta sobre o que um agente pode fazer com você dizendo para ler a lista de ferramentas do servidor e, em seguida, diz aos clientes para não confiar no que essa lista diz sobre si mesma. A nota que diz isso está no schema, não na prosa, o que é parte do motivo pelo qual tão poucas pessoas a leram.

Aqui está a passagem, da ToolAnnotations interface no schema da especificação na revisão 2026-07-28:

NOTA: todas as propriedades em ToolAnnotations são dicas. Elas não têm garantia de fornecer uma descrição fiel do comportamento da ferramenta (incluindo propriedades descritivas como title).

E sobre o mesmo assunto, da página de ferramentas:

Para confiança, segurança e proteção, os clientes DEVEM considerar as anotações de ferramentas como não confiáveis, a menos que venham de servidores confiáveis.

Pare para refletir sobre o formato disso por um instante. A resposta do protocolo para "como sei o que essa coisa pode fazer comigo" é: leia a lista. A instrução seguinte é: a lista é uma alegação da parte que você está avaliando. A ferramenta nomes e schemas são essenciais, porque o modelo os chama e o servidor precisa cumpri-los. Os rótulos de risco anexados a eles são a própria descrição do servidor sobre seu próprio comportamento.

Existem quatro desses rótulos — readOnlyHint, destructiveHint, idempotentHint e openWorldHint — e dois deles, destructiveHint e openWorldHintpadrão para trueUma ferramenta sem rótulo é, portanto, considerada destrutiva e presume-se que interage com o mundo externo, o que é a decisão correta e o oposto do que a maioria das pessoas espera.

A que importa para uma definição de marketing agêntico é destructiveHint, por causa do que ele não pergunta. Ele separa sobrescrever de adicionar. O dano é um eixo diferente e o esquema não tem coluna para ele, então uma chamada puramente aditiva pode ser a coisa mais consequente que um agente faz na sua stack e ainda assim ser rotulada como segura por um servidor agindo de total boa-fé. O que cada flag significa na prática, e como é uma listagem real depois de aplicar os padrões, está em o passo a passo ao lado.

Esta também é a versão honesta do que os profissionais de marketing continuam chamando de agent washing. O Young Urban Project nomeia isso com precisão: "A falha mais comum é o agent washing, pegar um produto de automação ou chatbot existente e rebatizá-lo como agêntico sem adicionar a camada de planejamento ou decisão por baixo", e acrescenta que "a demo é roteirizada para esconder exatamente a lacuna que importa". Uma lista de ferramentas é muito mais difícil de roteirizar do que uma demo. É também o único artefato em toda essa categoria que um comprador pode verificar sem a cooperação do fornecedor, e é por isso que escrevemos um passo a passo separado de como enumerar as ferramentas de qualquer servidor MCP antes de conectá-lo.

Onde fica a fronteira de aprovação e quem deve colocá-la lá

O Model Context Protocol diz que um humano deve sempre estar no circuito com a capacidade de negar invocações de ferramentas, e diz isso à aplicação cliente, como um SHOULD e não um MUST. Nada no protocolo obriga o servidor ao qual você se conecta. Onde fica o seu limite de aprovação é uma escolha que alguém fez, e muitas vezes não é você.

A frase exata:

Para confiança e segurança, há SHOULD sempre um humano no circuito com a capacidade de negar invocações de ferramentas.

A mesma seção de segurança pede que os clientes "Mostrem as entradas de ferramentas ao usuário antes de chamar o servidor, para evitar exfiltração de dados maliciosa ou acidental" e que "Validem os resultados das ferramentas antes de passá-los ao LLM". Ambas são dirigidas ao cliente: a coisa que roda do seu lado, o Claude ou ChatGPT ou harness interno que detém o modelo. Então, numa leitura simples do protocolo, a segurança do seu marketing agêntico é responsabilidade do seu cliente, e o servidor ao qual você se conectou não te deve nada além de uma lista honesta de ferramentas.

A categoria sabe disso e não tem muita certeza do que fazer a respeito. Guias de fornecedores rotineiramente definem um agente pela ausência de uma pessoa e então, mais abaixo na mesma página, dizem onde colocar a pessoa de volta; desmontamos uma dessas páginas em um agente de IA consegue realmente administrar sua comunidade. As duas metades são sinceras. A definição é escrita para o mercado e a instrução é escrita para a implantação, e é na lacuna entre elas que toda decisão real sobre autonomia de fato acontece.

A versão que vale a pena defender não é nem a "autonomia total" nem o "aprovar tudo". É que o limite é uma configuração por decisão, com um custo dos dois lados, e que o mecanismo que o aplica é, ele próprio, software que pode falhar — como demonstrou a falha de moderação do Discord no início deste ano, em que a etapa de revisão humana existia no design publicado e um bug a removeu do fluxo. Escrevemos sobre o que isso significa para deixar um agente administrar uma comunidade separadamente, porque merece mais do que uma cláusula.

Há também agora uma resposta medida para qual as chamadas merecem o gate, e não é o que a intuição sugere. SABER: Small Actions, Big Errors — Protegendo Etapas Mutáveis em Agentes LLMpor Alejandro Cuadron, Pengfei Yu, Yang Liu e Arpit Gupta e enviado em 26 de novembro de 2025, estuda onde a trajetória de um agente que usa ferramentas, quando dá errado, realmente custa caro. Ele relata que "Em contraste, desvios em ações não mutantes têm pouco ou nenhum efeito." A frase imediatamente anterior a essa apresenta o outro lado: cada desvio adicional em um mutando action reduz as chances de sucesso em até 92% em um de seus dois domínios e em até 96% no outro, para modelos de última geração. As falhas se concentram nas chamadas que alteram o estado.

A conclusão de design é sem glamour e barata: restrinja as escritas, deixe as leituras em paz e pare de tratar "humano no circuito" como um único botão com uma única configuração. O servidor do Zealy funciona assim por acaso, e devemos deixar claro que não derivamos isso deste artigo — o artigo chegou depois do design e concorda com ele, o que é algo mais fraco que engenharia guiada por evidências e mais forte que nada. Uma ressalva acompanha a citação: o SABER documenta erros de anotação no benchmark em que se baseia e publica uma versão corrigida, o que é um bom motivo para não citar pontuações antigas de benchmarks de agentes de ferramentas como se ainda descrevessem os modelos atuais. O outro motivo para ter cuidado com um único número aqui é que a falha de agentes é em grande parte um problema de variância — a pesquisa multi-turno divide a degradação em uma pequena perda de aptidão e um grande aumento de falta de confiabilidade, o que é um problema de gestão diferente de um modelo simplesmente não ser bom o suficiente.

O mesmo padrão de "deixado para o implementador" aparece uma camada abaixo, na quarta parte da nossa definição. Baixamos sete páginas de especificação e segurança em 18 de agosto de 2026 e as pesquisamos: o modelo de ameaças da especificação é um modelo de ameaças de autorização e transporte, cobrindo confused deputy, passthrough de token, server-side request forgery e um servidor local comprometido, entre vários outros, enquanto o ataque na camada de modelo é deixado para os implementadores. Nas páginas que baixamos, a expressão "prompt injection" não aparece; as quatro ocorrências de "injection" no documento de boas práticas de segurança são cross-site scripting, injeção de comando de shell e execução remota de código. Isso não é uma reclamação sobre uma especificação de transporte, que tem o direito de delimitar seu escopo. É uma afirmação sobre qual metade do problema você herda no momento em que conecta algo, e sobre por que uma fronteira de confiança nos dados retornados precisa ser tarefa explícita de alguém, e não uma propriedade presumida do protocolo.

O Zealy falha na sua própria definição, e é aqui que

Pelas definições mais estritas deste post — a do Young Urban Project, "sem um humano aprovando cada etapa individual", e a da Netcore, "sem exigir aprovação humana em cada etapa" — o Zealy não está fazendo marketing agêntico. Toda escrita pela superfície de agente do Zealy para para uma pessoa, e as escritas ficam desligadas até que um operador as ative.

Preferimos dizer isso do que perder a discussão depois. Aqui está a pontuação completa contra as nossas próprias quatro partes, em primeira mão e não auditada.

As quatro estão presentes, o que é a parte fácil. A terceira está configurada ao contrário para o rótulo. O servidor do Zealy coloca o portão de aprovação no lado do servidor, o que é mais do que o protocolo exige de um servidor e mais do que uma definição estrita de marketing agêntico permite. A superfície de ferramentas em si é grande o suficiente para valer uma auditoria — 72 ferramentas nomeadas na época em que as contamos — mas o número não é o ponto. A configuração é.

Também não podemos alegar consistência em todo o produto. O Zealy também oferece um revisor de IA que encerra uma claim de quest sozinho, sem nenhuma pessoa nesse caminho: a mesma empresa, a configuração oposta, em uma decisão que afeta se um membro recebe ou não. Ambas as escolhas são defensáveis; o que não podemos dizer honestamente é que existe uma única resposta em toda a empresa sobre quanta autonomia é apropriada.

Então tire o rótulo. O que o Zealy realmente oferece é uma superfície legível por agentes com uma etapa de commit humano, que é um nome sem graça para a coisa que a maioria das equipes deveria querer primeiro. Se você quer a mecânica de conectar isso, a documentação de integração MCP é canônica e este post deliberadamente não a repete; se você quer a superfície mais antiga e mais ampla por baixo, a documentação da API cobre isso. E se você nunca usou o produto, o que é o Zealy é o caminho mais curto.

O que perguntar antes de comprar algo chamado marketing agêntico

Peça a lista de ferramentas. Um fornecedor que vende marketing agêntico pode ou não mostrar as operações nomeadas que um agente recebe, com as permissões anexadas. Todo o resto — a linguagem de planejamento, a linguagem de busca de objetivos e a demo — é compatível com um chatbot ligado a um formulário, e o Young Urban Project tem um nome para isso.

Cinco perguntas, na ordem que rende mais informação pelo menor tempo de reunião:

1. "Quais operações o agente recebe, por nome?" Se a resposta for uma frase de capacidade em vez de uma lista, você já tem sua resposta. Se for uma lista, leia em busca de verbos. Ler, escrever, excluir, enviar, publicar, pagar.
2. "Quais delas podem agir sem mim?" Não "existe um humano no circuito": essa pergunta recebe um sim de todo mundo. Pergunte quais chamadas específicas pulam a pessoa, e quem escolheu essa divisão.
3. "O que acontece com o texto que um cliente escreveu quando o agente o lê?" Você está perguntando se os resultados de ferramentas são tratados como dados ou como possíveis instruções. Um fornecedor que já pensou nisso responderá imediatamente, porque esse é o modo de falha que tira o sono dos engenheiros dele.
4. "O que significam seus rótulos de risco?" Em seguida, confira a resposta com a especificação, e não com o material de vendas, e pergunte quais são os padrões — a maioria das pessoas os supõe ao contrário.
5. "O que ele não consegue fazer?" Uma lista de limites é o sinal de credibilidade mais barato possível e quase ninguém publica uma. A ausência dela não prova nada. A presença dela vale muito.

A última coisa a dizer é sobre sequenciamento, porque a decisão de compra aqui costuma ser mal cronometrada. A maioria das equipes que avalia marketing agêntico ainda não registrou quais das suas tarefas recorrentes são seguras para delegar e quais não são — e essa decisão é a mesma, quer as mãos sejam de um prestador de serviços, de um moderador ou de um modelo. Como delegar tarefas de comunidade aborda isso com pessoas, e a análise se transfere quase sem alterações. Faça isso primeiro. O agente ainda estará lá, e você saberá quais ferramentas realmente quer que ele tenha.