Il media buying agentico non può scalare senza le giuste fondamenta. Scopri come acquirenti e venditori ci riescono su Databricks.

Oggi il collo di bottiglia nel media buying non è il talento, ma il coordinamento

Ogni giorno, miliardi di dollari di pubblicità passano di mano attraverso un processo che è rimasto pressoché invariato da decenni: email, fogli di calcolo, PDF e telefonate. Un acquirente imposta una campagna, poi team qualificati contattano i publisher, inviano RFP, attendono i listini prezzi, confrontano i media kit e negoziano il prezzo prima di emettere finalmente un ordine di inserzione. Persone di talento trascorrono la maggior parte del loro tempo a coordinare la transazione invece di gestire il lavoro strategico e creativo.

L'attrito deriva dalla frammentazione. Non esiste un modo standardizzato per scoprire l'inventario, valutare il pubblico o stabilire relazioni di fiducia tra i partner, quindi ogni connessione tra acquirente e venditore diventa un'integrazione su misura. Poiché questo coordinamento richiede giorni, le decisioni vengono spesso prese sulla base di informazioni che hanno già ore o giorni. L'inventario, i prezzi e i segnali sul pubblico si muovono continuamente e, nel momento in cui una campagna viene approvata, la migliore opportunità potrebbe essere già passata.

L'ascesa dei flussi di lavoro agentici offre a questi team l'opportunità di eliminare dall'equazione il coordinamento manuale e ripetitivo, consentendo loro di dedicare il proprio tempo dove il giudizio conta di più: un targeting più preciso, creatività migliori e campagne che non sono solo più veloci da lanciare, ma anche più efficaci.

Perché questo problema è finalmente risolvibile e perché gli standard sono importanti

L'ultima ondata di AI ha creato software in grado di rispondere. La prossima ondata creerà software in grado di agire: agenti che perseguono un obiettivo, prendono decisioni, richiamano strumenti ed effettuano transazioni per tuo conto. Questo è il lavoro di coordinamento in cui sta affogando il media buying manuale: leggere un brief, cercare publisher, confrontare listini prezzi, negoziare il prezzo, emettere l'ordine. Per la prima volta, i sistemi multi-agente che utilizzano LLM e protocolli come MCP possono eseguire questo ciclo automaticamente.

Ma l'automazione da sola non basta. Gli standard Agentic Advertising Management Protocols (AAMP) di IAB Tech Lab stabiliscono un modello di comunicazione coerente: un vocabolario condiviso per inventario e segmenti di pubblico (AdCOM, le tassonomie), un protocollo di transazione comune (deal OpenDirect, OpenRTB) e un modello di registro per l'identificazione e la fiducia. Si potrebbe risolvere questo problema con l'AI e senza standard tra due parti. Tuttavia, gli standard sono ciò che consente all'intero settore di muoversi all'unisono, in modo che qualsiasi agente acquirente conforme possa effettuare transazioni con qualsiasi agente venditore conforme, proprio come qualsiasi browser può caricare qualsiasi sito web.

Gli standard aperti definiscono ciò che gli agenti si dicono l'un l'altro. La domanda successiva è dove questi agenti vengano effettivamente eseguiti: il loro stato, i loro modelli, la loro identità, la loro governance. È qui che entra in gioco Databricks.

Abbiamo creato un esempio di acquisto e vendita di media agentico interamente su Databricks. Acquirenti e venditori autonomi si scoprono a vicenda, concordano il prezzo e concludono accordi. È basato sul Software Development Kit (SDK) open source ufficiale di IAB Tech Lab, quindi non c'è lock-in a livello di protocollo, ed è ora disponibile come acceleratore che puoi distribuire con un singolo comando. Le istruzioni si trovano alla fine del blog.

In cosa consiste un media buy agentico

Un media buy agentico è una transazione semplice con tre attori:

• Un acquirente: un inserzionista (o la sua agenzia) con una campagna: un budget, il pubblico da raggiungere e un prezzo massimo da non superare.
• Venditori: publisher con inventario pubblicitario, ciascuno con un catalogo (un media kit di pacchetti e prodotti) e le proprie tariffe.
• Un registro: una directory che consente agli acquirenti di trovare i venditori e stabilire una relazione di fiducia identificando l'acquirente, l'accesso e le tariffe a lui riservati.

L'acquisto in sé è un ciclo breve: scoprire quali venditori hanno l'inventario giusto, valutarne il prezzo e prenotare l'accordo (o rinunciare). Oggi questo ciclo è in gran parte manuale; il cambiamento che stiamo dimostrando consiste nell'eseguirlo con agenti AI da entrambe le parti.

Gli agenti di aziende diverse hanno bisogno di un linguaggio condiviso per effettuare transazioni, ed è qui che gli standard aperti di IAB Tech Lab possono aggiungere valore. Non tratteremo qui i dettagli del loro SDK, ma ci concentreremo invece su ciò che serve per eseguire agenti acquirenti e venditori su Databricks.

Un ecosistema completo per agenti acquirenti e venditori

