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

Resposta curta: marketing agêntico é trabalho de marketing realizado por software que escolhe o seu próprio passo seguinte e depois o executa. É mais ou menos aí que o consenso termina. Recolhemos as onze páginas que apareceram para o termo e as suas variantes em 18 de agosto de 2026, e oito delas nunca mencionam o protocolo, tool calling ou function calling — que é a camada onde um agente deixa de ser uma janela de chat e passa a ser algo capaz de alterar a tua comunidade, a tua campanha ou os registos dos teus clientes. Por isso, este artigo define marketing agêntico pelas quatro coisas que um sistema tem de expor antes de um agente poder fazer qualquer trabalho de marketing, cita o Model Context Protocol sobre porque as etiquetas que esses sistemas publicam sobre si próprios não são de confiança, e avalia a própria superfície de agente da Zealy face à definição, incluindo a parte em que falhamos.

Divulgação: A Zealy publica esta página e a Zealy vende aquilo de que ela trata. A Zealy é uma plataforma de comunidades e quests. Duas das 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 integrado no produto. Os três aparecem abaixo. Tudo aqui sobre a própria superfície de agente da Zealy é informação em primeira mão: lida do repositório da Zealy, executada contra o próprio servidor da Zealy por nós, auditada por mais ninguém. Deves lê-la com o ceticismo que aplicarias a qualquer fornecedor a descrever o seu próprio produto.

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

O que é marketing agêntico?

O marketing agêntico é trabalho de marketing realizado por software que escolhe a sua própria ação seguinte em direção a um objetivo, em vez de seguir um fluxo de trabalho definido 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 as descobrir antes de agir, um limite de aprovação deliberado e um limite de confiança no que é devolvido.

Essa definição é nossa e é deliberadamente construída a partir da maquinaria, e não da ambição. Todas as definições publicadas que lemos descrevem o que o software tenta fazer. Nenhuma descreve o que tem de ser verdade na sua stack antes de o poder fazer. Eis as quatro partes, pela ordem em que um sistema tem de as satisfazer.

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 as suas ferramentas são o que designa por controladas pelo modelo: o modelo de linguagem descobre-as e invoca-as por si próprio, com base no contexto e no prompt do utilizador. Sem esta camada, tem um assistente de escrita. É um produto útil; não é este.
2. Descoberta antes da ação. O agente tem de conseguir perguntar o que existe e o que faz cada coisa, antes de se comprometer com algo. Uma integração codificada em que um humano já escolheu as três chamadas é automação com um modelo colado à cópia.
3. Um limite de aprovação que alguém escolheu de propósito. Cada ação ou para para uma pessoa ou não, e em algum lugar há uma regra que decide qual. A regra pode ser estrita ou flexível. O que não pode ser é não examinada.
4. Um limite de confiança sobre o que volta. Os resultados das ferramentas são dados escritos por outras pessoas: membros, clientes, formulários, páginas extraídas. Se uma string devolvida conseguir convencer o agente a fazer a sua próxima chamada de ferramenta, construiu um sistema que aceita instruções de quem preenche o seu campo de submissão de quests.

Daí decorrem duas consequências, e são a razão pela qual nos demos ao trabalho de escrever uma definição. Qualquer coisa que falte à primeira parte é um chatbot com melhor marketing. E qualquer coisa à qual falta a terceira parte não tomou uma decisão sobre autonomia — aconteceu-lhe uma. Um limite de aprovação que não escolheste não é uma posição de design, é um acidente que ainda não te 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 planeia e age por conta própria, e discordam sobre quanta intervenção humana pode permanecer. A Vlerick Business School permite intervenção mínima. A Braze descreve sistemas que percecionam, decidem e agem. A Young Urban Project e a Netcore colocam a linha na aprovação humana a cada passo. A Forrester separa os agentes da IA agêntica por completo.

Lê a coluna do meio antes da da direita. Quem define a categoria diz-te muito sobre onde colocam a linha.

Cada frase da coluna da direita foi comparada com o texto original da página associada, tal como obtido a 18 de agosto de 2026, em vez de ser lida a partir de um resultado de pesquisa. Seis páginas que se posicionam para este termo não puderam ser lidas de todo. A Salesforce, a IBM, a Gartner e a BCG devolveram 403 a todas as tentativas, e a McKinsey e a Adobe deram tempo limite esgotado. 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 considerámos dignas de manter.

Em relação à automação de marketing. A Treasure Data escreve que "O marketing agêntico é mais restrito do 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 é saber se o software age sem ti. A tua ferramenta de email já o faz. O teste é saber se a sequência de passos foi escolhida antecipadamente por uma pessoa.

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

