Agente AI ecommerce: come creare un assistente allo shopping

Un agente AI ecommerce può partire oggi da un agent loop, skill, contratti dei tool, controlli di sicurezza e pattern di interfaccia già definiti. Claude Commerce Agents offre questa struttura. Il lavoro vero consiste nel collegarla a dati di catalogo affidabili, associare ogni azione all’acquirente corretto, mantenere aggiornato l’inventario e fermare il modello prima del pagamento o di qualsiasi modifica irreversibile.

Portare tutto questo in produzione conta perché il vantaggio è misurabile. Secondo Anthropic, i retailer che usano shopping agent su Claude hanno registrato carrelli fino al 35% più grandi e una probabilità di completare l’acquisto superiore del 60%. Non sono risultati garantiti per ogni negozio. Indicano però che l’agente va trattato come un prodotto di conversione, non come un semplice widget di chat.

Il blueprint offre la struttura, non il negozio

Claude Commerce Agents è un’implementazione di riferimento Apache-2.0 per due ruoli. Lo shopping agent lavora a contatto con i clienti: può cercare e confrontare prodotti, pianificare un acquisto composto da più articoli, riempire il carrello, rispondere a domande su policy e ordini e ricordare le preferenze. Il merchant agent opera invece dietro le quinte: analizza le performance, controlla l’inventario, propone interventi sui prezzi e prepara campagne.

Per un assistente allo shopping rivolto al cliente, il design è volutamente semplice: un modello esegue un loop, le regole comuni risiedono nel system prompt, le procedure meno frequenti sono raccolte in cinque skill e i tool chiamano i sistemi commerce già in uso. È come avere un addetto esperto a un unico banco: segue l’intera conversazione, ma per verificare le scorte usa il terminale di magazzino, per l’identità consulta il sistema clienti e per il carrello passa dalla cassa.

La stessa definizione può essere eseguita tramite Messages API, Claude Agent SDK o Claude Managed Agents. Questa portabilità è utile, ma non rende gli esempi pronti per la produzione. Anthropic precisa che le demo non includono autenticazione. Il repository non effettua ordini, non addebita carte e non fornisce le regole aziendali su frodi, idoneità, inventario e conformità.

I conti economici iniziano dopo la demo

Il blueprint cambia il costo necessario per arrivare a una prima versione credibile. Nella pagina di lancio di Anthropic, Wix riferisce di aver ottenuto in 15 minuti un prototipo capace di ricevere prompt; Fetch dichiara di aver eseguito entrambi gli agenti di riferimento in locale in molto meno di un’ora; Zomato stima che le pratiche incluse possano far risparmiare settimane di tentativi ed errori. Sono testimonianze di partner, non garanzie sui tempi di consegna. Rendono comunque evidente lo spostamento del budget: meno ingegneria per inventare l’ossatura dell’agente, più lavoro su qualità del catalogo, permessi, valutazione e ultimo miglio fino al checkout.

Anche la spesa per il modello può essere contenuta rispetto al lavoro di integrazione. Il prezzo di Claude Sonnet 5 è di $2 per milione di token di input nuovi, $0.20 per milione di token letti dalla cache e $10 per milione di token di output. In un turno esemplificativo con 20,000 token di input e 800 di output, il costo del modello è $0.048 se tutti i token di input sono nuovi. Se 18,000 token di input arrivano dalla cache e 2,000 sono nuovi, lo stesso calcolo porta a $0.0156. Restano esclusi ricerca, hosting, osservabilità, supporto e tutte le API commerce che circondano il modello.

Anthropic afferma che le sue implementazioni commerce più efficaci raggiungono cache-hit rate dal 90% al 99%. Per questo il budget di produzione non consiste nel «comprare un LLM», ma nel rendere ogni attività di shopping completata precisa, veloce, attribuibile e sicura.

Come portare un agente AI ecommerce in produzione

L’ordine corretto di sviluppo segue il denaro e il rischio. Si parte dall’attività di acquisto, poi si collegano dati e identità, quindi si concedono le azioni e infine si ottimizza la velocità. Una conversazione impeccabile basata su scorte obsolete resta un negozio che non funziona.

1. Scegliere un solo obiettivo di acquisto e una metrica di successo

Non si parte da «rispondere a qualsiasi domanda sul catalogo». Meglio scegliere un compito preciso: aiutare il cliente a individuare la misura corretta di un materasso, comporre un kit da campeggio di tre prodotti entro un budget o trovare un’alternativa disponibile a un articolo esaurito.

Il successo va definito come attività completata, non come risposta gradevole. Tra le metriche utili ci sono una selezione di prodotti fondata sui dati, una raccomandazione accettata, l’aggiunta al carrello, il passaggio al checkout, la risoluzione senza ticket di assistenza e il tasso di reso degli ordini assistiti. Dimensione del carrello e completamento dell’acquisto vanno letti insieme a latenza e costo del modello. Una risposta economica diventa costosa quando consiglia la variante sbagliata.

2. Mettere ricerca e ranking esistenti dietro il tool del catalogo

Il modello non deve trasformarsi nel motore di ricerca del negozio. Nel pattern di Anthropic, search_products restituisce risultati già ordinati. Claude decide poi quali articoli soddisfano i vincoli dell’acquirente e quanti mostrarne.

Il catalogo va ricondotto a tre forme: prodotti semplici, famiglie di prodotti e varianti acquistabili. Una famiglia di camicie può includere opzioni di taglia e colore, mentre ogni variante possiede prezzo e disponibilità correnti. La ricerca può restituire la famiglia, ma una scrittura nel carrello deve indicare la variante esatta. Questa distinzione impedisce a un agente eloquente di aggiungere una «camicia blu» senza sapere se la taglia media blu sia disponibile.

È opportuno restituire soltanto i campi necessari al ragionamento del modello. In genere servono ID prodotto, titolo, prezzo, disponibilità, valori delle opzioni, attributi importanti e timestamp della fonte. Ripetere URL delle immagini e lunghi testi di marketing in ogni risultato consuma contesto senza migliorare la decisione.

Se esiste già un servizio di ricerca o raccomandazione, la logica di business deve rimanere lì. In caso contrario, va sistemato il retrieval prima di perfezionare il prompt. Un tool di catalogo non può compensare attributi incompleti, SKU duplicati o un ranking che ignora i vincoli dell’acquirente.

3. Associare l’identità prima che il modello veda un tool

L’autenticazione appartiene all’applicazione host. È questa ad autenticare l’acquirente, determinare se si tratta di un cliente o di un ospite e avviare una sessione. I metodi backend leggono l’identità dallo stato della sessione lato server. Il modello non riceve né l’ID cliente come argomento di un tool né la credenziale usata per chiamare il negozio.

Anche gli ospiti vanno trattati come principal reali, ma con meno permessi. Se un ospite chiede lo storico degli ordini o gli indirizzi salvati, il backend deve richiedere l’accesso. Dopo il login è preferibile iniziare una nuova sessione autenticata, anziché modificare a metà conversazione un’identità anonima.

È una separazione facile da trascurare in una demo e costosa da aggiungere in seguito. Segna la differenza tra «l’agente ha chiamato il tool degli ordini» e «questo acquirente autenticato era autorizzato a leggere questo ordine».

4. Rendere autorevole l’inventario nel momento dell’azione

I risultati di ricerca aiutano l’agente a ragionare, ma la verità appartiene al backend. All’interno dell’operazione sul carrello bisogna ricontrollare scorte, idoneità, prezzo, limiti di acquisto, orari limite per l’evasione e regole promozionali. Il controllo deve essere atomico, così se l’inventario cambia tra lettura e scrittura il sistema restituisce una risposta esplicita.

Quando la variante richiesta non è disponibile, la risposta deve includere l’ID non disponibile e le varianti valide della stessa famiglia. Sarà l’agente a spiegare il compromesso e a chiedere una scelta. I prodotti non vanno sostituiti in silenzio. Per marketplace, prezzi legati all’account, date di viaggio o ritiro in un negozio specifico, il contesto pertinente deve raggiungere il backend che calcola la risposta.

5. Trattare ogni tool come una superficie API soggetta a permessi

L’implementazione di riferimento costruisce l’elenco dei tool visibili in base alla configurazione del deployment. I sistemi assenti vanno disattivati. I nomi rimanenti devono essere inseriti in allow-list e qualsiasi chiamata esterna all’elenco va rifiutata nel codice.

Il passaggio successivo è aggiungere controlli di provenienza. Una scrittura nel carrello deve accettare solo un ID prodotto restituito dal server in quella sessione o già presente nel carrello. In questo modo si bloccano ID inventati, ID incollati da un altro account e istruzioni inserite nei contenuti dei prodotti. Lo stesso principio vale per il rendering: l’agente può scegliere un ID restituito, ma è il server a compilare la scheda prodotto usando il proprio record.

Schede prodotto, recensioni, policy, messaggi dei venditori e informazioni ricordate vanno considerati dati non attendibili. Il runtime di Anthropic pulisce e delimita il testo di terze parti prima che Claude lo legga. Le regole nel prompt aiutano, ma permessi, limiti di quantità, campi protetti e serializzazione delle scritture devono risiedere nel codice.

Se il deployment richiede più controllo sul runtime o sul gateway, la guida ai tool gestiti per agenti illustra le scelte infrastrutturali per gli agenti dotati di tool.

6. Fermare l’autorità dell’agente al checkout

Claude Commerce Agents traccia un confine netto: il modello può costruire e visualizzare il carrello, ma non può effettuare l’ordine né addebitare una carta. Dopo la chiamata al modello, l’host fornisce la destinazione del checkout, così l’URL non entra mai nel contesto del modello.

È possibile scegliere uno di questi passaggi:

1. Aprire il checkout all’interno dell’applicazione.
2. Aprire l’URL di checkout ospitato dalla piattaforma commerce.
3. Per un marketplace, mostrare un link di checkout per ogni venditore.

Questo confine è una buona scelta di prodotto, non una funzione mancante. Permette all’acquirente di verificare quantità, indirizzo, spedizione, sconti e prezzo totale nel sistema che già gestisce pagamenti e conformità.

Serve anche un passaggio separato all’assistenza umana per le ambiguità che l’agente non dovrebbe assorbire. Occorre definire quali intent lo attivano, quale coda lo riceve, quale riepilogo della conversazione viene trasferito e che cosa può approvare l’operatore. «Parlare con una persona» è un workflow con regole di identità e livelli di servizio, non una frase di ripiego.

7. Visualizzare l’interfaccia commerce tramite tool tipizzati

Griglie di prodotti, tabelle comparative, piani, carrelli e schede ordine dovrebbero essere tool di presentazione tipizzati. Claude chiama un componente con argomenti strutturati, il server li valida e li arricchisce, quindi il client mostra il risultato.

Così l’interfaccia visibile entra nel registro della conversazione. Quando l’acquirente dice «il secondo», l’elenco ordinato dei prodotti è ancora nei messaggi. Inoltre, non si chiede al modello di inventare markup personalizzato e fragile. Per costruire la shell conversazionale circostante, la guida alla creazione di chatbot affronta le decisioni più ampie sull’interfaccia.

8. Pianificare la latenza sull’intera attività

Il tempo fino al completamento va misurato come somma dei turni del modello e del tempo impiegato dai tool. Contano meno turni, tool più rapidi e una consegna dei token più veloce.

Il probabile contesto della pagina va caricato prima della prima chiamata al modello. Le letture indipendenti di catalogo o policy possono essere eseguite in parallelo. Ogni tool va avviato appena termina lo streaming dei suoi argomenti. Le schede prodotto possono comparire man mano che arrivano i campi, accompagnate da una semplice riga di avanzamento durante le ricerche lente.

Anthropic afferma che una risposta commerce renderizzata contiene spesso da 500 a 700 token di output: abbastanza da lasciare uno spinner vuoto per cinque o più secondi senza rendering progressivo. Riferisce inoltre che l’avvio immediato dei tool ha ridotto intervalli osservati di diversi secondi a poche centinaia di millisecondi. Questo lavoro ingegneristico viene prima del passaggio a un modello inferiore. Un modello meno capace può richiedere più turni e costare di più per attività completata.

9. Trasformare i requisiti di prodotto in eval

Un eval è un caso ripetibile che verifica il comportamento dell’agente a partire da uno stato noto. Si preparano messaggi, record di catalogo, carrello, dati utente e guasti rilevanti, quindi si valuta lo stato finale insieme alla risposta renderizzata.

La copertura deve includere cinque gruppi: richieste di shopping principali, turni dipendenti dal contesto, casi di sicurezza e brand, comportamento dell’interfaccia e messaggi che attraversano due funzionalità. A ogni caso positivo va affiancato il corrispettivo negativo. Se l’agente deve consigliare una variante disponibile, va testata anche la situazione in cui tutte le varianti valide sono esaurite. Bisogna includere testo ostile dentro una scheda prodotto, l’ID ordine di un altro utente, timeout, ricerche vuote, aggiunte ripetute al carrello e una variazione di prezzo tra ricerca e carrello.

