Agentic Marketing nel 2026: le quattro cose che un sistema deve esporre

Risposta breve: l'agentic marketing è lavoro di marketing svolto da software che sceglie da solo il proprio passo successivo e poi lo compie. Più o meno qui finisce l'accordo. Il 18 agosto 2026 abbiamo recuperato le undici pagine restituite per il termine e le sue varianti, e otto di esse non menzionano affatto il protocollo, il tool calling o il function calling — cioè lo strato in cui un agente smette di essere una finestra di chat e inizia a essere qualcosa che può modificare la tua community, la tua campagna o i tuoi dati sui clienti. Questo post definisce quindi l'agentic marketing attraverso le quattro cose che un sistema deve esporre prima che un agente possa svolgere qualsiasi lavoro di marketing, cita il Model Context Protocol sul perché le etichette che tali sistemi pubblicano su se stessi non sono affidabili, e valuta la superficie agente di Zealy rispetto alla definizione, inclusa la parte in cui non la superiamo.

Informativa: Zealy pubblica questa pagina e Zealy vende ciò di cui parla. Zealy è una piattaforma di community e quest. Due delle sue funzionalità sono agenti nel senso definito da questo articolo: un server MCP che un'AI esterna può pilotare e un revisore AI integrato nel prodotto. Tutti e tre compaiono qui sotto. Tutto ciò che riguarda la superficie agente di Zealy è di prima parte: letto dal repository di Zealy, eseguito da noi sul server di Zealy, verificato da nessun altro. Dovresti leggerlo con lo stesso scetticismo che applicheresti a qualsiasi fornitore che descrive il proprio prodotto.

Ultima verifica: 18 agosto 2026.

Che cos'è il marketing agentico?

Il marketing agentico è il lavoro di marketing svolto da software che sceglie la propria azione successiva verso un obiettivo invece di seguire un flusso di lavoro disegnato da una persona. Un sistema è qualificabile solo quando espone quattro cose: strumenti con nome invece di una casella di chat, un modo per scoprirli prima di agire, un confine di approvazione deliberato e un confine di fiducia su ciò che ritorna.

Questa definizione è nostra ed è costruita deliberatamente dalla macchina anziché dall'ambizione. Ogni definizione pubblicata che abbiamo letto descrive ciò che il software cerca di fare. Nessuna descrive ciò che deve essere vero nel tuo stack prima che possa farlo. Ecco le quattro parti, nell'ordine in cui un sistema deve soddisfarle.

1. Strumenti con nome, non una casella di testo. Un agente ha bisogno di operazioni con nomi, argomenti e forme di ritorno, cose come create_campaign, list_members e send_message, perché un modello che può produrre solo prosa può produrre solo prosa. Il Model Context Protocol è il modo comune attuale per pubblicare un tale elenco, e i suoi strumenti sono ciò che chiama controllati dal modello: il modello linguistico li scopre e li invoca da solo, in base al contesto e al prompt dell'utente. Senza questo livello hai un assistente di scrittura. È un prodotto utile; non è questo.
2. Scoperta prima dell'azione. L'agente deve poter chiedere cosa esiste e cosa fa ciascuna cosa, prima di impegnarsi in qualcosa. Un'integrazione hardcoded in cui un umano ha già scelto le tre chiamate è automazione con un modello attaccato alla copia.
3. Un confine di approvazione scelto di proposito. Ogni azione o si ferma per una persona o no, e da qualche parte c'è una regola che decide quale. La regola può essere rigida o flessibile. Ciò che non può essere è non esaminata.
4. Un confine di fiducia su ciò che ritorna. I risultati degli strumenti sono dati scritti da altre persone: membri, clienti, moduli, pagine raschiate. Se una stringa restituita può convincere l'agente a fare la sua prossima chiamata allo strumento, hai costruito un sistema che accetta istruzioni da chiunque compili il tuo campo di invio della quest.

Ne derivano due conseguenze, ed è per questo che ci siamo presi la briga di scrivere una definizione. Qualsiasi cosa priva della prima parte è un chatbot con un marketing migliore. E qualsiasi cosa priva della terza parte non ha preso una decisione sull'autonomia: l'ha subita. Un confine di approvazione che non hai scelto non è una posizione di design, è un incidente che non ti è ancora costato nulla.

Le definizioni esistenti e dove ciascuna traccia la linea dell'autonomia

Le definizioni pubblicate concordano sul fatto che un agente pianifica e agisce in autonomia, ma divergono su quanto coinvolgimento umano possa rimanere. Vlerick Business School ammette un intervento minimo. Braze descrive sistemi che percepiscono, decidono e agiscono. Young Urban Project e Netcore pongono il limite all'approvazione umana a ogni passaggio. Forrester separa del tutto gli agenti dall'AI agentica.