Gli agenti complessi vanno ben oltre le semplici richieste a un Large Language Model. Affinché questi agenti possano gestire una transazione multimediale, che potrebbe comportare una serie di attività come la pianificazione del pubblico, la ripartizione del budget, la ricerca di publisher, il rispetto di un prezzo massimo e la prenotazione dell'accordo, è necessario un sistema che gestisca:

• Stato: brief, identità, cataloghi, preventivi e ordini che devono persistere ed essere corretti dal punto di vista transazionale.
• Modelli serviti: modelli di base controllati che gli agenti possono richiamare, con il modello giusto per ogni attività.
• Dati controllati: il catalogo e i dati sul pubblico su cui gli agenti ragionano, con controlli di accesso.
• Identità e fiducia: chi è questo agente e cosa è autorizzato a vedere e fare?
• Osservabilità: una traccia di ogni decisione e chiamata di strumento, per il debug e l'audit.

Questo sistema può essere assemblato a partire da un fornitore di database, un host di modelli, uno strumento di governance, una piattaforma applicativa e un servizio di tracciamento. Su Databricks, è un'unica piattaforma.

Come si presenta l'architettura corretta?

Partiamo da un dato di fatto su questo mercato: gli acquirenti, i venditori e il registro sono entità separate. Questo divide il problema in due: come le parti comunicano tra loro e dove ciascuna parte esegue effettivamente la propria fase della transazione. I protocolli aperti rispondono alla prima domanda. Sono il filo conduttore tra le parti, che gestisce l'identificazione, la negoziazione e la liquidazione, e si fermano lì. Il luogo in cui un agente viene eseguito, mantiene il suo stato, dimostra la sua identità e rimane controllato è compito della piattaforma. Quindi ogni parte ha un'applicazione autonoma, creata su Databricks Apps, che possiede il proprio stato, la propria identità e i modelli che esegue, e incontra le altre solo tramite i protocolli. Le sezioni seguenti esaminano questi elementi uno alla volta e mostrano perché ognuno di essi appartiene a quel contesto.

Databricks Model Serving: la crew di agenti

Sotto il cofano, l'agente acquirente è una "crew", o gruppo, di agenti specializzati creati utilizzando CrewAI. La crew lavora in modo gerarchico su tre livelli, con l'agente di Livello 1 in grado di delegare compiti agli agenti di Livello 2 e così via. Questi agenti includono un Portfolio Manager di Livello 1 che definisce la strategia e suddivide il budget, gli Specialisti di Canale di Livello 2 specializzati nell'acquisto di un mezzo specifico e i lavoratori tattici di Livello 3 che pianificano il pubblico ed eseguono l'acquisto. Vengono eseguiti sulle API Databricks Foundation Model e sono configurati per utilizzare i modelli Claude a seconda della complessità dell'attività. L'uso di Databricks Unity AI Gateway per eseguire questi agenti semplifica la modifica dell'LLM che alimenta ciascun agente senza dover cambiare nient'altro.

Lakebase: stato transazionale per gli agenti

Gli agenti hanno bisogno di due cose dai loro dati: il contesto su cui agire e un luogo in cui registrare ciò che fanno. Il nostro acquirente legge i suoi brief, ogni venditore legge il suo catalogo di inventario e le regole di determinazione dei prezzi, e registrano ogni ordine prenotato. Si tratta del classico OLTP, quindi lo abbiamo inserito in Lakebase, il Postgres serverless di Databricks, in esecuzione proprio accanto al lakehouse. Gli agenti leggono e scrivono lo stato rapidamente con garanzie transazionali e, poiché si tratta di Postgres, i componenti del venditore si inseriscono direttamente senza un livello di dati personalizzato. E poiché Lakebase è serverless, si ridimensiona automaticamente in millisecondi per soddisfare i picchi di domanda. Gli agenti non arrivano a un ritmo costante e gli acquirenti possono rivolgersi a molti venditori contemporaneamente senza dover pre-allocare capacità.

Governance: oggi Lakebase, domani Unity Catalog

Al momento questa demo utilizza solo Lakebase. Nel mondo reale, Lakebase si colloca tra due confini controllati di Unity Catalog. In entrata, i dati vengono caricati dalle tabelle di Unity Catalog in Lakebase: l'inventario di un venditore e i relativi prezzi basati su modelli ML, i brief delle campagne di un acquirente e le definizioni del pubblico. In uscita, lo stato transazionale prodotto dagli agenti (chi ha acquistato cosa e a quale prezzo) viene sincronizzato nuovamente con l'ambiente di reporting. Entrambe le direzioni vengono eseguite su pipeline gestite da Databricks anziché su fragili ETL scritti a mano. Ciò lo rende un ciclo completo controllato: Unity Catalog traccia automaticamente la lineage di ogni caricamento e sincronizzazione, in modo da poter sempre tracciare quali dati sono stati spostati e dove. Il lakehouse rimane la fonte di verità su entrambi i lati e Lakebase è il livello operativo di hot-serving in cui gli agenti effettuano le transazioni.

