Il 2 settembre 2026, Anthropic ha pubblicato un blueprint per il commercio agentico che include implementazioni di riferimento per un agente d'acquisto e un agente destinato ai team commerciali. L'editore descrive un'architettura articolata attorno a un modello, competenze, strumenti aziendali e una suite di valutazioni. L'annuncio arriva mentre le piattaforme cercano di spostare ricerca, confronto e composizione del carrello in una conversazione. La vera difficoltà non è però produrre un dialogo convincente: è preservare la veridicità del catalogo, lo stato del carrello, il consenso e la responsabilità del pagamento.
Da ricordare: un agente commerciale deve ragionare liberamente ma agire attraverso interfacce ristrette e deterministiche. Catalogo, prezzo, disponibilità, condizioni e carrello restano fonti di verità esterne. L'agente propone e orchestra; i servizi aziendali convalidano, persistono e confermano.
1. Cosa comprende realmente un agente commerciale
Un agente d'acquisto aiuta un cliente a formulare un'esigenza, cercare prodotti, confrontare opzioni, creare una selezione coerente e passare un carrello al checkout. Può anche rispondere a domande successive all'ordine, quali tracciamento, reso o politica di rimborso.
Un agente commerciale si rivolge ai team dell'azienda. Analizza vendite e disponibilità, segnala un rischio di esaurimento, suggerisce una promozione o prepara una campagna. Le azioni esterne — modifica dei prezzi, pubblicazione o ordine a un fornitore — devono restare soggette a un'approvazione esplicita.
Questi due agenti talvolta usano gli stessi dati, ma le loro autorizzazioni differiscono. L'agente cliente legge il catalogo e modifica il carrello della sessione. L'agente commerciale può accedere ad aggregati, margini e dati di disponibilità più ampi. Riunirli sotto un'unica identità aumenta inutilmente il rischio.
Anthropic afferma che alcuni utilizzatori dei suoi agenti hanno osservato carrelli fino al 35% più alti e una probabilità d'acquisto superiore del 60%. Questi dati sono presentati dal fornitore e non costituiscono una garanzia applicabile a tutti i settori. Devono servire da ipotesi da testare, con particolare attenzione agli effetti di selezione, al margine e ai resi.
Il successo non può essere ridotto alla dimensione del carrello. Un agente che spinge prodotti inadatti può aumentare l'importo immediato degradando al tempo stesso fiducia, tasso di reso e valore del cliente.
2. Un'architettura semplice prima di moltiplicare i sottoagenti
La guida tecnica di Anthropic propone un modello principale in un ciclo agentico, dotato di competenze e strumenti. Sconsiglia di creare un sottoagente per ogni dominio quando conversazione, preferenze e carrello devono restare coerenti nel corso dei turni.
Questa raccomandazione è pragmatica. Ogni delega richiede il trasferimento di un contesto, introduce latenza e crea un rischio di perdita dello stato. Una richiesta come «sostituisci la giacca con un'opzione meno costosa ma mantieni la consegna venerdì» combina ricerca, confronto, carrello e logistica; si presta male a essere divisa in silos.
Le competenze permettono di caricare procedure al momento opportuno: politica di reso, guida di compatibilità, metodo di confronto o regole di stile. Gli strumenti svolgono operazioni deterministiche: cercare, verificare la disponibilità, creare un carrello, calcolare una consegna o leggere un ordine.
Un sottoagente resta utile per un compito autonomo e voluminoso, come una ricerca approfondita della quale torna all'orchestratore soltanto il risultato sintetico. Può essere giustificato anche quando un dominio regolamentato possiede il proprio agente, la propria identità e il proprio percorso di conformità.
La regola è non confondere la modularità del codice con la moltiplicazione degli agenti. I servizi aziendali restano modulari; la conversazione può mantenere un unico proprietario finché il contesto deve restare condiviso.
3. Mantenere catalogo, prezzi e disponibilità come fonti di verità
Il modello non deve mai inventare la scheda prodotto. Riceve risultati strutturati da un motore di ricerca o da un'API di catalogo: identificativo, variante, prezzo corrente, disponibilità, caratteristiche, condizioni e URL canonico.
La risposta visualizzata deve poter essere collegata a questi oggetti. Quando l'agente afferma che un prodotto è disponibile, l'interfaccia mostra l'ora della verifica. Prima dell'aggiunta al carrello e prima del checkout, il servizio riverifica prezzo e disponibilità.
Gli strumenti impongono schemi rigorosi. L'agente può richiedere search_products con un'esigenza e filtri autorizzati, ma non compone una query SQL né un URL interno. Può richiedere get_offer per un identificativo di variante, senza fornire esso stesso il prezzo atteso.
I confronti devono distinguere fatti e valutazioni. Peso, garanzia e composizione provengono dal catalogo. «Più adatto a un fine settimana con due bambini» è una raccomandazione prodotta dall'agente, che deve essere giustificata dai criteri espressi.
Le regole commerciali restano deterministiche. Uno sconto, un'idoneità, dei costi o un limite di quantità sono calcolati dai servizi esistenti. Il modello può spiegare il risultato, ma non riscrive la politica.
Questa architettura si inserisce nella preparazione descritta nel nostro articolo sul commercio agentico e l'esposizione del catalogo e del checkout.
4. Rendere il carrello idempotente e spiegabile
Il carrello è un oggetto transazionale, non un paragrafo di conversazione. Possiede un identificativo, una versione e uno stato conservato dal sistema di commercio. Ogni modifica usa una chiave di idempotenza affinché una ripresa di rete o una ripetizione del modello non raddoppi le quantità.
Gli strumenti devono esprimere l'intenzione: aggiungere una determinata variante, modificare una quantità, eliminare una riga o applicare un'opzione. Il servizio verifica la versione del carrello e rifiuta una scrittura se nel frattempo un altro canale l'ha modificato. L'agente rilegge allora lo stato e spiega il conflitto.
Prima di una modifica importante, l'interfaccia presenta la conseguenza: prodotto, variante, quantità, prezzo unitario, totale ed eventuale sostituzione. È necessaria una conferma quando l'agente cambia una caratteristica essenziale, sostituisce più articoli o supera un budget espresso.
Conservate la provenienza di ogni riga. Il cliente deve sapere ciò che ha richiesto esplicitamente, ciò che l'agente ha suggerito e ciò che ha confermato. Questa distinzione facilita l'assistenza ed evita che una raccomandazione sia percepita come una scelta certa dell'utente.
Prevedete il ritorno indietro. Finché il checkout non è avviato, un'operazione inversa deve poter ripristinare la versione precedente. Le modifiche sono registrate senza memorizzare inutilmente l'intera conversazione.
5. Separare raccomandazione, conferma e pagamento
Il pagamento costituisce una frontiera. Anthropic indica che il suo blueprint lascia il pagamento al commerciante, tramite il checkout esistente o un fornitore di pagamenti agentici. Questa separazione deve essere mantenuta, anche quando l'esperienza sembra continua.
L'agente può preparare il carrello, raccogliere preferenze di consegna e spiegare le condizioni. Un servizio deterministico calcola il totale finale, le tasse, la consegna e le promozioni. L'utente vede un riepilogo completo prima di confermare.
La conferma deve essere recente e specifica. Include commerciante, importo, valuta, indirizzo, modalità di consegna, articoli e condizioni principali. Una frase precedente come «sì, prendili» non deve essere riutilizzata dopo una modifica del carrello.
I dati di pagamento non devono entrare nel contesto del modello. Vengono immessi in un componente del fornitore e tokenizzati. L'agente riceve soltanto uno stato e un identificativo di transazione non sensibile.
In caso di ambiguità, lo stato resta payment_pending anziché paid. I webhook sono trattati in modo idempotente e lo stato visualizzato proviene dal backend. Un agente non deduce mai il successo da un semplice cambiamento visivo nel browser.
Per le azioni commerciali, applicate la stessa logica. Una proposta di riduzione del prezzo o di campagna è una bozza. Una persona autorizzata convalida l'oggetto, l'ambito, la data e l'impatto prima della pubblicazione.
6. Personalizzare senza oltrepassare il confine del consenso
La personalizzazione può migliorare la pertinenza, ma raccoglie rapidamente preferenze dichiarate, storico, comportamento, budget e contesto. L'utente deve capire quali dati sono usati e poter correggere o eliminare una preferenza.
Distinguete la memoria di sessione dalla memoria durevole. La prima serve al percorso attuale e scade. La seconda viene creata solo per una finalità chiara, con una base giuridica e un'interfaccia di gestione. Una preferenza dedotta non deve essere registrata come fatto senza convalida.
Evitate categorie sensibili o inferenze suscettibili di produrre discriminazione. Un agente non deve adeguare il prezzo o la qualità del servizio in funzione di una vulnerabilità presunta. Le regole di raccomandazione devono essere sottoposte ad audit e compatibili con la politica commerciale.
Anthropic indica che il suo blueprint mira a vincolare i suggerimenti ai prodotti e ai prezzi reali e a evitare pratiche manipolative di upsell. L'organizzazione deve tradurre questo obiettivo in controlli testabili: rispettare il budget, presentare le alternative meno costose, spiegare le commissioni, non creare una scarsità fittizia e non nascondere un'opzione pertinente.
Misurate anche gli effetti dopo l'acquisto: annullamenti, resi, reclami e soddisfazione. Una personalizzazione responsabile ottimizza la pertinenza nel tempo, non la pressione al momento del checkout.
7. Testare un sistema non deterministico con valutazioni aziendali
Una suite di valutazioni deve coprire il ragionamento, gli strumenti, l'interfaccia e il risultato transazionale. Iniziate con scenari rappresentativi: richiesta di più prodotti, budget rigido, incompatibilità, esaurimento, variante ambigua, consegna urgente, reso e domanda su un ordine.
Aggiungete casi avversi: istruzione malevola in una descrizione prodotto, prezzo contraddittorio, strumento lento, disponibilità modificata durante il compito, ripetizione di un webhook e tentativo di ottenere un dato di un altro cliente. Verificate che le politiche restino applicate indipendentemente dalla risposta del modello.
Misurate: tasso di compiti completati, accuratezza di prodotti e prezzi, coerenza del carrello, numero di turni, latenza, costo, conferme richieste, errori transazionali e interventi umani. Per la qualità commerciale, seguite conversione, margine, dimensione del carrello, soddisfazione, resi e valore a trenta o novanta giorni.
Le valutazioni offline non sono sufficienti. Un pilota A/B può confrontare l'agente con la ricerca classica, ma deve mantenere un'esperienza di controllo e salvaguardie identiche. I risultati sono segmentati per tipo di richiesta, terminale e complessità.
Esaminate le conversazioni non riuscite con una tassonomia: comprensione errata, catalogo incompleto, strumento in errore, scelta inadatta, politica bloccante o interfaccia confusa. Questa analisi guida i miglioramenti meglio di un prompt sempre più lungo.
A ogni cambiamento di modello, competenza, strumento o catalogo, rieseguite gli scenari critici. Un agente è un sistema in movimento; la sua certificazione non è mai definitiva.
8. Distribuire un progetto pilota in novanta giorni
Durante i primi trenta giorni, scegliete un percorso delimitato e non critico: una categoria di prodotti, un paese, utenti volontari e un checkout esistente. Esponete il catalogo in lettura, costruite il carrello in un ambiente di test e definite le valutazioni.
Dal giorno 31 al giorno 60, aprite il pilota con scritture reversibili sul carrello. Conservate una convalida esplicita prima di qualsiasi transizione verso il checkout. Misurate errori, latenza, costo e richieste abbandonate. Correggete dati e strumenti prima di aumentare l'autonomia.
Dal giorno 61 al giorno 90, aggiungete progressivamente il tracciamento dell'ordine o alcune funzioni commerciali in sola lettura. Le raccomandazioni di prezzo e di campagna restano bozze. Realizzate un'esercitazione di incidente: catalogo indisponibile, conferma duplicata, modello degradato o politica di reso errata.
I criteri per il passaggio alla scala devono essere definiti prima del pilota: zero errori di importo tollerati, tasso minimo di compiti completati, soglia di latenza, costo per sessione, soddisfazione, tasso di reso e assenza di scostamento dalla politica. Un aumento della conversione non compensa una perdita di integrità transazionale.
Prevedete una modalità degradata. Se il modello o uno strumento non è disponibile, l'utente ritrova ricerca, carrello e assistenza classici senza perdere il proprio stato. L'agente arricchisce il commercio; non deve diventare un singolo punto di guasto.
Conclusione
Gli agenti commerciali possono ridurre l'attrito tra intenzione e acquisto, soprattutto per richieste complesse che combinano più prodotti, criteri e fasi. Il loro valore dipende meno dall'eloquenza del modello che dall'architettura che lo circonda.
Catalogo, prezzo, disponibilità, carrello e pagamento devono restare deterministici e verificabili. L'agente orchestra strumenti ristretti, richiede conferme precise, rispetta il consenso ed è valutato sulla qualità durevole della transazione. Partitech accompagna gli attori del commercio nella progettazione di queste architetture, nell'integrazione con i sistemi esistenti e nella costruzione di piloti misurabili e reversibili.
Riferimenti verificati il 3 settembre 2026
- Anthropic — «Building commerce agents with Claude», 2 settembre 2026: https://claude.com/blog/claude-for-commerce-agents
- Anthropic — «A guide to the anatomy of effective commerce agents», 2 settembre 2026: https://claude.com/blog/the-anatomy-of-effective-commerce-agents
- Anthropic — repository di riferimento Commerce Agents: https://github.com/anthropics/commerce-agents