Leggi la colonna centrale prima di quella di destra. Chi definisce la categoria dice molto su dove pone il limite.

Ogni stringa nella colonna di destra è stata confrontata con il testo grezzo della pagina collegata così come recuperata il 18 agosto 2026, anziché letta da un risultato di ricerca. Sei pagine che si posizionano per questo termine non è stato possibile leggerle affatto. Salesforce, IBM, Gartner e BCG hanno restituito 403 a ogni tentativo, mentre McKinsey e Adobe sono andate in timeout. Nessuna di esse è citata qui.

Tre delle pagine tracciano anche un confine utilizzabile rispetto a un termine vicino, e queste sono le uniche tre che abbiamo trovato degne di essere mantenute.

Rispetto al marketing automation. Treasure Data scrive che "il marketing agentico è più ristretto del marketing AI e distinto dal marketing automation", perché "il marketing automation esegue flussi di lavoro fissi, definiti dall'uomo". Il test non è se il software agisce senza di te. Il tuo strumento di email lo fa già. Il test è se la sequenza dei passaggi è stata scelta in anticipo da una persona.

Rispetto all'AI generativa. Optimove lo presenta come un contrasto tra due trigger: "L'AI generativa crea contenuti basati su prompt umani", mentre "l'AI agentica intraprende azioni autonome senza attendere i prompt". A forma di prompt contro a forma di obiettivo, che è una distinzione reale e raramente rispettata.

Rispetto a un assistente. La frase più incisiva scritta da chiunque nel set appartiene a Il Docket di Arjun Pillai: "Un assistente attende un utente, aiuta con un compito e vive dentro un flusso di lavoro umano." La sua metà agente è "Un agente agisce verso un obiettivo, prende decisioni delimitate, attiva flussi di lavoro e possiede parte dell'esecuzione sotto supervisione." Un passaggio separato sulla stessa pagina fornisce il meccanismo che manca a quella frase: gli umani "definiscono obiettivi, regole di escalation, vincoli di argomento e soglie di approvazione. L'agente opera entro quei confini. Quando qualcosa esce da essi, esegue l'escalation." L'escalation è il confine di approvazione della nostra definizione, descritto dal lato dell'agente.

Un disaccordo vale la pena stamparlo anziché appianarlo. Forrester, su una pagina sui casi d'uso degli agenti AI con Craig Le Clair citato, separa i due termini che ogni pagina di fornitore sopra tratta come intercambiabili: gli agenti AI funzionano su "regole predefinite", mentre "l'AI agentica introduce autonomia e adattabilità più ampie". Avvertenza onesta su quella citazione: è una pagina di atterraggio di un podcast, non una nota di ricerca pubblicata, e la citiamo come inquadramento di una società di analisi, non come risultati.

Lo strato che otto delle undici definizioni omettono

Delle undici pagine che abbiamo recuperato per questo termine il 18 agosto 2026, otto non menzionano mai il Model Context Protocol, il tool calling o il function calling. Quello strato è la differenza tra un modello che ti scrive un brief di campagna e un modello che può creare una quest, bannare un membro o indirizzare il tuo flusso di eventi altrove.

Gli otto senza alcuna menzione di nessuna di quelle stringhe: braze.com, cdp.com, docket.io, forrester.com, netcore.ai, tofuhq.com, vlerick.com e youngurbanproject.com. Dei tre rimanenti, hubspot.com menziona il Model Context Protocol ma non è una pagina definitoria. Optimove è quello che ci è rimasto impresso: la stringa MCP compare nella sua pagina solo nel menu di navigazione, come "The Optimove MCP", e mai nel corpo dell'articolo che spiega la categoria. Un fornitore che distribuisce un server MCP, la cui stessa spiegazione del marketing agentico non arriva mai a ciò che distribuisce. Questa è un'affermazione su undici pagine in un solo giorno, non sull'intera categoria — ma è valsa per ogni pagina che abbiamo controllato.

Due pagine del set nominano davvero il livello mancante, ed entrambe lo fanno bene.

Duncan Lennox di HubSpot scrive: "Ma gli agenti non cliccano sui dashboard né navigano le interfacce; chiamano le API, leggono output strutturati e agiscono." La stessa pagina inquadra l'ambito come "ciò che gli agenti possono leggere, scrivere e su cui possono agire", che è l'unità corretta. Non "può fare marketing", ma quali sostantivi e quali verbi.