Identità e fiducia

Le app si autenticano tra loro utilizzando OAuth — il meccanismo che stabilisce e verifica l'identità dichiarata da ciascuna — e un registro assegna a ogni acquirente un livello di attendibilità. Questo livello determina ciò che un acquirente può effettivamente vedere: un acquirente pubblico e sconosciuto ottiene solo fasce di prezzo e non può effettuare transazioni; un acquirente verificato e attendibile ottiene i prezzi esatti e può prenotare. Modificando l'attendibilità dell'acquirente, la stessa campagna che prima era limitata alle fasce di prezzo può ora essere prenotata. Su Databricks, questa gestione dell'identità è nativa rispetto al funzionamento già esistente delle app e dell'accesso ai dati. Laddove l'SDK di riferimento IAB richiede chiavi API, noi utilizziamo semplicemente i service principal integrati della piattaforma e OAuth per l'autenticazione secondo le migliori pratiche attuali, senza dover creare nulla in più.

Osservabilità

I team di agenti sono configurati per il tracciamento di MLflow, che si implementa facilmente tramite un hook di autologging CrewAI di una sola riga. Questo ci consente di acquisire i passaggi di ragionamento, le chiamate agli strumenti, i prezzi letti e la decisione di prenotazione o rinuncia di ogni esecuzione dell'agente. L'abbiamo mantenuto opzionale per la demo, ma questo è esattamente il modo in cui vorresti portare in produzione, eseguire il debug, ottimizzare e rendere affidabile un sistema autonomo quando si tratta di controlli di budget.

Guarda l'app di acquisto basata su agenti in azione

Seguiamo un'esecuzione completa su una campagna. Iniziamo inviando il brief dell'inserzionista, che in questo scenario è un Lancio del Brand per il Q3, con un budget di 200.000 $ suddiviso tra i tipi di media CTV e Linear TV, e un tetto massimo di CPM (Cost Per Mille) di 38 $. Questo brief viene inviato all'app dell'acquirente e il team di agenti avvia il processo di acquisto.

1. Pianificazione del budget: Il Portfolio Manager legge il brief e suddivide la spesa tra i canali, allocando 120.000 $ alla CTV e 80.000 $ alla TV lineare.

2. Traduzione del pubblico: Uno specialista mappa i destinatari espressi in linguaggio naturale nel brief in segmenti standard, convalidati rispetto alla IAB Tech Lab Audience Taxonomy: "sports fans" viene mappato in "Sports Enthusiasts" e "auto intenders" in "Auto Intenders".

3. Individuazione dei venditori: L'acquirente individua gli editori nel registro: Seller A (CTV) e Seller B (Linear), il che conferma l'identità dell'acquirente e ne definisce il livello di accesso.

4. Determinazione del prezzo: Un Channel Specialist per ciascun canale consulta il rispettivo venditore tramite MCP, associa il segmento di pubblico a un prodotto disponibile e legge il prezzo ufficiale.

5. Prenotazione o rinuncia: Una sola regola: prenota se il prezzo è pari o inferiore al limite di 38 $ e il pubblico del prodotto corrisponde; altrimenti, rinuncia.

Prossimi passi

Quello che abbiamo mostrato qui è la fase centrale della transazione: gli agenti che effettuano lo scambio. Ma la stessa piattaforma è anche il luogo ideale per costruire le fasi a monte e a valle: la creazione del brief dell'acquirente, i modelli di ML che definiscono i prezzi dei pacchetti del venditore, i modelli e i cruscotti utilizzati per stimare ricavi e spese. Si tratta di problemi le cui soluzioni dipendono da dati controllati e ML, entrambi presenti nativamente su Databricks. Il nostro team si impegna a aggiornare il repository, garantendo che si evolva insieme a IAB Tech Lab man mano che vengono rilasciate ulteriori funzionalità AAMP.

Distribuisci autonomamente

Questo sistema viene fornito come acceleratore Databricks Automation Bundle. Clona il repository, punta la CLI di Databricks alla tua area di lavoro ed esegui un singolo comando:

Usa questo comando per creare e distribuire le app e le istanze di Lakebase, inserire i dati iniziali e collegare l'acquirente ai venditori tramite il registro. Pochi minuti dopo avrai due agenti venditori attivi, un registro e una console acquirente, tutti operanti all'interno della tua area di lavoro.

Da lì, personalizzalo. Sostituisci il tuo inventario, le tue regole di prezzo e i tuoi segmenti di pubblico, oppure collega il livello Lakebase al tuo catalogo e ai tuoi modelli reali. Entra nella transazione come acquirente o venditore e osserva come reagiscono gli agenti: modifica un prezzo, cambia il livello di attendibilità di un acquirente, aggiungi un venditore e guarda come si sviluppa la trattativa. Si tratta di un modello funzionante su misura per l'acquisto e la vendita di media basati su agenti.

Guarda la demo di 5 minuti, quindi distribuisci l'acceleratore nella tua area di lavoro.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale