Marketing automation contro agenti AI: due lavori diversi

In breve. Nel mio disegno automazione e agenti fanno due lavori diversi: l'automazione apre richieste e non decide niente, l'agente compone l'applicazione e propone le azioni, l'umano decide. La tesi che ne ricavo, ed è interpretazione mia: il confine non è tra vecchio e nuovo, ma tra chi apre, chi propone e chi decide — e ogni sconfinamento è un controllo aggirato. Da Accordo, con le meccaniche che lo rendono vero. Pubblicato il 6 ottobre 2026.

Il timer che non decide niente

Il pezzo di automazione più istruttivo è il più piccolo: lo scheduled ask. Una persona scrive un'istruzione per aprire una richiesta di dominio a un istante futuro — un follow-up di lavoro o una revisione di rinnovo, solo questi due tipi. L'istruzione è un record visibile, non un payload opaco: si può leggere, cancellare e riprogrammare come qualsiasi altra cosa di proprietà di una persona.

All'istante, il timer fa deliberatamente quasi niente: marca il record come dovuto e presenta l'istruzione al punto di ingresso che il dominio già offre, con l'identità del consumatore scritta nel record. Non sceglie il consumatore, né il contenuto, né l'istante: tutti e tre sono coperti da un'impronta scritta quando una persona l'ha chiesto, e un record la cui provenienza o contenuto si è mossa viene rifiutato. Il timer non ha autorità propria: apre, non completa, non annulla, non assegna a nessuno.

La divisione è scritta nei documenti dei package: il dominio possiede il cosa, la spina possiede il quando, l'applicazione compone i due. Il package work non schedula niente, non ricorda niente a nessuno e non assegna a nessuno; lifecycle non cancella, non schedula, non prezza e non notifica niente. Sembrano divieti decorativi, e sono il contrario: ogni verbo negato è un lavoro che resta a qualcun altro, per disegno.

Le proposte che nessun provider tocca

Sul lato marketing la stessa divisione prende la forma delle proposte di campagna. Il package registra funnel osservati e proposte, con una policy versionata che dice quali sezioni una proposta deve dichiarare: pubblico, esclusioni, canale, motivazione del provider, piano contenuti, piano tracciamento, rischi, approvazioni richieste. Una proposta che non sa dire queste otto cose non è pronta per un umano, e il framework lo dice invece di mostrare un modulo mezzo vuoto.

Due dettagli contano. Il primo: l'approvazione è un confine da attore umano — ogni attore che non sia una persona viene rifiutato, e la completezza viene ricalcolata dal record salvato, mai fidandosi del piano calcolato prima dal chiamante. Il secondo: la versione corrente non contatta nessun provider per nessun percorso. La motivazione del provider che la proposta dichiara è prosa che un umano legge, non un handle che il runtime risolve. Niente email inviate, niente calendario, niente spesa: il package osserva e propone, non esegue.

Per come si disegnano journey e workflow programmabili con trigger e blocchi di codice, il riferimento resta il framework esistente: la parte di orchestrazione resta valida, cambia chi la scrive.

L'agente che compone e propone

L'agente fa l'altro lavoro. Legge AGENTS.md, dodici skill di dominio e un server MCP, e produce moduli, workflow, policy, API e schermate come codice che revisioni nel repository. Non scrive mai direttamente sulle tabelle: chiama metodi di servizio e workflow nominati, come il cambio di stadio della pipeline che si muove da sola. E tutto ciò che il server MCP genera o distrugge resta in dry-run finché non passi un flag di apply esplicito.

La differenza con l'automazione sta tutta qui. Il timer apre una richiesta scritta da un umano a un istante scritto da un umano, e si ferma lì. L'agente compone cose nuove — codice, proposte, piani — e le sottopone ai gate: policy deterministica, approvazioni umane, audit. L'automazione non ha idee; l'agente non ha permessi. Quando i due ruoli si confondono — un timer che decide, un agente che esegue senza gate — non si è guadagnata efficienza: si è perso un controllo.

Chi decide, e dove resta scritto

Il terzo lavoro resta all'umano, ed è quello che tiene insieme gli altri due. Approvazioni sopra soglia, chiusure a tentativi esauriti, base legale e consenso: decisioni che il sistema presenta e non prende. Il racconto completo è nell'articolo sulle approvazioni umane, con il test che vieta la decisione all'agente e l'audit su ogni verdetto. La tesi completa è nel pillar sull'autonomia sotto controllo: agenti che propongono, policy che blocca, persone che decidono.

Fatti e limiti, separati

Fatti: scheduled ask con due soli tipi (follow-up di lavoro, revisione di rinnovo) e quattro stati (scheduled, due, opened, cancelled); timer senza autorità propria, con consumatore, contenuto e istante coperti da impronta; proposte di campagna con otto sezioni obbligatorie e approvazione solo da attore umano; nessun provider contattato dalla versione corrente; agente che compone codice e propone via workflow nominati, con MCP in dry-run fino a flag esplicito.

Limiti: la marketing automation non esegue niente — registra funnel osservati e proposte, non invia, non pubblica, non spende; Interactions non esiste; il pilot ha escluso la marketing automation dallo scope; predizione e data science restano fuori. Un timer, un package di proposte e dodici skill non misurano quanto il disegno regga in produzione: misurano che la divisione dei lavori esiste e gira.

Domande frequenti

Perché il timer non può completare o annullare?

Perché il suo contratto gli assegna un solo lavoro: aprire la richiesta scritta da un umano all'istante scritto da un umano. Completare o annullare sono decisioni, e le decisioni stanno ai gate — policy, umani, audit — non all'orologio.

Cosa può dichiarare una proposta di campagna?

Pubblico, esclusioni, canale, motivazione del provider, piano contenuti, piano tracciamento, rischi e approvazioni richieste. Senza queste otto sezioni la proposta non è pronta per un umano. E nessun provider viene contattato: la motivazione è prosa da leggere, non un handle da risolvere.

Che differenza c'è tra automazione e agente?

L'automazione apre richieste scritte da umani e non decide niente; l'agente compone cose nuove e le propone ai gate. L'automazione non ha idee, l'agente non ha permessi: quando i ruoli si confondono si perde un controllo, non si guadagna efficienza.

Chi approva una proposta?

Solo un umano nominato. L'approvazione rifiuta ogni altro attore e ricalcola la completezza dal record salvato, senza fidarsi di ciò che il chiamante aveva calcolato prima.