Cybersecurity
Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.
Scopri →
Servizi & Sistemi Linux
Domini, hosting, PEC, infrastruttura email, servizi di rete e sistemi Linux. Assistenza e gestione dell'infrastruttura Open Source.
Scopri →
Il 1 settembre Anthropic ha aperto commerce-agents, licenza Apache-2.0, in Python. Si presenta come blueprint di riferimento per costruire agenti di acquisto e agenti per i commercianti. La parte che merita attenzione non è il dominio ma il modo in cui è disegnato il percorso di scrittura.
Due ruoli, definiti una volta sola
Gli agenti sono due e stanno su lati opposti dello stesso negozio.
Lo shopping agent è quello che un’azienda incorpora nella propria applicazione per i clienti: cerca, confronta, pianifica, riempie il carrello, risponde a domande su ordini e politiche commerciali e ricorda quello che il cliente gli dice. Il merchant agent è quello che usa il personale per il back office: spiega le performance, mantiene le schede prodotto, agisce sugli avvisi di magazzino e di ordine, definisce prezzi e promozioni e prepara le campagne.
Ognuno è definito una volta sola attraverso quattro elementi, che il repository tiene separati: il prompt, le skill, i contratti degli strumenti e i gate. Da quella definizione unica il progetto porta lo stesso agente su tre runtime diversi: la Messages API, il Claude Agent SDK e i Managed Agents.
La struttura dei pacchetti segue la stessa idea. C’è un commerce-common con quello che i due ruoli condividono, cioè configurazione, fencing, memoria, skill, grounding, presentazione, frame dell’esecutore ed eventi. Poi per ciascun ruolo un core che tiene tipi, backend, prompt, contratti degli strumenti, gate ed esecutore, con accanto i runtime che cambiano soltanto il ciclo di turno.
È la stessa separazione fra nucleo e punti di estensione che avevamo trovato leggendo DeepSeek Harness, applicata qui a un dominio con conseguenze economiche dirette.
Dove si ferma la scrittura
Questa è la parte che rende il repository utile anche a chi non vende niente online.
La nota in testa alla documentazione è esplicita: “Nothing places an order, charges a card, or changes a live listing”. Il checkout non conclude, ma presenta il carrello all’applicazione ospite perché sia questa a completarlo. E ogni scrittura del merchant agent è una modifica in staging che viene applicata dalla superficie di approvazione dell’ospite, cioè da una persona.
La frase che chiude la nota è quella che conta di più per chi valuta l’architettura: “Business rules, authorization, and compliance are the deployment’s”. Il blueprint non pretende di portarsi dietro le regole di business, l’autorizzazione e la conformità: dichiara che restano di chi lo mette in produzione.
Nel core del merchant agent, accanto ai contratti degli strumenti, compaiono infatti due voci distinte, change guardrails e gates. Sono la traduzione in codice della stessa idea: l’agente può proporre una modifica ma non può applicarla. Il punto in cui si ferma è dichiarato nella definizione invece che lasciato al prompt.
Cosa si può eseguire
Il repository non è solo architettura. Porta quattro verticali eseguibili, retail, travel, telecom ed entertainment, ciascuno con una vetrina per il cliente e un portale per il commerciante, che girano sulle stesse librerie e si avviano con un comando.
Per chi vuole partire dal proprio sistema c’è un plugin per Claude Code, commerce-builder, con comandi per generare un progetto sui propri sistemi, aggiungere un flusso, scrivere le valutazioni e revisionare un agente che esiste già.
Tutto quello che si vede nelle demo è dichiaratamente inventato, con un’unica azienda di fantasia.
Cosa ne pensiamo
La cosa che ci sembra più utile è che il punto di arresto sia una proprietà del progetto e non una raccomandazione. Nella maggior parte delle integrazioni che vediamo, il confine fra quello che l’agente propone e quello che l’agente esegue vive in una frase del prompt di sistema, che è il posto meno robusto in cui possa stare. Qui il gate è un elemento della definizione dell’agente, allo stesso livello dei contratti degli strumenti. Sopravvive al cambio di runtime, perché lo stesso agente su Messages API, su Agent SDK o su Managed Agents si ferma nello stesso punto.
È lo stesso principio che avevamo descritto parlando di sicurezza e governance del ciclo agentico, dove il punto era che la sicurezza sta nell’harness e non nel prompt. Lo stesso principio è nei checkpoint umani di TrueForge.
La seconda osservazione riguarda la divisione delle responsabilità, che è dichiarata invece che sottintesa. Un blueprint che scrive per esteso che regole di business, autorizzazione e conformità restano di chi lo deploya è più onesto di uno che lascia credere di averle risolte. Per chi lavora in Italia questo significa che le parti che ricadono sotto normativa, dai diritti del consumatore alla gestione dei dati di pagamento, non arrivano dal blueprint e vanno progettate a parte.
Il criterio pratico che ne ricaviamo, per chiunque stia valutando un agente che tocca transazioni, è di guardare per prima cosa dove il codice impedisce la scrittura, invece di cosa il prompt gli chiede di non fare. Se la risposta è che non c’è un punto simile, quello che si sta costruendo non è un agente con supervisione umana ma un agente con una richiesta cortese di supervisione.