Real Story Group, azienda di ricerca martech che vende valutazioni di fornitori, fornisce la frase che chiude il ragionamento. In un articolo su MCP datato 11 giugno 2025, il Principal Analyst Scott Simmons lo definisce "un livello di astrazione API universale costruito per gli agenti AI", e trae la conclusione che un agente è "potente solo quanto ciò che il fornitore sceglie di esporre".

Quell'ultima frase è tutto. Il marketing agentico non è una proprietà del modello che hai scelto. È una proprietà della superficie che i tuoi fornitori pubblicano. Se gli strumenti sono in sola lettura, il tuo agente fa report. Se non ci sono strumenti, il tuo agente scrive testi. La questione delle capacità e la questione dell'approvvigionamento sono la stessa questione, ed è per questo che le definizioni che saltano questo livello sono così piacevoli da leggere e così difficili da mettere in pratica. Se vuoi il quadro più ampio dei canali su cui un agente opererebbe, il nostro pilastro del marketing web3 li copre e quanto costano.

Perché un elenco di strumenti è una prova e un'etichetta di strumento è solo un indizio

Il Model Context Protocol risponde alla domanda su cosa un agente può farti dicendoti di leggere l'elenco degli strumenti del server, e poi dice ai client di non fidarsi di ciò che quell'elenco afferma su se stesso. La nota che lo dice sta nello schema anziché nella prosa, ed è in parte per questo che così pochi l'hanno letta.

Ecco il passaggio, dal ToolAnnotations interfaccia nel schema della specifica alla revisione 2026-07-28:

NOTA: tutte le proprietà in ToolAnnotations sono suggerimenti. Non è garantito che forniscano una descrizione fedele del comportamento dello strumento (incluse proprietà descrittive come title).

E sullo stesso argomento, da pagina degli strumenti:

Per la fiducia, la sicurezza e la protezione, i client DEVONO considerare le annotazioni degli strumenti come non attendibili, a meno che non provengano da server attendibili.

Soffermati un attimo sulla forma di questa cosa. La risposta del protocollo a "come faccio a sapere cosa questa cosa può farmi" è: leggi la lista. La sua istruzione immediatamente successiva è: la lista è un'affermazione della parte che stai valutando. Lo strumento nomi e schemi sono portanti, perché il modello li richiama e il server deve rispettarli. Le etichette di rischio a essi associate sono la descrizione che il server dà del proprio comportamento.

Esistono quattro etichette di questo tipo — readOnlyHint, destructiveHint, idempotentHint e openWorldHint — e due di esse, destructiveHint e openWorldHint, per impostazione predefinita sono true. Uno strumento senza etichetta è quindi considerato distruttivo e si presume che tocchi il mondo esterno, il che è la scelta giusta e l'opposto di ciò che la maggior parte delle persone si aspetta.

Quello che conta per una definizione di marketing agentico è destructiveHint, per ciò che non chiede. Separa la sovrascrittura dall'aggiunta. Il danno è un asse diverso e lo schema non ha una colonna per esso, quindi una chiamata puramente additiva può essere la singola cosa più rilevante che un agente fa al tuo stack e comunque essere etichettata come sicura da un server che agisce in totale buona fede. Cosa significa ogni flag in pratica, e come appare un vero elenco una volta applicati i valori predefiniti, è la guida accanto.

Questa è anche la versione onesta di ciò che i marketer continuano a chiamare agent washing. Young Urban Project lo definisce con precisione: "Il fallimento più comune è l'agent washing, prendere un prodotto di automazione o chatbot esistente e riposizionarlo come agentico senza aggiungere il livello di pianificazione o decisione sottostante", e aggiunge che "la demo è sceneggiata per nascondere esattamente il divario che conta". Un elenco di strumenti è molto più difficile da sceneggiare rispetto a una demo. È anche l'unico artefatto in tutta questa categoria che un acquirente può verificare senza la collaborazione del fornitore, ed è per questo che abbiamo scritto una guida separata su come enumerare gli strumenti di qualsiasi server MCP prima di connetterlo.

Dove va il confine di approvazione, e chi dovrebbe metterlo lì

Il Model Context Protocol afferma che una persona dovrebbe sempre essere nel ciclo con la capacità di negare le invocazioni degli strumenti, e lo dice all'applicazione client, come SHOULD anziché MUST. Nulla nel protocollo obbliga il server a cui ti connetti. Dove si colloca il tuo confine di approvazione è una scelta fatta da qualcuno, e spesso non da te.

La frase esatta:

Per fiducia, sicurezza e protezione, lì SHOULD dovrebbe sempre esserci una persona nel ciclo con la capacità di negare le invocazioni degli strumenti.

La stessa sezione sulla sicurezza chiede ai client di "Mostrare gli input degli strumenti all'utente prima di chiamare il server, per evitare esfiltrazioni di dati malevole o accidentali" e di "Convalidare i risultati degli strumenti prima di passarli all'LLM". Entrambe sono rivolte al client: la cosa che gira dalla tua parte, il Claude o ChatGPT o harness interno che ospita il modello. Quindi, in una lettura semplice del protocollo, la sicurezza del tuo marketing agentico è compito del tuo client, e il server a cui ti sei connesso non ti deve nulla oltre a un elenco onesto degli strumenti.

La categoria lo sa e non è del tutto sicura di cosa fare al riguardo. Le guide dei fornitori definiscono abitualmente un agente per l'assenza di una persona e poi, più in basso nella stessa pagina, ti dicono dove rimettere la persona; ne smontiamo una di quelle pagine in un agente AI può davvero gestire la tua community. Entrambe le metà sono sincere. La definizione è scritta per il mercato e l'istruzione è scritta per il deployment, e il divario tra loro è dove ogni vera decisione sull'autonomia viene effettivamente presa.

La versione per cui vale la pena discutere non è né "piena autonomia" né "approva tutto". È che il confine è un'impostazione per singola decisione con un costo su entrambi i lati, e che il meccanismo che lo applica è esso stesso software che può fallire — come ha dimostrato il fallimento della moderazione di Discord all'inizio di quest'anno, dove il passaggio di revisione umana esisteva nel design pubblicato e un bug lo ha rimosso dal percorso. Abbiamo scritto su cosa significa questo per lasciare che un agente gestisca una community separatamente, perché merita più di una clausola.

C'è anche ora una risposta misurata a quali chiamate meritano il gate, e non è quella che suggerisce l'intuito. SABER: Small Actions, Big Errors — Safeguarding Mutating Steps in LLM Agents, di Alejandro Cuadron, Pengfei Yu, Yang Liu e Arpit Gupta e inviato il 26 novembre 2025, studia dove una traiettoria errata di un agente che usa strumenti ti costa davvero. Riporta che "Al contrario, le deviazioni nelle azioni non mutanti hanno poco o nessun effetto." La frase immediatamente precedente fornisce l'altro lato: ogni ulteriore deviazione in un' mutante azione riduce le probabilità di successo fino al 92% su uno dei suoi due domini e fino al 96% sull'altro, per i modelli all'avanguardia. Il fallimento si concentra nelle chiamate che cambiano lo stato.

La conclusione progettuale è poco affascinante ed economica: filtrare le scritture, lasciare in pace le letture e smettere di trattare "human in the loop" come un'unica manopola con un'unica impostazione. Il server di Zealy funziona così, e dobbiamo essere chiari sul fatto che non l'abbiamo derivato da questo articolo — l'articolo è arrivato dopo il design ed è d'accordo con esso, il che è una cosa più debole dell'ingegneria guidata dalle evidenze e più forte di niente. Una precisazione accompagna la citazione: SABER documenta errori di annotazione nel benchmark su cui si basa e ne pubblica una versione corretta, il che è un buon motivo per non citare i punteggi dei vecchi benchmark di tool-agent come se descrivessero ancora i modelli attuali. L'altro motivo per essere cauti con un singolo numero qui è che il fallimento degli agenti è in gran parte un problema di varianza — la la ricerca multi-turno suddivide il degrado in una lieve perdita di attitudine e un forte aumento dell'inaffidabilità, che è un problema di gestione diverso da un modello semplicemente non abbastanza buono.

Lo stesso schema "lasciato all'implementatore" si ripete un livello più in basso, nella quarta parte della nostra definizione. Il 18 agosto 2026 abbiamo scaricato sette pagine di specifiche e sicurezza e le abbiamo cercate: il modello di minaccia della specifica è un modello di minaccia per autorizzazione e trasporto, che copre confused deputy, token passthrough, server-side request forgery e un server locale compromesso tra gli altri, mentre l'attacco a livello di modello è lasciato agli implementatori. Nelle pagine che abbiamo scaricato, la frase "prompt injection" non compare; le quattro occorrenze di "injection" nel documento sulle best practice di sicurezza sono cross-site scripting, shell command injection e remote code execution. Non è una critica a una specifica di trasporto, che ha il diritto di delimitare il proprio ambito. È un'affermazione su quale metà del problema erediti nel momento in cui colleghi qualcosa, e sul perché un confine di fiducia sui dati restituiti debba essere un compito esplicito di qualcuno anziché una proprietà presunta del protocollo.