Em relação a um assistente. A frase mais incisiva que alguém do conjunto escreveu pertence a Docket's Arjun Pillai: "Um assistente espera por um utilizador, ajuda numa tarefa e vive dentro de um fluxo de trabalho humano." A sua metade agente é "Um agente age em direção a um objetivo, toma decisões limitadas, desencadeia 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 a essa frase: os humanos "definem objetivos, regras de escalonamento, restrições de tópicos e limiares de aprovação. O agente opera dentro desses limites. Quando algo fica fora deles, escala." O escalonamento é a fronteira de aprovação da nossa definição, descrita do lado do agente.

Há uma divergência que vale a pena imprimir em vez de suavizar. A Forrester, numa página sobre casos de uso de agentes de IA com Craig Le Clair nomeado, separa os dois termos que todas as páginas de fornecedores acima tratam como intercambiáveis: os agentes de IA funcionam com "regras predefinidas", enquanto "a IA agêntica introduz uma autonomia e adaptabilidade mais amplas". Aviso justo sobre essa citação — é uma página de destino de um podcast, não uma nota de investigação publicada, e citamo-la como o enquadramento de uma empresa de análise e não como conclusões.

A camada que oito das onze definições omitem

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

As oito sem qualquer menção a essas expressões: braze.com, cdp.com, docket.io, forrester.com, netcore.ai, tofuhq.com, vlerick.com e youngurbanproject.com. Das três restantes, a hubspot.com menciona o Model Context Protocol mas não é uma página de definição. Optimove é a que ficou connosco: a expressão MCP aparece na 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 disponibiliza um servidor MCP, cujo próprio explicador de marketing agêntico nunca chega àquilo que disponibiliza. Isto é uma afirmação sobre onze páginas num dia, não sobre toda a categoria — mas verificou-se em todas as páginas que analisámos.

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

Duncan Lennox, da HubSpot, escreve: "Mas os agentes não clicam em dashboards nem navegam em interfaces; chamam APIs, leem resultados estruturados e agem." A mesma página enquadra o âmbito como "o que os agentes podem ler, escrever e sobre o que podem agir", que é a unidade correta. Não "consegue fazer marketing", mas que substantivos e que verbos.

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

Essa última cláusula é tudo. O marketing agêntico não é uma propriedade do modelo que escolheste. É uma propriedade da superfície que os teus fornecedores publicam. Se as ferramentas forem só de leitura, o teu agente relata. Se não houver ferramentas, o teu agente escreve textos. A questão da capacidade e a questão da aquisição são a mesma questão, e é por isso que as definições que saltam esta camada são tão agradáveis de ler e tão difíceis de aplicar. Se quiseres o panorama mais amplo dos canais em que um agente estaria a agir, o nosso pilar de marketing web3 cobre-os e quanto custam.

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

O Model Context Protocol responde à questão do que um agente te pode fazer dizendo-te para leres a lista de ferramentas do servidor, e depois diz aos clientes para não confiarem no que essa lista diz sobre si mesma. A nota que o afirma está no esquema e não na prosa, o que é parte da razão pela qual tão poucas pessoas a leram.

Eis a passagem, da ToolAnnotations interface na esquema da especificação na revisão 2026-07-28:

NOTA: todas as propriedades em ToolAnnotations são dicas. Não garantem uma descrição fiel do comportamento da ferramenta (incluindo propriedades descritivas como title).

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

Por motivos de confiança, segurança e proteção, os clientes DEVEM considerar as anotações das ferramentas como não fidedignas, a menos que provenham de servidores de confiança.

Pare um momento para absorver isto. A resposta do protocolo a «como sei o que esta coisa me pode fazer» é: leia a lista. A instrução imediatamente seguinte é: a lista é uma alegação da parte que está a avaliar. Os nomes e os esquemas das ferramentas são essenciais, porque o modelo chama-os e o servidor tem de os respeitar. As etiquetas de risco que lhes estão associadas são a própria descrição que o servidor faz do seu próprio comportamento.

Existem quatro dessas etiquetas — readOnlyHint, destructiveHint, idempotentHint e openWorldHint — e duas delas, destructiveHint e openWorldHint, assumem por omissão o valor true. Uma ferramenta sem etiqueta é, portanto, considerada destrutiva e considerada como tendo impacto no mundo exterior, 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, pelo que não pergunta. Separa a substituição da adição. O dano é um eixo diferente e o esquema não tem coluna para ele, pelo que uma chamada puramente aditiva pode ser a coisa mais consequente que um agente faz à sua stack e ainda assim ser etiquetada da forma segura por um servidor que atua de boa-fé. O que cada flag significa na prática, e como é uma listagem real depois de aplicar os valores por omissão, está no passo a passo ao lado.