Anthropic consiglia da 50 a 100 casi per ogni flusso utente come punto di partenza. Vanno costruiti con i team di prodotto, legale, customer care e merchandising, trasformando poi gli incidenti reali in casi di regressione permanenti. Le release canary devono superare soglie su accuratezza fondata sui dati, completamento delle attività, tasso di superamento dei controlli di sicurezza, latenza p50 e p99, cache-hit rate e costo per attività completata.

Sette casi d’uso ecommerce, ordinati per chi ne beneficia di più

I vantaggi maggiori emergono nei negozi in cui gli acquirenti hanno vincoli reali e il catalogo presenta compromessi significativi. Un chatbot generico per le FAQ è l’impiego più debole di questa architettura.

1. Consulente per prodotti ad alta considerazione

Per chi: negozi di materassi, elettrodomestici, attrezzatura outdoor o elettronica, dove i prodotti richiedono un confronto.

Workflow: l’acquirente indica obiettivo, budget, dimensioni e preferenze. L’agente interroga i risultati già ordinati del catalogo, recupera i dettagli dei candidati migliori, presenta un confronto strutturato, conferma la variante esatta e prepara il carrello.

Perché conviene: porta il supporto decisionale dentro la sessione di acquisto. È il caso d’uso più vicino agli aumenti di dimensione del carrello e completamento degli acquisti riportati da Anthropic, perché l’agente può sciogliere i dubbi prima che il cliente abbandoni il sito.

2. Creazione di bundle basati sull’obiettivo

Per chi: negozi che vendono prodotti destinati a funzionare insieme, come attrezzatura da campeggio, postazioni home office, routine skincare o il primo allestimento di una cucina.

Workflow: l’agente scompone un obiettivo in diverse esigenze di prodotto, esegue ricerche indipendenti in parallelo, verifica il budget complessivo, spiega i compromessi e aggiunge al carrello le varianti approvate.

Perché conviene: l’agente può aumentare il valore del carrello completando un’attività, invece di limitarsi a promuovere un articolo in più. Evita inoltre all’acquirente di aprire varie pagine di categoria e verificarne da solo la compatibilità.

3. Guida a varianti e vestibilità

Per chi: commercianti di abbigliamento, cosmetici, mobili e prodotti configurabili con un rischio elevato di reso.

Workflow: l’acquirente fornisce vincoli di vestibilità, tonalità, spazio o compatibilità. L’agente legge le opzioni della famiglia, controlla le scorte della variante esatta, presenta solo combinazioni valide e rifiuta di aggiungere un record di famiglia non definito.

Perché conviene: il valore sta nella riduzione delle scelte sbagliate, non nell’aumento della conversazione. Arrivare al checkout con una variante valida può ridurre cancellazioni e resi evitabili senza interrompere il percorso del cliente.

4. Scoperta dei prodotti e assistenza post-vendita

Per chi: negozi in cui la coda dell’assistenza gestisce di continuo stato degli ordini, resi, garanzie e domande sulle policy.

Workflow: la stessa conversazione passa dalla scoperta del prodotto alla consultazione autenticata di un ordine o alla ricerca nelle policy. L’agente legge i record del cliente, visualizza lo stato e trasferisce le eccezioni a un operatore insieme al contesto.

Perché conviene: un’unica interfaccia può sostenere sia la conversione sia la risoluzione autonoma. L’acquirente non deve ripetere a un altro bot il contesto relativo a prodotto, ordine e policy.

5. Assistente agli acquisti B2B consapevole dell’account

Per chi: distributori e attività in abbonamento con prezzi contrattuali, regole di idoneità o assortimenti approvati.

Workflow: l’host associa alla sessione l’account e il ruolo dell’acquirente. I tool backend restituiscono solo prezzi, prodotti consentiti e opzioni di evasione validi per quell’account. L’agente prepara un preventivo o il passaggio a un ordine di acquisto, senza fingere che il checkout consumer sia adatto.

Perché conviene: comprime un processo d’acquisto ricco di regole preservando i diritti dell’account. Il modello spiega le opzioni, ma l’autorità rimane nel sistema account.

6. Coordinatore del carrello per marketplace

Per chi: marketplace in cui più venditori possono soddisfare la stessa richiesta.

Workflow: il venditore diventa una dimensione della ricerca. L’agente confronta le offerte, raggruppa le righe del carrello per venditore e, quando necessario, l’host mostra un link di checkout distinto per ciascun venditore.

Perché conviene: trasforma un acquisto frammentato in un’unica conversazione di pianificazione senza nascondere la realtà commerciale: pagamenti ed evasione appartengono a commercianti diversi.