Zealy non rispetta la propria definizione, ed è qui che

Secondo le definizioni più rigorose di questo articolo — "senza un umano che approvi ogni singolo passaggio" di Young Urban Project e "senza richiedere approvazione umana a ogni passaggio" di Netcore — Zealy non fa marketing agentico. Ogni scrittura attraverso la superficie agentica di Zealy si ferma per una persona, e le scritture sono disattivate finché un operatore non le attiva.

Preferiamo dirlo che perdere la discussione più tardi. Ecco il punteggio completo rispetto alle nostre quattro parti, di prima mano e non verificato.

Tutti e quattro sono presenti, che è la parte facile. Il terzo è impostato nel verso sbagliato rispetto all'etichetta. Il server di Zealy pone il gate di approvazione lato server, il che è più di quanto il protocollo richieda a un server e più di quanto consenta una definizione rigorosa di marketing agentico. La superficie degli strumenti è di per sé abbastanza ampia da meritare un audit — 72 strumenti denominati al momento del conteggio — ma il numero non è il punto. La questione è l'impostazione.

Non possiamo nemmeno rivendicare coerenza su tutto il prodotto. Zealy offre anche un revisore AI che chiude da solo la richiesta di una quest, senza alcuna persona in quel percorso: la stessa azienda, l'impostazione opposta, su una decisione che incide sul fatto che un membro venga pagato. Entrambe le scelte sono difendibili; ciò che non possiamo dire onestamente è che esista una risposta unica a livello aziendale su quanta autonomia sia appropriata.

Quindi togliamo l'etichetta. Ciò che Zealy offre davvero è una superficie leggibile dagli agenti con un passaggio di conferma umana, che è un nome noioso per la cosa che la maggior parte dei team dovrebbe volere per prima. Se vuoi i meccanismi per collegarla, la documentazione sull'integrazione MCP è canonica e questo post deliberatamente non la ripete; se vuoi la superficie più vecchia e ampia sottostante, la documentazione API la copre. E se non hai mai usato il prodotto, cos'è Zealy è la rotta più breve in.

Cosa chiedere prima di acquistare qualcosa chiamato agentic marketing

Chiedi l'elenco degli strumenti. Un fornitore che vende agentic marketing può mostrarti le operazioni con nome a cui ha accesso un agente, con le relative autorizzazioni, oppure no. Tutto il resto, il linguaggio di pianificazione, il linguaggio orientato agli obiettivi e la demo, è compatibile con un chatbot collegato a un modulo, e Young Urban Project ha un nome per questo.

Cinque domande, nell'ordine che ti dà più informazioni con il minor tempo di riunione:

1. "Quali operazioni ottiene l'agente, per nome?" Se la risposta è una frase sulle capacità invece di un elenco, hai la tua risposta. Se è un elenco, leggilo cercando i verbi. Leggere, scrivere, eliminare, inviare, pubblicare, pagare.
2. "Quali di esse possono agire senza di me?" Non "c'è un umano nel processo": a quella domanda tutti rispondono sì. Chiedi quali chiamate specifiche saltano la persona, e chi ha scelto questa suddivisione.
3. Cosa succede al testo scritto da un cliente quando l'agente lo legge? Stai chiedendo se i risultati degli strumenti vengono trattati come dati o come potenziali istruzioni. Un fornitore che ci ha riflettuto risponderà subito, perché è il tipo di errore che tiene svegli i suoi ingegneri.
4. "Cosa significano le vostre etichette di rischio?" Poi verifica la risposta rispetto alla specifica anziché alla presentazione commerciale, e chiedi quali sono i valori predefiniti: la maggior parte delle persone li indovina al contrario.
5. "Cosa non può fare?" Un elenco dei limiti è il segnale di credibilità più economico possibile e quasi nessuno lo pubblica. La sua assenza non è prova di nulla. La sua presenza vale molto.

L'ultima cosa da dire riguarda l'ordine delle operazioni, perché qui la decisione di acquisto è di solito fuori tempo. La maggior parte dei team che valutano il marketing agentico non ha ancora messo per iscritto quali dei propri compiti ricorrenti sono sicuri da delegare e quali no, e questa decisione è la stessa sia che le mani appartengano a un collaboratore esterno, a un moderatore o a un modello. Come delegare i compiti della community lo affronta con le persone, e l'analisi si trasferisce quasi invariata. Fallo prima. L'agente sarà ancora lì, e saprai quali strumenti vuoi davvero che abbia.