Esta é também a versão honesta daquilo a que os profissionais de marketing continuam a chamar agent washing. A Young Urban Project nomeia-o com precisão: «A falha mais comum é o agent washing, pegar num produto de automação ou chatbot existente e rebrandá-lo como agêntico sem acrescentar a camada de planeamento ou de decisão por baixo», e acrescenta que «a demonstração está programada para esconder exatamente a lacuna que importa». Uma lista de ferramentas é muito mais difícil de programar do que uma demonstração. É também o único artefacto em toda esta categoria que um comprador pode verificar sem a cooperação do fornecedor, razão pela qual escrevemos um passo a passo separado sobre como enumerar as ferramentas de qualquer servidor MCP antes de se ligar a ele.

Onde fica o limite de aprovação e quem deve colocá-lo lá

O Model Context Protocol diz que deve haver sempre um humano no circuito com capacidade para negar invocações de ferramentas, e diz isso à aplicação cliente, como DEVE em vez de OBRIGATÓRIO. Nada no protocolo obriga o servidor a que se liga. Onde fica o seu limite de aprovação é uma escolha que alguém fez, e muitas vezes não foi você.

A frase exata:

Por motivos de confiança, segurança e proteção, DEVE haver sempre um humano no circuito com capacidade para negar invocações de ferramentas.

A mesma secção de segurança pede aos clientes que «Mostrem as entradas das ferramentas ao utilizador antes de chamar o servidor, para evitar exfiltração de dados maliciosa ou acidental» e que «Validem os resultados das ferramentas antes de os passar ao LLM». Ambos os pedidos se dirigem ao cliente: a coisa que corre do seu lado, o Claude ou ChatGPT ou harness interno que detém o modelo. Assim, numa leitura simples do protocolo, a segurança do seu marketing agêntico é responsabilidade do seu cliente, e o servidor a que se ligou não lhe deve nada além de uma lista de ferramentas honesta.

A categoria sabe isto e não tem bem a certeza do que fazer. Os guias dos fornecedores definem rotineiramente um agente pela ausência de uma pessoa e depois, mais abaixo na mesma página, dizem-lhe onde voltar a colocar a pessoa; desmontamos uma dessas páginas em pode um agente de IA realmente gerir a sua comunidade. Ambas as metades são sinceras. A definição é escrita para o mercado e a instrução é escrita para a implementação, e é na lacuna entre elas que se toma efetivamente cada decisão real sobre autonomia.

A versão que vale a pena defender não é «autonomia total» nem «aprovar tudo». É que o limite é uma definição por decisão, com um custo de ambos os 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 o passo de revisão humana existia no design publicado e um bug retirou-o do percurso. Escrevemos sobre o que isso significa para deixar um agente gerir uma comunidade em separado, porque merece mais do que uma cláusula.

Há também agora uma resposta medida para que chamadas merecem o controlo, e não é a que a intuição sugere. SABER: Small Actions, Big Errors — Safeguarding Mutating Steps in LLM Agents, de Alejandro Cuadron, Pengfei Yu, Yang Liu e Arpit Gupta, submetido a 26 de novembro de 2025, estuda onde a trajetória errada de um agente que usa ferramentas realmente lhe custa. Refere que «Em contraste, os desvios em ações não mutantes têm pouco ou nenhum efeito.» A frase imediatamente anterior dá o outro lado: cada desvio adicional numa ação mutante reduz a probabilidade de sucesso até 92% num dos seus dois domínios e até 96% no outro, para modelos de última geração. A falha concentra-se nas chamadas que alteram o estado.

A conclusão de design é pouco glamorosa e barata: restringir as escritas, deixar as leituras em paz e parar de tratar o "humano no circuito" como um único botão com uma única definição. O servidor da Zealy funciona assim, e devemos ser claros que não o derivámos deste artigo — o artigo chegou depois do design e concorda com ele, o que é mais fraco do que engenharia guiada por evidências e mais forte do 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 é uma boa razão para não citar pontuações mais antigas de benchmarks de agentes-ferramenta como se ainda descrevessem os modelos atuais. A outra razão para ter cuidado com um único número aqui é que a falha de um agente é em grande parte um problema de variância — a investigação multi-turno divide a degradação numa perda menor de aptidão e num grande aumento de falta de fiabilidade, o que é um problema de gestão diferente de um modelo simplesmente não ser suficientemente bom.

O mesmo padrão de "deixado ao implementador" repete-se uma camada abaixo, na quarta parte da nossa definição. Descarregámos sete páginas de especificação e segurança em 18 de agosto de 2026 e pesquisámo-las: o modelo de ameaças da especificação é um modelo de ameaças de autorização e transporte, cobrindo confused deputy, token passthrough, server-side request forgery e um servidor local comprometido, entre vários outros, enquanto o ataque à camada de modelo é deixado aos implementadores. Nas páginas que descarregámos, 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 comandos de shell e execução remota de código. Isto não é uma crítica a uma especificação de transporte, que tem o direito de delimitar o seu âmbito. É uma afirmação sobre qual metade do problema herdas no momento em que ligas algo, e sobre porque é que um limite de confiança nos dados devolvidos tem de ser explicitamente tarefa de alguém em vez de uma propriedade assumida do protocolo.

A Zealy falha a sua própria definição, e é aqui que

Pelas definições mais estritas deste artigo — "sem um humano a aprovar cada passo individual" do Young Urban Project e "sem exigir aprovação humana em cada passo" da Netcore — a Zealy não está a fazer marketing agêntico. Cada escrita através da superfície de agente da Zealy para para uma pessoa, e as escritas estão desligadas até um operador as ativar.

Preferimos dizê-lo do que perder a discussão mais tarde. Aqui está a avaliação completa face às 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á definida ao contrário para o rótulo. O servidor da Zealy coloca o portão de aprovação do 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 é suficientemente grande para valer uma auditoria — 72 ferramentas nomeadas na altura em que as contámos — mas o número não é o ponto. A definição é.

Também não podemos reivindicar consistência em todo o produto. A Zealy também disponibiliza um revisor de IA que fecha uma claim de quest sozinho, sem nenhuma pessoa nesse caminho: a mesma empresa, a definição oposta, numa decisão que afeta se um membro recebe. Ambas as escolhas são defensáveis; o que não podemos dizer honestamente é que existe uma única resposta à escala da empresa sobre quanta autonomia é apropriada.

Então tiremos o rótulo. O que a Zealy oferece na realidade é uma superfície legível por agentes com um passo de commit humano, que é um nome aborrecido para aquilo que a maioria das equipas devia querer primeiro. Se quiseres a mecânica de a ligar, a documentação de integração MCP é canónica e este artigo deliberadamente não a repete; se quiseres a superfície mais antiga e mais ampla por baixo, a documentação da API cobre-a. E se nunca usaste o produto, o que é a Zealy é o caminho mais curto.

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

Pede a lista de ferramentas. Um fornecedor que vende marketing agêntico ou te mostra as operações nomeadas a que um agente tem acesso, com as permissões associadas, ou não consegue. Tudo o resto, a linguagem de planeamento e a linguagem de busca de objetivos e a demonstração, é compatível com um chatbot ligado a um formulário, e o Young Urban Project tem um nome para isso.

Cinco perguntas, pela ordem que te dá mais informação pelo menor tempo de reunião:

1. "Que operações o agente tem, por nome?" Se a resposta for uma frase de capacidade em vez de uma lista, tens a tua resposta. Se for uma lista, lê-a à procura de verbos. Ler, escrever, eliminar, enviar, publicar, pagar.
2. "Quais delas podem agir sem mim?" Não "há um humano no circuito": essa pergunta recebe um sim de todos. Pergunta que chamadas específicas dispensam a pessoa, e quem escolheu essa divisão.
3. "O que acontece ao texto que um cliente escreveu quando o agente o lê?" Está a perguntar se os resultados das ferramentas são tratados como dados ou como potenciais instruções. Um fornecedor que já pensou nisto responde de imediato, porque é o modo de falha que mantém os seus engenheiros acordados.
4. "O que significam os vossos rótulos de risco?" Depois confirme a resposta com a especificação em vez do material de vendas, e pergunte quais são as predefinições — a maioria das pessoas adivinha-as ao contrário.
5. "O que é que não consegue fazer?" Uma lista de limites é o sinal de credibilidade mais barato possível e quase ninguém publica uma. A sua ausência não prova nada. A sua presença vale muito.

A última coisa a dizer é sobre sequenciamento, porque a decisão de compra aqui costuma estar fora de tempo. A maioria das equipas que avalia marketing agêntico ainda não escreveu 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 pertençam a um prestador de serviços, a um moderador ou a um modelo. Como delegar tarefas de comunidade percorre-o com pessoas, e a análise transfere-se quase sem alterações. Faça isso primeiro. O agente continuará lá, e saberá quais ferramentas quer realmente que ele tenha.