7. Copilot per inventario e promozioni del merchant

Per chi: team di merchandising che gestiscono vendite, scorte, prezzi e campagne su molti SKU.

Workflow: il merchant agent legge performance e avvisi sull’inventario, propone un riordino o una promozione, prepara la modifica e attende l’approvazione attraverso una vera interfaccia operativa prima di applicarla.

Perché conviene: può accorciare il lavoro di analisi e preparazione mantenendo i controlli maker-checker già adottati dall’azienda. L’autorità su prezzi, budget e inserzioni live resta alla persona.

Tre prodotti che vale la pena costruire

1. Un launch kit verticale per shopping agent

Si può creare un pacchetto pronto per la produzione dedicato a una categoria ad alta considerazione, per esempio attrezzatura outdoor, arredamento o beauty, e venderlo ai merchant che hanno superato i limiti di un widget di chat generico.

La scala dei prezzi esiste già. Brambles propone piani per assistenti allo shopping da $29 a $499 al mese per volumi compresi tra 10,000 e 500,000 sessioni. Rye addebita $149 al mese per l’infrastruttura di agentic commerce, più $0.02 per ogni recupero di prodotto e $0.05 per ogni ordine effettuato. Queste cifre mostrano sia la spesa in abbonamento dei merchant sia quella a consumo per l’infrastruttura.

La versione minima vendibile supporta una piattaforma commerce e una categoria. Mappa famiglie e varianti, associa le sessioni di ospiti e utenti autenticati, implementa ricerca e dettagli dei prodotti, costruisce il carrello, passa al checkout ospitato, invia in streaming due o tre componenti UI tipizzati e include un pacchetto di eval specifico per la categoria insieme a un percorso di trasferimento all’operatore.

Il limite è la pressione sui prezzi. Le piattaforme e gli assistenti economici negli app store possono già coprire domande e risposte generiche sui prodotti. Il livello difendibile deve comprendere logica di categoria, mappatura affidabile del catalogo, attribuzione delle conversioni e casi derivati dagli errori reali di quel verticale.

È l’opportunità più solida. È la più vicina ai ricavi del merchant e il blueprint elimina abbastanza lavoro generico da consentire a un piccolo team di concentrarsi sulle attività specifiche della categoria per cui i clienti sono davvero disposti a pagare.

2. Verifica della preparazione del catalogo e QA delle varianti

L’idea è creare un servizio che verifichi se un catalogo è in grado di rispondere in sicurezza alle query di un agente prima che lo shopping agent raggiunga i clienti.

Esiste già un’infrastruttura rilevante intorno a questo problema. Channel3 dichiara che il suo livello prodotto copre 100 milioni di prodotti presso 25,000 retailer e risponde in meno di un secondo. Rye addebita $0.02 per ogni recupero di prodotto. Google vende AI Commerce Search a $2.50 per 1,000 query. Il retrieval strutturato e aggiornato è già una voce di budget.

Un MVP importa un feed, costruisce le relazioni tra famiglia e varianti, controlla gli attributi obbligatori, confronta i timestamp di prezzi e scorte, esegue una libreria di vincoli di shopping reali e segnala per SKU le risposte mancanti o contraddittorie. A questo si aggiunge un test di replay che verifichi come la stessa query non produca mai, al momento del carrello, una variante non disponibile senza un percorso di recupero esplicito.

Il limite è la forza gravitazionale delle piattaforme. Shopify e altre piattaforme commerce possiedono feed di catalogo autorevoli e possono inglobare la validazione di base. Il prodotto deve offrire normalizzazione multipiattaforma, priorità dei problemi collegate alle attività di shopping perse e prove che le correzioni riducano le raccomandazioni errate.

3. Un sistema di eval e release gate specifico per il commerce

Si può costruire il livello di test che decide se una modifica a prompt, modello, tool o catalogo sia abbastanza sicura da essere rilasciata.

La valutazione degli agenti dispone già di un budget. Langfuse dichiara che oltre 50,000 aziende usano la sua piattaforma e propone i livelli di produzione a $29 e $199 al mese, con Enterprise a partire da $2,499. Anthropic consiglia da 50 a 100 casi di eval per ciascun flusso commerce. Ciò che manca non è l’ennesimo trace viewer, ma una libreria mantenuta di stati commerce, fixture di catalogo contaminate, invarianti del carrello e policy di rilascio.

L’MVP importa le trascrizioni, converte gli incidenti in casi snapshot e offre grader deterministici per provenienza del prodotto, corrispondenza dei prezzi ai dati, selezione delle varianti, limiti di quantità, confini del checkout, fughe di identità, recupero dai timeout e qualità del passaggio di consegne. Il confronto tra modelli e prompt deve basarsi su completamento delle attività, latenza p99 e costo per attività completata.

Il limite è un mercato orizzontale affollato. Il vantaggio difendibile deve derivare da fixture specifiche per il commerce, precisione dei grader, connettori di piattaforma e dati di benchmark. La sola osservabilità generica verrà copiata o inclusa in altri prodotti.

Che cosa non risolve Claude Commerce Agents

La valutazione onesta è che questo blueprint risolve meglio la struttura dell’agente che l’integrazione con il negozio. Offre un punto di partenza serio, non un prodotto di shopping in hosting.

• Non autentica gli acquirenti né autorizza il personale: la responsabilità resta all’host e al gateway.
• Non corregge dati di catalogo scadenti, ranking inefficace o ritardi nell’inventario: i sistemi commerce rimangono responsabili.
• Non effettua ordini, non conserva credenziali di pagamento, non addebita carte e non decide le policy antifrode.
• Non sceglie le regole di escalation umana, le code di servizio o i ruoli di approvazione.
• Non rende i miglioramenti di conversione dichiarati da Anthropic trasferibili a ogni catalogo: servono misurazioni controllate proprie.
• Non elimina le decisioni sulla privacy legate alla memoria. Le preferenze archiviate richiedono tipi di dati accettati, tempi di conservazione, accesso, correzione ed eliminazione.

Non conviene costruirlo per un catalogo minuscolo, dove i filtri risolvono già ogni acquisto con un clic. Non va lanciato se prezzi e scorte sono obsoleti. Non si concede accesso in scrittura solo perché il prompt sembra prudente. L’agente merita un posto quando la conversazione risolve un’attività di acquisto davvero complessa e i sistemi possono fornire dati aggiornati e soggetti a permessi.

La mossa da fare lunedì

La prossima settimana va scelto un solo flusso che genera ricavi. Si prendono 50 esempi reali da ricerca sul sito, chat di vendita e trascrizioni dell’assistenza. All’inizio si collegano soltanto ricerca nel catalogo e dettagli dei prodotti, mentre ogni altro tool restituisce non disponibile. Si misura se l’agente seleziona varianti disponibili e fondate sui dati e se gli acquirenti accettano la raccomandazione. Carrello e checkout vanno aggiunti solo dopo che il percorso di lettura supera i propri casi. Questa sequenza trasforma Claude Commerce Agents da demo d’effetto a release commerce controllata.

Come funziona un assistente AI per lo shopping?

Un solo agente Claude mantiene la conversazione e chiama tool tipizzati per ricerca nel catalogo, dettagli dei prodotti, carrello, policy, ordini, memoria e presentazione. Il backend autentica l’acquirente, applica le regole su prezzi e inventario e restituisce dati strutturati. Il modello ragiona su quei dati, ma non diventa la fonte di verità.

Come si collega il catalogo prodotti?

Il backend storefront del blueprint va implementato sopra i servizi di ricerca e prodotto esistenti. La ricerca restituisce famiglie già ordinate, i dettagli prodotto forniscono varianti acquistabili esatte e i sistemi autorevoli espongono prezzo e disponibilità correnti. Credenziali e identità dell’acquirente restano sul server.

Come funzionano i permessi utente in Sidekick?

Per un proprio agente di shopping o merchant va ripreso il principio di fondo, non l’implementazione del prodotto Sidekick. Utente e ruolo si determinano prima del turno dell’agente, si espongono solo i tool consentiti, le credenziali restano lato server, ogni metodo backend verifica di nuovo l’autorizzazione e le scritture sensibili del merchant richiedono una vera approvazione nell’host.

Posso realizzarlo in autonomia usando Claude o qualcosa di simile?

Sì. Il repository open source comprende esempi eseguibili e un plugin per Claude Code capace di creare la struttura iniziale sopra il backend. Resta comunque molto lavoro: autenticazione, mappatura del catalogo, inventario live, integrazione di carrello e checkout, permessi, passaggio all’assistenza umana, monitoraggio ed eval.

Per realizzare uno di questi prodotti attorno al catalogo e alle regole operative della propria attività, è possibile scoprire il servizio di sviluppo di agenti AI.