# Alejandro Rioja — IT > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/it/ Author: Alejandro Rioja Language: it --- ## Claude Fable 5, prime impressioni: il punto di vista di un operatore Source: https://alejandrorioja.com/it/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5 è il modello più capace di Anthropic e si vede nel lavoro agentico difficile e a lungo orizzonte, ma non è l'aggiornamento predefinito. Costa di più per token, usa un nuovo tokenizer che gonfia i tuoi conteggi di token di circa il 30%, esegue un thinking sempre attivo che non puoi disabilitare e può rifiutare richieste a livello di classificatore. Per la maggior parte dei carichi di lavoro Opus 4.8 resta la scelta giusta. Punta su Fable 5 quando il compito è davvero difficile. ## Indice _Aggiornato a giugno 2026._ **TL;DR:** Fable 5 è il modello più capace di Anthropic e si vede nel lavoro agentico difficile e a lungo orizzonte, ma non è l'aggiornamento predefinito. Costa di più per token, usa un nuovo tokenizer che gonfia i tuoi conteggi di token di circa il 30%, esegue un thinking sempre attivo che non puoi disabilitare e può rifiutare richieste a livello di classificatore. Per la maggior parte dei carichi di lavoro Opus 4.8 resta la scelta giusta. Punta su Fable 5 quando il compito è davvero difficile. **[La lettura dell'operatore]** Gestisco oltre 30 agenti in produzione tra un brand di consulenza e una struttura per il pickleball, quindi un nuovo modello di punta per me non è un benchmark: è una voce di costo e una migrazione. Ecco cosa è cambiato quando ho effettivamente collegato Fable 5 ad alcuni di loro, e dove invece ho lasciato Opus 4.8 al suo posto. ## Cos'è davvero Fable 5 [Claude](/recommends/claude) Fable 5 è il modello più capace che Anthropic abbia distribuito su larga scala. È pensato per l'estremità più esigente dello spettro: ragionamento profondo e lavoro agentico a lungo orizzonte, le esecuzioni in cui un agente deve tenere insieme un piano lungo decine di chiamate a strumenti senza perdere il filo. La superficie dell'API è quasi identica a quella di Opus 4.7/4.8, il che ne ha reso facile il test. Finestra di contesto da 1M di token per impostazione predefinita, fino a 128K token di output per richiesta. Se hai costruito qualcosa sulla recente linea Opus, la forma della richiesta ti è familiare. Le differenze stanno nei dettagli, e nei dettagli si annidano i soldi e le sorprese. Una nota sui nomi, così non ti confondi: **Mythos 5** è lo stesso modello — stesse capacità, stesso prezzo, stesso comportamento — disponibile solo tramite il programma Project Glasswing di Anthropic. Se non fai parte di quel programma, il modello che ti serve è `claude-fable-5`. Tutto ciò che segue vale per entrambi. ## Dove è davvero migliore Gli ho lanciato per primo il mio compito agentico più ostico: un'esecuzione in più passaggi di ricerca e sintesi che legge un mucchio di fonti, verifica le affermazioni incrociandole e scrive un brief con le citazioni. È il tipo di lavoro in cui i modelli più deboli vanno alla deriva: dopo una decina di chiamate a strumenti perdono il conto di quale affermazione provenisse da quale fonte. Fable 5 ha tenuto il filo. La sintesi era più stringata, le citazioni sono rimaste agganciate alle affermazioni giuste e ha colto due contraddizioni tra le fonti su cui la mia versione con Opus 4.8 era passata sopra in sordina. Sul ragionamento lungo e strutturato è un vero salto di qualità, non un marginale aumento nei benchmark. Questa è l'argomentazione onesta a suo favore. Se la modalità di fallimento del tuo agente è "si sgretola sul 10% più difficile", Fable 5 riduce quel divario. Se il tuo agente riassume newsletter o redige post per i social, la differenza non la sentirai — e pagherai per una capacità che non stai usando. ## L'insidia sui costi di cui nessuno ti avverte Ecco quella che ti coglierà alla sprovvista se scorri di fretta le note di rilascio. Fable 5 arriva con un **nuovo tokenizer**, e gli stessi contenuti si tokenizzano in circa il **30% di token in più** rispetto alla linea Opus. Rileggilo, perché si combina con il prezzo. Fable 5 ha già di per sé un prezzo superiore alla fascia Opus (10 dollari per milione di token in input, 50 dollari per milione in output). Ora aggiungi un'inflazione dei token di circa il 30% sopra ogni prompt e ogni completamento. Un carico di lavoro invariato — stessi prompt, stessi output — può costare sensibilmente di più dopo la migrazione, prima ancora che tu abbia cambiato una sola cosa di ciò che fa l'agente. Quindi non riutilizzare i tuoi vecchi numeri. Le tue impostazioni di `max_tokens`, i tuoi budget per la finestra di contesto, le tue stime di costo per esecuzione — erano tutti misurati su un tokenizer diverso. La buona notizia: l'endpoint di conteggio dei token restituisce i conteggi con **entrambi** i tokenizer quando passi `model: "claude-fable-5"`, così puoi misurare lo scarto sui tuoi prompt reali prima di cambiare qualsiasi cosa. ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` L'ho eseguito per primo sui miei prompt più pesanti. Lo scarto non era uniforme — varia in base al contenuto — ma "metti a budget circa il 30% in più, poi aggiungi il sovrapprezzo" era il modello mentale giusto. ## Il thinking è sempre attivo — e non puoi disattivarlo Su Fable 5, il thinking adattivo è sempre in funzione. L'unica nuova breaking change rispetto alla linea Opus: se invii un esplicito `thinking: {type: "disabled"}`, ottieni un 400. La soluzione è semplice — basta omettere del tutto il parametro `thinking` — ma se avevi del codice che disabilitava esplicitamente il thinking per chiamate veloci ed economiche, quel codice ora va in errore. Inoltre non ricevi indietro la catena di ragionamento grezza. Fable 5 la protegge: ricevi normali blocchi `thinking` e puoi chiedere un riepilogo leggibile con `display: "summarized"`, ma il ragionamento non filtrato non viene mai esposto. Per la maggior parte delle applicazioni non è un problema — leggi il riepilogo se ti serve visibilità. Il punto in cui conta sono gli **agenti multi-turno**: quando prosegui una conversazione sullo stesso modello, devi rispedire i blocchi di thinking **invariati**. Se li elimini o li modifichi, il turno si rompe. Se stai costruendo loop agentici, tratta i blocchi di thinking come token opachi da riportare avanti alla lettera. ## I rifiuti ora sono un problema di control-flow Questo è il cambiamento che incide di più su come scrivi il codice attorno al modello. Fable 5 esegue classificatori di sicurezza sulle richieste in arrivo, mirando soprattutto alla biologia di ricerca e a gran parte dei contenuti di cybersecurity. Quando una richiesta viene declinata, ottieni un **HTTP 200 di successo** con `stop_reason: "refusal"` — non un errore, non un'eccezione. L'array `content` potrebbe essere vuoto. Se il tuo codice fa `response.content[0].text` senza prima controllare `stop_reason`, andrà in crash il giorno in cui una richiesta verrà rifiutata. E del lavoro adiacente benigno — strumenti di sicurezza legittimi, compiti nelle scienze della vita — può occasionalmente far scattare un falso positivo, quindi non è un problema solo per chi fa cose losche. La regola è: **diramare su `stop_reason`, mai su `stop_details`.** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` Per la produzione c'è una strada più pulita: un parametro `fallbacks` lato server (in beta) che riprova automaticamente una richiesta rifiutata su `claude-opus-4-8` nello stesso giro di richiesta, applicando una riprezzatura in stile credito. Se gestisci agenti senza supervisione, predisponilo così che un singolo rifiuto da falso positivo non mandi a sbattere un'intera esecuzione. È la stessa lezione che continuo a re-imparare sugli agenti che [continuano a fallire in produzione](/blog/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it): il fatto che il modello diventi più intelligente non elimina la necessità di gestire i suoi casi limite — li sposta soltanto altrove. ## Altri due dettagli sulla migrazione Un paio di cose più piccole che mi sono costate tempo, perché non costino il tuo: - **Niente prefill dell'assistente.** Se guidavi l'output precompilando l'ultimo turno dell'assistente, quel pattern non c'è più. Usa invece output strutturati (`output_config.format`) o istruzioni nel system prompt. - **La retention dei dati a 30 giorni è obbligatoria.** Fable 5 non è disponibile in modalità zero-data-retention. Se sei in ZDR per ragioni di conformità, Fable 5 è fuori discussione e Opus 4.8 resta il tuo tetto. Verificalo *prima* di pianificare una migrazione, non dopo. ## Conviene davvero passare? Ecco il mio verdetto da operatore dopo averci convissuto. **Fable 5 non è l'obiettivo predefinito del "aggiorna all'ultimo modello": lo è Opus 4.8.** La cosa sorprende le persone, ma è l'inquadramento giusto. Opus 4.8 è un semplice cambio di model-ID rispetto a 4.7, senza nuove breaking change, costa meno, e per la stragrande maggioranza del lavoro agentico è indistinguibile nella qualità dell'output. Fable 5 si guadagna il suo posto sui compiti davvero difficili: agenti a lungo orizzonte che devono restare coerenti lungo molti passaggi, ragionamento profondo su più fonti, le esecuzioni in cui il fallimento che vuoi eliminare è sottile. Per questi, la capacità è reale e vale il sovrapprezzo. Per tutto il resto — redazione di contenuti, classificazione, routing, sintesi — stai pagando più token a un prezzo più alto per una qualità che non riesci a percepire. Alla fine ho finito per usarli entrambi. Il mio agente di ricerca e sintesi è passato a Fable 5. Tutto il resto è rimasto su Opus 4.8. È proprio questa la divisione che conta: scegli il modello per ogni compito, non per moda. Se gestisci una flotta di agenti, vale la stessa disciplina di cui ho scritto nel [mio stack da operatore del 2026](/blog/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack): instrada il lavoro difficile verso il modello costoso e smetti di pagare troppo per quello facile. ## La conclusione dell'operatore Testa Fable 5 sul tuo singolo compito più difficile prima di toccare qualsiasi altra cosa — è lì che ripaga, e se lì non sposta l'ago della bilancia, non lo farà da nessuna parte. Esegui il contatore di token sui tuoi prompt reali, così l'inflazione del tokenizer di circa il 30% e il sovrapprezzo non ti sorprendano sulla fattura. Aggiungi un controllo su `stop_reason: "refusal"` (o il fallback lato server verso Opus 4.8) ovunque Fable 5 tocchi la produzione. Poi instrada con criterio: Fable 5 per il 10% difficile, Opus 4.8 per il resto. Il modello migliore non è quello più capace — è quello adatto al compito. --- ## La guida definitiva per principianti agli agenti IA: Cowork, Codex e gli strumenti che fanno davvero il lavoro Source: https://alejandrorioja.com/it/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: Gli agenti IA sono il passo oltre i chatbot: gli dai un obiettivo in italiano semplice e loro fanno il lavoro — leggono i tuoi file, elaborano, organizzano, scrivono ed eseguono codice. Cowork è la rampa di accesso senza codice; Codex e Claude Code sono per chi lavora con una base di codice. L'abilità che conta è scrivere un'istruzione chiara e ben delimitata, non imparare a programmare. ## Table of contents _Aggiornata giugno 2026._ **TL;DR:** Gli agenti IA sono il passo oltre i chatbot: gli dai un obiettivo in linguaggio comune e loro fanno il lavoro — leggono i tuoi file, elaborano, organizzano, scrivono ed eseguono codice, e verificano i propri risultati. **Cowork** è la rampa di accesso senza codice per i non tecnici; **Codex** e **Claude Code** sono per chi lavora con una base di codice. L'unica abilità che conta è scrivere un'istruzione chiara e ben delimitata — non imparare a programmare. **[Nota dell'autore]** Gestisco più di 30 agenti con codice ogni giorno, ma la maggior parte delle persone non ha bisogno di codice per catturare l'80% del valore. Ha bisogno di un'istruzione chiara e di un posto dove eseguirla. Questa guida è l'introduzione che darei a un amico intelligente che non ha mai scritto una riga di codice. ## Cos'è davvero un "agente IA" Un chatbot risponde a una domanda. Un **agente** completa un compito. La differenza è che un agente può eseguire azioni in un ciclo — leggere un documento, decidere cosa fare dopo, scrivere un file, eseguire un comando, verificare il risultato, correggere quello che non va — senza che tu debba guidare ogni passo. In concreto: non chiedi "come pulisco questo foglio di calcolo?" Dici "ecco il foglio — elimina i duplicati, correggi i formati delle date e segnala le righe con e-mail mancanti", e l'agente lo fa e ti restituisce il file pulito. Questo cambiamento — da *consiglio* a *lavoro completato* — è tutto il punto. ## Le due famiglie di strumenti Ci sono due porte d'ingresso in questo mondo, e hai bisogno solo di quella che corrisponde al tuo lavoro. ### Porta 1: Agenti senza codice (inizia qui se non programmi) **Claude Cowork** è uno spazio di lavoro dove dai a Claude un obiettivo più i materiali — file, link, note — e produce il risultato che revisioni e usi: una bozza, un riassunto, un piano, un foglio di calcolo pulito. Scrivi istruzioni, non codice. Pensa a "un assistente molto capace che legge velocemente e non si stanca mai", non a "uno strumento di programmazione". Questo è il punto di partenza giusto per marketer, fondatori, operatori, scrittori, analisti — chiunque il cui lavoro consista principalmente in documenti, ricerche e decisioni. ### Porta 2: Agenti di programmazione (usali appena è coinvolta una base di codice) **OpenAI Codex** e **Claude Code** sono agenti che vivono dove il software viene costruito — un terminale, un IDE o il cloud. Descrivi un cambiamento ("aggiungi un interruttore per la modalità scura", "correggi questo test che fallisce", "migra questo file alla nuova API") e l'agente modifica il codice, lo esegue e itera fino a quando funziona. Continui a revisionare tutto; l'agente fa la digitazione. Non devi essere un ingegnere senior per usarli. Molti non-sviluppatori usano agenti di programmazione per lanciare piccoli siti web, automatizzare fogli di calcolo come script e correggere bug in strumenti che non hanno scritto. Ma c'è una vera curva di apprendimento, quindi la maggior parte dei principianti è meglio servita cominciando dalla Porta 1 e passando la Porta 2 quando si trova davanti a un compito che necessita davvero di codice. ## Il tuo primo risultato (fallo oggi) Scegli un compito piccolo e fastidioso che fai spesso. Buoni primi candidati: - Trasformare una trascrizione di riunione disordinata in note pulite più un elenco di punti di azione. - Riassumere un lungo PDF in 5 punti e 3 domande che vale la pena fare. - Riscrivere una bozza di e-mail in modo che sia chiara, calorosa e con meno di 120 parole. Poi usa la struttura che rende gli agenti affidabili anziché imprevedibili — **ruolo → input → istruzione esatta → vincolo → una verifica**: > Sei il mio assistente. Ecco una [trascrizione di riunione / PDF / bozza di e-mail] incollata qui sotto. Fai questo: [trasformala in note pulite con un elenco in grassetto di \"Punti di azione\" / riassumi in 5 punti + 3 domande di follow-up / riscrivi in modo che sia chiara, calorosa e con meno di 120 parole]. Mantieni la mia voce. Fammi una domanda se qualcosa è ambiguo prima di iniziare. > > [incolla il tuo contenuto qui] Tutto qui. Hai appena delegato un compito. La struttura è l'intero gioco — e funziona in modo identico in Cowork, ChatGPT o in un agente di programmazione. ## Il prompt in quattro parti che rende gli agenti affidabili I principianti pensano che il segreto sia una frase magica. Non lo è. È la specificità. Ogni istruzione affidabile per un agente ha quattro parti: 1. **Ruolo** — chi è l'agente per questo compito ("Sei il mio assistente di ricerca"). 2. **Contesto** — i materiali e il *perché* ("Sto preparandomi per una chiamata di vendita con un fondatore fintech"). 3. **Compito** — l'azione esatta e delimitata ("Trova tre fatti recenti sulle serie di finanziamento e redigi due domande di apertura"). 4. **Vincoli + una verifica** — formato, lunghezza, tono e un'istruzione per chiedere prima di assumere ("Solo punti elenco, cita le fonti, fammi una domanda di chiarimento se l'azienda è ambigua"). Vago in entrata, vago in uscita. Più un agente può *fare*, più la tua chiarezza conta — un chatbot che fraintende spreca una frase; un agente che fraintende spreca un pomeriggio di lavoro che devi disfare. ## Errori da principiante da evitare - **Trattarlo come un motore di ricerca.** Non fare domande di una riga. Dagli lavoro vero con file veri. - **Saltare il vincolo.** "Scrivimi un piano" ti dà un muro di testo. "Scrivimi un piano di una pagina con tre fasi e un responsabile per compito" ti dà qualcosa di utilizzabile. - **Non chiedere una verifica.** Aggiungi "fammi una domanda se qualcosa è ambiguo" e coglierai i malintesi *prima* che l'agente inizi, non dopo. - **Lasciare che gli agenti di programmazione girino incustoditi su codice importante.** Revisiona il diff. Gli agenti sono veloci e per lo più corretti, ma "per lo più" sta facendo lavoro in quella frase — tieni un umano nel ciclo su tutto ciò che viene messo in produzione. - **Passare alla Porta 2 troppo presto.** Se il tuo compito riguarda documenti e decisioni, non hai mai bisogno di aprire un terminale. ## Come scegliere il tuo primo strumento - **Il tuo lavoro riguarda documenti, ricerche e testi** → inizia con **Cowork** (o il prodotto chat che già paghi, usato in modalità agente). - **Vuoi costruire o correggere software** → **Claude Code** o **OpenAI Codex**. - **Vuoi lavoro ricorrente senza intervento** (un digest giornaliero, un rapporto settimanale) → passa ai **[compiti pianificati](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)** una volta che hai padroneggiato il prompt manualmente. ## Agenti IA per principianti — FAQ 2026 ### Devo saper programmare per usare gli agenti IA? No. Gli agenti senza codice come Claude Cowork sono costruiti per utenti non tecnici — scrivi istruzioni in linguaggio comune. Gli agenti di programmazione come Codex e Claude Code comportano una curva di apprendimento, ma anche quelli sono sempre più usati da persone che non si considerano programmatori. Inizia senza codice, passa al codice solo quando un compito lo richiede. ### Qual è la differenza tra un chatbot e un agente IA? Un chatbot risponde a domande; un agente completa compiti. L'agente può eseguire una sequenza di azioni — leggere, decidere, agire, verificare, correggere — in un ciclo, producendo lavoro completato anziché consigli. In pratica lo stesso prodotto spesso fa entrambe le cose; la "modalità agente" è il comportamento dell'agente. ### Cowork è migliore di Codex? Sono per lavori diversi, non migliori o peggiori. Cowork è uno spazio di lavoro senza codice per documenti, ricerche e operazioni. Codex (e Claude Code) sono agenti di programmazione per costruire e correggere software. Scegli quello che corrisponde al tuo compito. ### Come ottengo buoni risultati da un agente IA? Specificità. Usa la struttura in quattro parti: ruolo, contesto, compito esatto e vincoli più una verifica. Dagli materiali veri, digli il formato che vuoi e chiedigli di segnalare le ambiguità prima di iniziare. Le istruzioni chiare contano più di qualsiasi "prompt magico". ### È sicuro lasciare che gli agenti IA girino da soli? Per compiti a basso rischio e reversibili (elaborare, riassumere, organizzare), sì — revisiona l'output e vai avanti. Per tutto ciò che cambia sistemi reali (pubblicare codice, inviare messaggi, eliminare dati), tieni un umano nel ciclo e revisiona prima che agisca. La reversibilità è il test giusto: più qualcosa è facile da annullare, più autonomia può avere in sicurezza. **Letture correlate:** [Come essere citato nelle risposte di ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [Il manuale di llms.txt](https://alejandrorioja.com/llms-txt-playbook/) · [Come usare i compiti pianificati di Claude](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **Vuoi aiuto per mettere gli agenti al lavoro nella tua azienda?** Costruisco sistemi di agenti IA per team operativi — [contattami](https://alejandrorioja.com/contact/) o leggi di più su [come penso a tutto questo](https://alejandrorioja.com/seo-tips/). --- ## Come guadagna Anthropic? Il modello di business di Claude spiegato Source: https://alejandrorioja.com/it/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropic vende l'accesso ai suoi modelli di IA Claude attraverso cinque canali principali: un'API basata sull'utilizzo (paghi per token), abbonamenti consumer (Claude Pro e Max), piani enterprise (licenze Team e Enterprise), Claude Code per gli sviluppatori e distribuzione tramite marketplace cloud come Amazon Bedrock e Google Vertex. L'API e il business enterprise — non l'app consumer — sono i principali motori di ricavi. ## Table of contents _Aggiornato giugno 2026._ **TL;DR:** Anthropic vende l'accesso ai suoi modelli di IA Claude attraverso cinque canali principali: un'**API basata sull'utilizzo** (paghi per token), **abbonamenti consumer** (Claude Pro e Max), **piani enterprise** (licenze Team e Enterprise), **Claude Code** per gli sviluppatori e **distribuzione tramite marketplace cloud** come Amazon Bedrock e Google Vertex AI. L'API e il business enterprise — non l'app di chat consumer — sono i principali motori di ricavi. **[Nota dell'operatore]** Sviluppo sull'API di Anthropic ogni giorno, quindi vedo il business dall'interno del contatore. Il punto fondamentale: Anthropic è un'azienda B2B con una porta d'ingresso consumer. L'app di chat che usi è marketing e una linea di ricavi; il vero denaro sta negli sviluppatori e nelle aziende che misurano i token tramite l'API e pagano per licenze su larga scala. ## Cos'è Anthropic Anthropic è un'azienda di ricerca sulla sicurezza dell'IA, fondata nel 2021, che sviluppa la famiglia di grandi modelli linguistici **Claude**. Vende questi modelli — e gli strumenti attorno ad essi — a consumatori, sviluppatori e imprese. È un'azienda privata, fortemente supportata da investitori strategici tra cui Amazon e Google, che fungono anche da partner cloud e di distribuzione. Il prodotto è l'intelligenza come servizio: non acquisti un software in scatola, ma noleggi l'accesso a un modello che legge, scrive, ragiona e agisce per conto tuo. Ogni canale qui sotto è un diverso involucro attorno allo stesso asset principale. ## Come guadagna Anthropic? ### 1. L'API (basata sull'utilizzo, il motore centrale) Il fondamento del business. Sviluppatori e aziende chiamano Claude tramite un'API e pagano **per token** — grossomodo, per ogni porzione di testo in entrata e in uscita. Il prezzo scala con la capacità del modello: - **Claude Opus** (il livello più capace) è il più costoso — nell'ordine di pochi dollari per milione di token in input e molte volte tanto per l'output. - **Claude Sonnet** (il modello equilibrato) si trova nel mezzo. - **Claude Haiku** (il livello veloce ed economico) è il meno costoso, per attività semplici ad alto volume. I token in output costano più di quelli in input, e funzionalità come il contesto lungo, il prompt caching e l'elaborazione in batch hanno la propria tariffazione. La dinamica chiave: **i ricavi scalano direttamente con l'utilizzo**. Una startup che integra Claude nel proprio prodotto e cresce fino a milioni di utenti genera ogni mese maggiori ricavi API senza che Anthropic firmi un nuovo contratto. Questo modello basato sull'utilizzo spiega perché i laboratori di IA parlano di ricavi "run-rate" che crescono così velocemente — si moltiplicano con la crescita dei clienti stessi. ### 2. Abbonamenti consumer (Claude Pro e Max) Le app Claude (web, desktop, mobile) sono gratuite da provare, con livelli a pagamento per chi le usa intensamente: - **Claude Pro** — una quota mensile fissa per limiti di utilizzo più elevati, accesso ai migliori modelli e funzionalità come contesto più ampio e accesso prioritario. - **Claude Max** — un livello di prezzo più alto per gli utenti avanzati che raggiungono i limiti di Pro, con uno spazio di utilizzo sostanzialmente maggiore. Questa è la parte più visibile di Anthropic ma, per un'azienda i cui clienti sono principalmente altre aziende, è una fetta più piccola rispetto alle linee API ed enterprise. Il suo valore strategico è tanto come funnel e superficie di brand quanto come fonte di ricavi. ### 3. Enterprise (licenze Team e Enterprise) Qui risiede gran parte del denaro duraturo. Le aziende acquistano Claude per i loro dipendenti su base **licenza per utente**, con piani costruiti per le organizzazioni: - **Team** — per le aziende più piccole: utilizzo condiviso, fatturazione centralizzata, funzionalità collaborative. - **Enterprise** — per le grandi organizzazioni: sicurezza e conformità elevate, single sign-on, finestre di contesto più ampie, controlli amministrativi e garanzie di utilizzo. I contratti enterprise sono ricorrenti, si espandono nel tempo (più licenze, più utilizzo) e portano con sé quel tipo di costi di migrazione che rendono i ricavi stabili. Questo è il classico movimento SaaS sovrapposto al modello. ### 4. Claude Code (strumenti per sviluppatori) **Claude Code** è lo strumento di codifica agentivo di Anthropic — un agente che scrive, modifica ed esegue codice nel tuo terminale, IDE o nel cloud. È monetizzato tramite gli stessi binari di abbonamento e utilizzo (è incluso nei livelli Pro/Max/Team/Enterprise e si conta contro il tuo piano). Strategicamente fa due cose: è una linea di ricavi a sé stante e genera molto utilizzo di token ad alto valore, poiché gli agenti di codifica consumano una grande quantità di capacità del modello. ### 5. Distribuzione tramite marketplace cloud (AWS, Google e altri) Anthropic non vende Claude solo direttamente — distribuisce anche tramite le grandi piattaforme cloud: - **Amazon Bedrock** e **Claude Platform on AWS** — i clienti già su AWS accedono a Claude tramite l'infrastruttura e la fatturazione di Amazon. - **Google Vertex AI** e **Microsoft Foundry** — la stessa idea su Google Cloud e sulla piattaforma di Microsoft. Questi canali raggiungono le aziende dove già vivono la loro spesa cloud e i loro processi di approvvigionamento, il che riduce l'attrito per adottare Claude. I ricavi vengono condivisi con la piattaforma, ma la portata è enorme — e i profondi investimenti di Amazon e Google rendono queste partnership strategiche, non solo commerciali. ### 6. La piattaforma di agenti emergente Sempre più, Anthropic vende non solo semplici chiamate al modello ma **infrastruttura per agenti** — servizi gestiti dove Anthropic esegue il loop dell'agente e ospita l'ambiente in cui gli agenti svolgono le attività. Man mano che più clienti passano da "fare una domanda al modello" a "far fare il lavoro a un agente", questo livello superiore diventa un nuovo punto per catturare valore al di là del nucleo di pagamento per token. ## Anthropic è redditizia? Anthropic è privata e non pubblica bilanci certificati, ma il quadro pubblico è lo stesso dei suoi pari: **i ricavi crescono estremamente velocemente**, mentre l'azienda spende enormi somme in calcolo (addestramento e inferenza dei modelli) e talenti nella ricerca. Come altri laboratori di IA di frontiera, si trova in una fase di investimento intenso in cui la crescita dei ricavi, non il profitto attuale, è il titolo di riferimento. La scommessa che fanno gli investitori è che i ricavi basati sull'utilizzo continuino a moltiplicarsi man mano che l'IA si integra in sempre più software, superando infine il costo del calcolo. ## Come si confronta con OpenAI Le strutture sono simili — entrambe monetizzano tramite abbonamenti consumer, un'API basata sull'utilizzo, licenze enterprise e strumenti per sviluppatori. Le differenze riguardano l'enfasi e le partnership: Anthropic punta fortemente sull'API sviluppatori/enterprise ed è supportata da Amazon e Google; OpenAI ha una presenza consumer più ampia e una profonda partnership con Microsoft. Se vuoi l'altro lato del confronto, leggi [come guadagna OpenAI](https://alejandrorioja.com/how-does-openai-make-money/). ## Modello di ricavi di Anthropic — FAQ 2026 ### Qual è la principale fonte di ricavi di Anthropic? L'**API basata sull'utilizzo** e i **contratti enterprise** sono i principali motori. Sviluppatori e aziende pagano per token per chiamare Claude, e le organizzazioni acquistano piani per utente per i loro team. L'abbonamento Claude consumer è il prodotto più visibile ma una fetta più piccola dei ricavi rispetto alle linee di business. ### Come funziona la tariffazione dell'API di Claude? Paghi per token — input e output misurati in porzioni di testo. I modelli più capaci (Opus) costano di più per token rispetto a quelli equilibrati (Sonnet) o veloci (Haiku), e i token in output costano più di quelli in input. Funzionalità come il contesto lungo, il prompt caching e l'elaborazione in batch hanno la propria tariffazione. I ricavi scalano direttamente con quanto i clienti utilizzano i modelli. ### Anthropic è quotata in borsa? No. Anthropic è un'azienda privata supportata da investitori strategici e di capitale di rischio, tra cui Amazon e Google. Le sue azioni non sono disponibili sulle borse valori pubbliche e non vi è alcuna IPO confermata. ### Anthropic guadagna con l'app Claude gratuita? Non direttamente dagli utenti gratuiti — il livello gratuito è un funnel. Il denaro arriva quando gli utenti gratuiti fanno upgrade a **Pro** o **Max**, quando i team acquistano **licenze enterprise** e soprattutto quando gli sviluppatori costruiscono sull'**API**. Il compito dell'app gratuita è la portata e il brand; i livelli a pagamento e l'API sono dove converte. ### Chi sono i maggiori clienti di Anthropic? Principalmente altre aziende: società software che integrano Claude nei loro prodotti tramite API, e imprese che distribuiscono Claude ai propri dipendenti. La distribuzione tramite marketplace cloud attraverso AWS, Google e Microsoft attrae anche grandi clienti enterprise che acquistano tramite i loro provider cloud esistenti. **Letture correlate:** [Come guadagna OpenAI](https://alejandrorioja.com/how-does-openai-make-money/) · [La guida per principianti agli agenti AI](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Come essere citato nelle risposte di ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## La versione breve Anthropic affitta l'accesso ai suoi modelli Claude. Gli sviluppatori pagano per token tramite l'API, i consumatori pagano mensilmente per Pro e Max, le aziende pagano per licenza per Team e Enterprise, gli ingegneri usano Claude Code con gli stessi piani, e i giganti del cloud (AWS, Google, Microsoft) rivendono Claude alle imprese tramite i loro marketplace. È un business B2B con una porta d'ingresso consumer — e il contatore, non l'app di chat, è dove si trova il denaro. --- ## Come guadagna OpenAI? Il modello di business di ChatGPT e delle API Source: https://alejandrorioja.com/it/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAI guadagna in quattro modi principali: abbonamenti a ChatGPT (Plus, Pro, Team, Enterprise, Edu), un'API a consumo in cui gli sviluppatori pagano per token, grandi contratti aziendali e la partnership con Microsoft (distribuzione più un accordo di condivisione dei ricavi). A differenza della maggior parte dei laboratori di IA, il business degli abbonamenti consumer di OpenAI è la sua principale linea di ricavi — la scala di ChatGPT è il motore. ## Table of contents _Aggiornato a giugno 2026._ **TL;DR:** OpenAI guadagna in quattro modi principali: **abbonamenti a ChatGPT** (Plus, Pro, Team, Enterprise, Edu), un'**API a consumo** in cui gli sviluppatori pagano per token, grandi **contratti aziendali** e la **partnership con Microsoft** (distribuzione più un accordo di condivisione dei ricavi). A differenza della maggior parte dei laboratori di IA, il business degli abbonamenti consumer di OpenAI è la sua principale linea di ricavi — l'enorme scala di ChatGPT è il motore. **[Nota per gli operatori]** OpenAI è l'inverso di una tipica azienda di IA enterprise: ha prima costruito un fenomeno consumer e poi un business per sviluppatori e aziende. I centinaia di milioni di utenti di ChatGPT sono sia il marchio che la macchina per generare cassa. Tutti gli altri in questo spazio vorrebbero avere quel tipo di imbuto di acquisizione iniziale. ## Cos'è OpenAI? OpenAI è la società di ricerca sull'IA dietro **ChatGPT** e la famiglia di modelli **GPT**, oltre a prodotti come il modello video Sora, la generazione di immagini e l'agente di programmazione Codex. Fondata nel 2015, ha raggiunto la notorietà di massa quando ChatGPT è stato lanciato alla fine del 2022 ed è diventato uno dei prodotti consumer a più rapida crescita della storia. La sua struttura è insolita: è nata come organizzazione no-profit e ha creato un ramo a scopo di lucro con limite di profitto per raccogliere l'enorme capitale che richiede l'addestramento di modelli all'avanguardia. Non è quotata in borsa e ha una profonda partnership pluriennale con **Microsoft** che fornisce calcolo, distribuzione e capitale. Il prodotto, come per qualsiasi laboratorio di IA, è intelligenza come servizio — venduta attraverso canali consumer, sviluppatori e aziendali. ## Come guadagna OpenAI? ### 1. Abbonamenti a ChatGPT (la linea di ricavi più grande) Questo è ciò che distingue OpenAI dai suoi concorrenti. ChatGPT è gratuito, con livelli a pagamento che convertono una parte della sua enorme base di utenti in ricavi ricorrenti: - **ChatGPT Plus** — una quota mensile fissa per l'accesso ai migliori modelli, limiti più alti e funzionalità premium. Il livello per il mercato di massa. - **ChatGPT Pro** — un livello di prezzo più alto per gli utenti avanzati che desiderano il massimo utilizzo e le impostazioni del modello più performante. - **ChatGPT Team** — piani per posto per le piccole imprese, con spazi di lavoro condivisi e strumenti di amministrazione. - **ChatGPT Enterprise** — per le grandi organizzazioni: sicurezza avanzata, conformità, SSO, contesto più ampio e garanzie di utilizzo. - **ChatGPT Edu** — una versione pensata per università e scuole. Poiché ChatGPT raggiunge centinaia di milioni di utenti settimanali, anche un tasso di conversione a singola cifra bassa verso i piani a pagamento produce un enorme business di abbonamenti. Questa scala consumer è il vantaggio distintivo di OpenAI e gli abbonamenti sono, secondo quanto riportato, la sua maggiore fonte di ricavi. ### 2. Le API (a consumo, per sviluppatori) Sviluppatori e aziende integrano i modelli di OpenAI nei propri prodotti e pagano **per token** — per ogni porzione di testo (o immagine o audio) elaborata. I prezzi scalano con la capacità del modello: i modelli di ragionamento di punta costano di più per token rispetto a quelli più piccoli, veloci ed economici, e l'output ha un prezzo più alto dell'input. Le API trasformano ogni azienda che sviluppa su GPT in un cliente misurato la cui fattura cresce con il proprio utilizzo. È la stessa dinamica di composizione su cui si basa ogni laboratorio di IA: una startup che integra OpenAI e scala a milioni di utenti genera più ricavi API ogni mese senza nessun nuovo contratto. ### 3. Contratti aziendali Oltre alle API self-service e ai piani Team, OpenAI stipula grandi accordi personalizzati con grandi aziende — utilizzo in volume, capacità dedicata, supporto personalizzato e impegni di sicurezza e conformità. Questi sono ricorrenti, si espandono nel tempo e diventano difficili da sostituire una volta che un'azienda costruisce flussi di lavoro critici sui modelli. Questo movimento enterprise affianca il business consumer ed è un'importante area di crescita. ### 4. La partnership con Microsoft Microsoft è il principale partner strategico di OpenAI. Il rapporto funziona su più assi: - **Calcolo** — Il cloud Azure di Microsoft fornisce gran parte dell'infrastruttura su cui OpenAI addestra e serve i modelli. - **Distribuzione** — I modelli di OpenAI sono offerti attraverso le piattaforme di Microsoft (servizi IA di Azure, prodotti Copilot), mettendo GPT davanti alla gigantesca base di clienti enterprise di Microsoft. - **Condivisione dei ricavi** — Le due società condividono i ricavi nell'ambito del loro accordo commerciale, e Microsoft ha investito massicciamente in OpenAI. Questa partnership è in parte capitale, in parte go-to-market: dà a OpenAI accesso ad aziende a cui ci vorrebbero anni per vendere direttamente. ### 5. Prodotti nuovi e adiacenti OpenAI continua ad espandere la superficie che può monetizzare: - **Codex** — il suo strumento di programmazione agentivo, monetizzato attraverso abbonamenti e utilizzo dell'API (e un driver di elevato consumo di token). - **Sora** — generazione di video, offerta all'interno dei livelli a pagamento e come prodotto a sé stante. - **Generazione di immagini e altre modalità** — incluse negli abbonamenti e misurate tramite API. - **Un ecosistema sviluppatori e agenti** — GPT personalizzati, una piattaforma di agenti e strumenti che consentono alle aziende di costruire sui modelli di OpenAI. Ognuno di questi è un ulteriore involucro attorno allo stesso asset centrale, mirato a catturare più di quello che gli utenti e gli sviluppatori sono disposti a pagare. ## OpenAI è redditizia? OpenAI è privata e non pubblica bilanci certificati. Il quadro ampiamente riportato: **i ricavi sono molto grandi e crescono rapidamente**, ma lo sono anche i costi — addestrare modelli all'avanguardia e servire centinaia di milioni di utenti consuma quantità sbalorditive di calcolo. Come i suoi concorrenti, OpenAI si trova in una fase di investimento intensivo in cui la priorità è la crescita e la capacità, non il profitto a breve termine. La scommessa è che la scala più la crescente adozione da parte delle aziende alla fine superi i costi di calcolo. ## Confronto con Anthropic I blocchi costruttivi sono simili — abbonamenti consumer, un'API a consumo, accordi aziendali, strumenti di programmazione — ma l'enfasi è diversa. Il vantaggio distintivo di OpenAI è la **scala consumer** (ChatGPT) e la sua partnership con **Microsoft**; Anthropic punta di più sull'**API per sviluppatori e aziende** ed è sostenuta da Amazon e Google. Per l'altro lato del confronto, leggi [come guadagna Anthropic](https://alejandrorioja.com/how-does-anthropic-make-money/). ## Modello di ricavi di OpenAI — FAQ 2026 ### Qual è la maggiore fonte di ricavi di OpenAI? **Gli abbonamenti a ChatGPT.** Poiché ChatGPT raggiunge centinaia di milioni di utenti, i suoi livelli a pagamento (Plus, Pro, Team, Enterprise, Edu) costituiscono la principale linea di ricavi di OpenAI — un profilo insolito per un laboratorio di IA, la maggior parte dei quali guadagna di più da API e aziende che dai consumatori. ### Come generano ricavi le API di OpenAI? Gli sviluppatori pagano **per token** per utilizzare i modelli di OpenAI nelle proprie app — per ogni porzione di testo, immagine o audio elaborata. I modelli più performanti costano di più per token, e l'output ha un prezzo più alto dell'input. I ricavi crescono automaticamente man mano che cresce l'utilizzo dei clienti. ### OpenAI è quotata in borsa? Posso comprare azioni OpenAI? No. OpenAI è un'azienda privata e le sue azioni non sono disponibili nelle borse pubbliche. La maggior parte delle persone non può investire direttamente. Microsoft detiene una quota importante attraverso la sua partnership, ma questo non equivale a un'IPO di OpenAI. ### Come fa la partnership con Microsoft a portare denaro a OpenAI? Microsoft fornisce il calcolo Azure, distribuisce i modelli di OpenAI attraverso i suoi prodotti e la sua cloud a un'enorme base di clienti enterprise, e le due società condividono i ricavi nell'ambito del loro accordo commerciale. Microsoft ha anche investito massicciamente in OpenAI. È sia una fonte di finanziamento che un canale di distribuzione. ### OpenAI guadagna dagli utenti gratuiti di ChatGPT? Non direttamente — il livello gratuito è un imbuto. I ricavi arrivano quando gli utenti gratuiti passano a **Plus** o **Pro**, quando le aziende acquistano posti **Team** o **Enterprise**, e quando gli sviluppatori costruiscono sull'**API**. Il ruolo del prodotto gratuito è la portata; i livelli a pagamento e le API la convertono. **Lettura correlata:** [Come guadagna Anthropic](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Come guadagna SpaceX](https://alejandrorioja.com/how-does-spacex-make-money/) · [La guida per principianti agli agenti IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## La versione breve OpenAI converte l'enorme base di utenti di ChatGPT in ricavi da abbonamento (Plus, Pro, Team, Enterprise), addebita agli sviluppatori per token tramite la sua API, stipula grandi contratti aziendali e si affida a Microsoft per calcolo, distribuzione e ricavi condivisi. La sua caratteristica distintiva è la scala consumer — la maggior parte dei laboratori di IA monetizza prima gli sviluppatori; OpenAI ha costruito un fenomeno consumer e un business alle sue spalle. --- ## Come Guadagna SpaceX? Lanci, Starlink e la Questione dell'IPO Source: https://alejandrorioja.com/it/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceX guadagna in tre modi: servizi di lancio (vendita di posti in orbita su razzi Falcon riutilizzabili), Starlink (internet via satellite per consumatori, imprese, marittimo/aviazione e governi) e contratti governativi (equipaggio e cargo NASA, moduli di atterraggio lunare, lanci di sicurezza nazionale). Starlink è ora il principale motore di ricavi. SpaceX rimane privata; un IPO di SpaceX in sé non è imminente, sebbene uno spin-off futuro di Starlink sia da tempo nell'aria. ## Table of contents _Aggiornato giugno 2026._ **TL;DR:** SpaceX guadagna in tre modi: **servizi di lancio** (vendita di posti in orbita su razzi Falcon riutilizzabili), **Starlink** (internet via satellite per consumatori, imprese, marittimo/aviazione e governi) e **contratti governativi** (equipaggio e cargo NASA, moduli di atterraggio lunare, lanci di sicurezza nazionale). Starlink è ora il principale motore di ricavi. SpaceX rimane privata; un IPO di SpaceX in sé non è imminente, sebbene uno spin-off futuro di Starlink sia da tempo nell'aria e ripetutamente ridimensionato. **[Lettura dell'operatore]** SpaceX è l'esempio moderno più chiaro di un'azienda che ha usato un vantaggio tecnologico in hardware duro (razzi riutilizzabili) per costruirci sopra un business con economie software (internet via satellite). Il business dei lanci si guadagna il diritto di esistere; Starlink è dove sta il denaro ricorrente e scalabile. Questa è tutta la storia in una frase. ## Cos'è SpaceX SpaceX (Space Exploration Technologies Corp.) progetta, costruisce e fa volare razzi e veicoli spaziali, e gestisce la rete internet via satellite Starlink. Fondata nel 2002 con l'obiettivo a lungo termine di rendere l'umanità multiplanetaria, è diventata il principale fornitore di lanci al mondo facendo qualcosa che nessun altro aveva fatto su larga scala: atterrare e riutilizzare il primo stadio di un razzo orbitale, riducendo drasticamente il costo di accesso allo spazio. Questo vantaggio di costo è il motore di tutto il resto. Lanci economici, frequenti e affidabili sono ciò che rende economicamente possibile una costellazione di oltre 7.000 satelliti — e la costellazione è ciò che trasforma un business di lanci discontinuo e basato su progetti in uno a ricavi ricorrenti. ## Come guadagna SpaceX? ### 1. Servizi di lancio Il business originale. SpaceX vende lanci a tre tipi di clienti: - **Operatori di satelliti commerciali** — aziende che hanno bisogno di un carico utile in orbita pagano per un lancio dedicato o un posto su una missione **rideshare** (molti piccoli satelliti su un unico razzo, con prezzo al chilogrammo). - **Governo e militari** — carichi utili per la sicurezza nazionale e missioni scientifiche, spesso con un premio per affidabilità e garanzie. - **Altre aziende spaziali** — inclusi, sempre più, concorrenti che dipendono ancora da SpaceX perché è il passaggio più economico e disponibile. L'economia unitaria funziona grazie alla **riutilizzabilità**: lo stesso propulsore del primo stadio vola molte volte, quindi il costo marginale di un lancio è ben al di sotto del prezzo. Il Falcon 9 è il cavallo di battaglia; il Falcon Heavy gestisce i carichi più pesanti. ### 2. Starlink (la macchina dei ricavi ricorrenti) Starlink è una costellazione di migliaia di satelliti in orbita bassa terrestre che fornisce internet ad alta velocità in luoghi che la banda larga terrestre non può raggiungere o non serve. È ora la parte di SpaceX che assomiglia a un vero business in abbonamento, con diversi livelli: - **Consumatore** — le famiglie pagano per un'antenna (hardware) più un abbonamento mensile. - **Impresa e mobilità** — piani a prezzo più alto per aziende, settore marittimo (navi, yacht) e **aviazione** (accordi Wi-Fi in volo con compagnie aeree). - **Governo** — incluso **Starshield**, la variante orientata alla difesa venduta a clienti militari e governativi. - **Direct-to-cell** — partnership con operatori mobili per fornire connettività satellite direttamente ai telefoni comuni nelle zone senza copertura. Starlink combina vendite di hardware (il terminale) con ricavi mensili ricorrenti (l'abbonamento) tra milioni di abbonati — la classica forma rasoio-e-lame, su scala planetaria. Ecco perché la maggior parte delle stime ora colloca Starlink davanti ai lanci come principale linea di ricavi di SpaceX. ### 3. Contratti governativi Un segmento distinto e molto grande che si sovrappone ai lanci ma che vale la pena separare: - **NASA** — SpaceX trasporta astronauti alla Stazione Spaziale Internazionale nell'ambito del programma **Commercial Crew** (Crew Dragon) e la rifornisce con **Cargo Dragon**. Ha anche vinto un contratto per costruire un sistema di atterraggio lunare basato su **Starship** per le ambizioni lunari della NASA. - **Sicurezza nazionale** — contratti di lancio ricorrenti per carichi utili della difesa e dell'intelligence. Questi contratti sono ad alto valore, pluriennali, e finanziano gran parte dello sviluppo che beneficia il settore commerciale. ### 4. Starship (il motore del futuro, non ancora un centro di profitto) Starship è il veicolo di lancio super-pesante completamente riutilizzabile di SpaceX — il sostituto a lungo termine del Falcon e la chiave sia per le missioni lunari/su Marte che per la prossima generazione più grande di satelliti Starlink. Oggi è un centro di costi finanziato dagli altri tre business. Se raggiungerà voli di routine, abbatterà di nuovo drasticamente il costo dei lanci e consentirà un dispiegamento di Starlink molto più ampio — questa è la scommessa che gli investitori stanno effettivamente facendo. ## SpaceX è redditizia? SpaceX è privata e non pubblica bilanci certificati, quindi qualsiasi cifra precisa è una stima. Il quadro ampiamente riportato: i lanci sono redditizi per missione grazie alla riutilizzabilità, e Starlink è passato in territorio di flusso di cassa positivo man mano che la sua base di abbonati è cresciuta. L'azienda reinveste enormi somme nello sviluppo di Starship, quindi il "profitto" dipende in larga misura da come si tratta quella R&S. La direzione di marcia — ricavi Starlink ricorrenti in crescita su un business di lanci dominante — è ciò che sostiene l'enorme valutazione privata dell'azienda. ## La questione dell'IPO Questa è la parte che tutti chiedono, quindi ecco la versione onesta. **Non ci si aspetta che SpaceX faccia un IPO presto.** Elon Musk ha detto ripetutamente che preferisce tenere SpaceX privata mentre Starship e il programma su Marte sono intensivi di capitale e a lungo orizzonte — la pressione trimestrale del mercato pubblico non si adatta a una missione di decenni. Invece, SpaceX fornisce liquidità ai dipendenti e ai primi investitori tramite **offerte periodiche di vendita** (l'azienda facilita la vendita di azioni a un prezzo fisso), il che consente alle persone di incassare senza una quotazione pubblica. Queste vendite secondarie sono ciò che produce le cifre di valutazione nei titoli — SpaceX è stata valutata centinaia di miliardi di dollari nei recenti round. **Un IPO spin-off di Starlink è nell'aria da tempo** — lo stesso Musk suggerì anni fa che Starlink avrebbe potuto eventualmente andare in borsa una volta che i suoi ricavi fossero stati stabili e prevedibili. Ma ha anche ripetutamente raffreddato le aspettative sui tempi a breve termine. A partire dal 2026, Starlink non ha fatto un IPO e non c'è una data confermata. Trattate qualsiasi titolo con "data IPO Starlink" con scetticismo a meno che non provenga dall'azienda stessa. ## Conclusione Il modello di SpaceX è uno stack: il lancio riutilizzabile crea un vantaggio di costo, quel vantaggio rende Starlink economicamente possibile, Starlink trasforma il tutto in un business a ricavi ricorrenti, e i contratti governativi finanziano il lavoro di frontiera (Starship) che azzera di nuovo la curva dei costi. Rimane privata per scelta, usando offerte di vendita invece di un IPO — e il percorso più probabile verso i mercati pubblici è una futura quotazione di Starlink, non SpaceX nel suo insieme, quando l'azienda deciderà che i tempi sono maturi. ## Modello di ricavi di SpaceX — FAQ 2026 ### Qual è la principale fonte di ricavi di SpaceX? La maggior parte delle stime ora colloca **Starlink** davanti ai servizi di lancio come principale linea di ricavi di SpaceX, trainata da milioni di abbonamenti di consumatori, imprese, mobilità e governo più le vendite di hardware terminale. I servizi di lancio rimangono grandi e altamente redditizi per missione, ma il modello ricorrente di Starlink scala più velocemente. ### SpaceX è quotata in borsa? Posso comprare azioni SpaceX? No. SpaceX è una società privata e le sue azioni non sono disponibili sulle borse pubbliche. La maggior parte delle persone non può investire direttamente; l'accesso è generalmente limitato a dipendenti e investitori accreditati che partecipano a round privati o offerte di vendita. Diffidate delle offerte di "azioni SpaceX" che suggeriscono diversamente. ### SpaceX o Starlink faranno un IPO? Non ci si aspetta che SpaceX vada in borsa nel breve termine — Musk ha detto di volerla tenere privata durante la fase intensiva di capitale di Starship/Marte. Un IPO di **Starlink** è stato discusso per anni come una possibilità una volta che i suoi ricavi fossero prevedibili, ma a partire dal 2026 non c'è una data confermata. Qualsiasi affermazione specifica di "data IPO" dovrebbe essere trattata con scetticismo a meno che non provenga dall'azienda. ### Come guadagna Starlink? Starlink addebita ai clienti un'antenna satellitare (hardware) più un abbonamento mensile, su livelli consumer, business, marittimo, aviazione e governo — incluso il Starshield orientato alla difesa e le partnership con operatori direct-to-cell. È un modello rasoio-e-lame: hardware in anticipo, ricavi ricorrenti dopo. ### Come la riutilizzabilità aiuta i profitti di SpaceX? Atterrare e rifar volare lo stesso propulsore di razzo molte volte riduce il costo marginale di ogni lancio ben al di sotto del prezzo addebitato. Questo vantaggio di costo è ciò che rende SpaceX il fornitore di lanci più economico e ciò che rende economicamente praticabile il dispiegamento di una costellazione Starlink di diverse migliaia di satelliti. **Lettura correlata:** [Come guadagna Uber](https://alejandrorioja.com/how-does-uber-make-money/) · [Come guadagna Shopify](https://alejandrorioja.com/how-shopify-makes-money/) · [Come guadagna PayPal](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## La versione breve SpaceX vende posti in orbita a basso costo perché riutilizza i suoi razzi, poi usa quel vantaggio di costo per gestire Starlink — un business in abbonamento per internet via satellite che ora è il suo principale generatore di ricavi — mentre i contratti governativi finanziano lo Starship di nuova generazione. Rimane privata volutamente; un IPO di Starlink, non di SpaceX, è il percorso eventuale più probabile verso i mercati pubblici. --- ## Come usare le attività pianificate di Claude: automatizza i lavori ricorrenti con cron Source: https://alejandrorioja.com/it/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: Le attività pianificate trasformano un prompt Claude una-tantum in un lavoro ricorrente: si avvia secondo un programma tipo cron, svolge il lavoro e consegna il risultato. Usa l'app Claude per i prompt personali ricorrenti (un digest mattutino, un riepilogo settimanale) e le routine di Claude Code o i deployment di Managed Agents per l'automazione degli sviluppatori che gira nel cloud. Il vantaggio sta nell'automatizzare il lavoro che altrimenti faresti a mano ogni giorno o ogni settimana. ## Table of contents _Aggiornato giugno 2026._ **TL;DR:** Le attività pianificate trasformano un prompt Claude una-tantum in un lavoro ricorrente: si avvia secondo un programma tipo cron, svolge il lavoro e consegna il risultato. Usa l'**app Claude** per i prompt personali ricorrenti (un digest mattutino, un riepilogo settimanale) e le **routine di Claude Code** o i **deployment di Managed Agents** per l'automazione degli sviluppatori che gira nel cloud. Il vantaggio sta nell'automatizzare il lavoro che altrimenti rifaresti a mano ogni giorno o ogni settimana. **[Lettura per operatori]** Le automazioni a leva più alta non sono appariscenti — sono i piccoli lavori ricorrenti che consumano silenziosamente 20 minuti al giorno. Un'attività pianificata è il modo per delegarli a Claude una volta sola e non pensarci mai più. Ne eseguo diverse: una scansione mattutina dei concorrenti, un controllo notturno dello stato dei PR, una bozza settimanale della pipeline di contenuti. Nessuna ha richiesto più di dieci minuti per essere configurata. ## Cos'è un'attività pianificata Una normale sessione Claude è sincrona: scrivi, risponde, sei presente. Un'**attività pianificata** è asincrona e ricorrente: definisci un prompt (o un intero workflow di agente) più un programma, e Claude lo esegue da solo — alle 7 di ogni giorno feriale, ogni lunedì, ogni ora — e ti consegna il risultato quando ha finito. Sotto il cofano è un cron job con un LLM al centro. Non stai scrivendo codice per collegare API; stai descrivendo il risultato in linguaggio naturale e lasciando che l'agente scopra i passaggi ogni volta che si avvia. ## I tre posti dove le configurerai Non c'è un unico pulsante — ci sono tre superfici, adatte al tuo profilo. ### 1. L'app Claude (per tutti) Le app Claude per consumatori supportano le attività ricorrenti: salvi un prompt e una cadenza, Claude lo esegue secondo il programma e ti notifica con il risultato. Questo è il percorso senza codice — ideale per un briefing giornaliero, una ricerca ricorrente, un lavoro "riepiloga le mie newsletter non lette ogni mattina". Se non sei uno sviluppatore, inizia da qui. ### 2. Routine di Claude Code (per chi vive nel terminale) Se usi **Claude Code**, puoi pianificare un prompt o uno slash command in modo che venga eseguito con cadenza cron come agente cloud — una "routine". Gira lato server sul tuo repository o workspace, quindi funziona anche quando il laptop è chiuso. Usi tipici: monitorare le pull request aperte, eseguire un passaggio notturno di lint-e-fix, generare una bozza di post ogni mattina per la revisione. Definisci il programma e il compito; Claude Code gestisce l'avvio e il registro delle esecuzioni. ### 3. Deployment di Managed Agents (per sviluppatori che costruiscono prodotti) Per i team che sviluppano sulla Claude API, i **deployment pianificati** eseguono un agente secondo un programma cron ricorrente — ogni avvio crea una sessione che svolge il lavoro in modo autonomo (una scansione notturna di conformità, un rapporto settimanale, un monitor orario). Ottieni un registro di esecuzione per ogni avvio per verificare successi e fallimenti. Questa è la versione programmatica e di livello produzione della stessa idea. ## Come pensare al programma Tutti e tre usano lo stesso modello mentale — **quale compito, quanto spesso, cosa fare con il risultato**: 1. **Il compito** — scrivilo come scriveresti qualsiasi buon prompt per agente: ruolo, contesto, azione esatta, vincoli e una verifica. Un'attività pianificata non può farti una domanda di chiarimento a metà esecuzione, quindi deve essere *completamente specificata in anticipo*. Questa è la differenza più grande rispetto all'uso interattivo. 2. **La cadenza** — giornaliera, settimanale, oraria, solo giorni feriali, un orario specifico nel tuo fuso orario. Adattala alla velocità con cui la cosa sottostante cambia effettivamente; un digest "giornaliero" di una fonte aggiornata settimanalmente sono esecuzioni sprecate. 3. **La consegna** — dove arriva il risultato (una notifica, un file, un messaggio, una bozza). Decidilo in anticipo così l'output è utile nel momento in cui arriva. ## Pattern che davvero convengono - **Il digest mattutino.** "Ogni giorno feriale alle 7, recupera le ultime notizie su [argomenti], riepiloga le tre cose che contano e mandami un brief di 5 punti." Sostituisce 20 minuti di scansione manuale. - **Il rapporto settimanale.** "Ogni lunedì, compila [metriche] in un riepilogo di una pagina con cosa è cambiato e perché." Trasforma un'incombenza ricorrente in una revisione. - **Il lavoratore notturno.** Una routine di codice che esegue un lavoro lungo e ben specificato mentre dormi — un refactoring, una sessione di test, una pulizia dei dati — così ti svegli con un risultato da revisionare. - **Il monitor.** "Ogni ora, controlla [cosa]; scrivimi solo se [condizione] è vera." Le migliori automazioni sono per lo più silenziose e parlano solo quando conta. ## Consigli di configurazione dall'uso in produzione - **Sovra-specifica il prompt.** Nessuna domanda di chiarimento è possibile a metà esecuzione. Indica il formato, le fonti, i vincoli e cosa fare nei casi limite. - **Inizia con un test manuale.** Esegui il prompt esatto una volta a mano. Se produce quello che vuoi in modo interattivo, pianificalo. Se no, correggi prima il prompt — pianificare un prompt sbagliato produce solo risultati sbagliati in modo affidabile. - **Adatta la cadenza alla frequenza di cambiamento.** Non eseguire orariamente qualcosa che si aggiorna settimanalmente. - **Mantieni gli output come bozze quando la posta in gioco è alta.** Per qualsiasi cosa che esce nel mondo — un post pubblicato, un'email inviata — fai in modo che il compito produca una *bozza* per la tua revisione, non un'azione in tempo reale. Riserva il completamente autonomo "fallo e basta" per il lavoro a basso rischio e reversibile. - **Osserva le prime esecuzioni.** I lavori pianificati alla lunga si sfasano — una fonte cambia formato, un feed si azzittisce. Controlla i primi record di esecuzione, poi fidati. ## Attività pianificate Claude — FAQ 2026 ### Cosa sono le attività pianificate di Claude? Sono lavori ricorrenti: definisci un prompt o un workflow di agente più un programma tipo cron, e Claude lo esegue automaticamente — quotidianamente, settimanalmente, ogni ora — consegnando il risultato senza che tu sia alla tastiera. Esistono nelle app Claude per consumatori (per i prompt personali ricorrenti), in Claude Code (come routine cloud) e nella Claude API (come deployment di Managed Agents). ### Devo essere uno sviluppatore per usarle? No. L'app Claude supporta le attività ricorrenti senza codice — solo un prompt salvato e una cadenza. Le routine di Claude Code e i deployment di Managed Agents sono le versioni rivolte agli sviluppatori per automatizzare i workflow di codice e prodotto. ### In cosa si differenzia un'attività pianificata da una normale chat Claude? Una chat normale è interattiva — sei lì per rispondere alle domande di follow-up. Un'attività pianificata è autonoma e ricorrente, quindi il prompt deve essere completamente specificato in anticipo; Claude non può fermarsi per farti una domanda a metà esecuzione. Si avvia secondo il programma, completa il lavoro e ti consegna il risultato. ### Qual è una buona prima attività pianificata? Un digest mattutino. "Ogni giorno feriale alle 7, riepiloga le ultime notizie su [i tuoi argomenti] in cinque punti." È a basso rischio, facile da verificare e sostituisce immediatamente un'incombenza manuale ricorrente — il modello perfetto per imparare il workflow prima di automatizzare qualcosa di più grande. ### Un'attività pianificata può eseguire azioni reali, come inviare email? Sì, ma sii deliberato. Per il lavoro reversibile e a basso rischio, lasciala agire. Per qualsiasi cosa rivolta all'esterno o difficile da annullare, fai in modo che il compito produca una bozza che approvi piuttosto che agire automaticamente — specialmente nelle esecuzioni non presidiate. La reversibilità è il test giusto per capire quanta autonomia concedere. **Letture correlate:** [La guida per principianti agli agenti IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Come guadagna Anthropic](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Come essere citati nelle risposte di ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **Vuoi un sistema di agenti pianificati che gestisca il tuo lavoro ricorrente?** È esattamente quello che costruisco — [mettiti in contatto](https://alejandrorioja.com/contact/). --- ## La Matematica dei Costi degli Agenti IA: Quando Haiku Batte Sonnet (e Quando No) Source: https://alejandrorioja.com/it/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Scegliere Claude Haiku al posto di Sonnet può ridurre drasticamente il costo per chiamata, ma solo quando il task tollera un tasso di successo inferiore. La metrica reale non è il costo per chiamata — è il costo per risultato riuscito, inclusi i ritentativi e la pulizia umana. Faccio il routing per task, non per default. ## Indice dei contenuti _Aggiornato giugno 2026._ **TL;DR:** Scegliere Claude Haiku al posto di Sonnet può ridurre il costo per chiamata di un ordine di grandezza, ma solo quando il task tollera il tasso di successo inferiore di Haiku. La metrica che conta è il **costo per risultato riuscito** — costo della chiamata più ritentativi più pulizia umana — non il prezzo di listino per token. Faccio il routing per task, e una quota significativa dei miei step ad alto volume gira su Haiku mentre le decisioni di giudizio restano su Sonnet. **Lettura dell'operatore:** Gestisco oltre 100 agenti, e l'inferenza è una voce di costo reale. Ma ho visto team "risparmiare" forzando tutto sul modello più economico per poi pagare il conto in ritentativi, escalation e clienti arrabbiati. La matematica dei costi funziona solo quando misuri l'intero funnel. Il modello più economico non è quello con il prezzo per token più basso. È quello con il costo totale più basso per fare il lavoro nel modo giusto. Questi sono numeri diversi, e il divario tra loro è esattamente dove la maggior parte delle decisioni di costo sugli agenti va storta. ## L'economia dei token, detta chiaramente Anthropic tariffa Claude per milione di token, con input e output fatturati separatamente, e l'output che costa diverse volte di più dell'input. I numeri esatti cambiano nel tempo, quindi controlla i prezzi attuali di Anthropic — ma è la **struttura** a guidare la decisione: - **Haiku** è il livello economico e veloce — di gran lunga il costo per token più basso della famiglia. - **Sonnet** sta nel mezzo — nettamente più costoso di Haiku, nettamente più economico di Opus. - **Opus** è il livello premium per il ragionamento più difficile. Ne seguono due cose. Primo, i token di output dominano il costo nei task generativi, quindi un modello prolisso costa di più anche allo stesso prezzo per token. Secondo, il divario di prezzo per token tra Haiku e Sonnet è abbastanza grande da farsi notare assolutamente sul conto in uno step ad alto volume. Questo è l'argomento *a favore* di Haiku. Ora l'argomento contro. ## La metrica che conta davvero: il costo per risultato riuscito Il costo per chiamata è un numero di vanità. Ecco la formula che uso davvero: ``` costo_per_successo = (costo_chiamata × tentativi) + costo_pulizia ÷ tasso_di_successo ``` Dove `tentativi` tiene conto dei ritentativi, e `costo_pulizia` è il costo atteso di un umano che corregge i fallimenti che sfuggono. Guarda cosa fa questo al confronto. Supponi che Haiku costi circa un decimo di Sonnet per chiamata. Se Haiku riesce nell'80% dei casi su un task e Sonnet nel 98%, il risparmio per chiamata sembra enorme. Ma se ogni fallimento di Haiku innesca un ritentativo e 1 su 10 richiede comunque un umano che costa denaro reale, il termine di pulizia può inghiottire il risparmio sui token. Su un task a basso rischio e alto volume la matematica favorisce Haiku in modo schiacciante. Su un task dove un fallimento manda un'email al cliente sbagliato, può ribaltarsi completamente. Non puoi prendere questa decisione senza misurare il tasso di successo per modello — che è esattamente ciò che ti dà un [harness di valutazione](/the-eval-harness-i-use-to-ship-ai-agents/). Esegui lo stesso set di valutazione contro entrambi i modelli e leggi i tassi di successo sulla stessa unità di misura. ## Dove Haiku vince in modo deciso Haiku è la scelta giusta quando il task è **circoscritto, strutturato e verificabile**: - **Classificazione e routing** — "questo messaggio in arrivo è una prenotazione, un reclamo o spam?" Tre categorie, facile da verificare, gira di continuo. Haiku tutto il giorno. - **Estrazione con uno schema** — tirare fuori una data, un nome, un importo da un testo, validato con Zod. Se l'output viene parsato, è quasi certamente corretto. - **Riscritture brevi e formattazione** — aggiustamenti di tono, riassumere un input noto come buono, normalizzare dati. - **Filtraggio di prima passata** — Haiku fa il triage, e solo i casi ambigui vengono escalati a Sonnet. Questo è il pattern a maggior leva. Il filo conduttore: il costo di un errore di Haiku è basso e l'errore è economico da individuare. Quando la verifica è economica e il rischio è basso, vince il modello economico. ## Dove Sonnet si guadagna il suo prezzo Sonnet (e a volte Opus) vale la pena quando il task è **aperto, multi-step o costoso da sbagliare**: - **Loop di agente multi-strumento** dove una chiamata sbagliata a uno strumento si propaga a cascata. Una maggiore affidabilità di ragionamento si compone attraverso gli step — i pattern di orchestrazione che tratto in [orchestrazione multi-agente](/multi-agent-orchestration-patterns-queues-state-handoffs/) si basano sul fatto che il modello non perda il filo. - **Generazione rivolta al cliente** dove un output scadente costa fiducia, non solo un ritentativo. - **Qualsiasi cosa dove la verifica sia di per sé difficile.** Se non puoi dire a basso costo se l'output è corretto, non puoi permetterti un modello che sbaglia di frequente. Un fallimento qui non costa un ritentativo — costa un rimborso, un cliente perso, o il mio tempo. A fronte di questo, il sovrapprezzo per token è un errore di arrotondamento. ## La regola di routing che metto davvero in produzione Non scelgo un modello per agente. Faccio il routing per **task** all'interno dell'agente, di solito con un classificatore economico che decide quale modello a valle gestisce il lavoro: ```typescript function pickModel(task: Task): string { // Economico, verificabile, alto volume → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // Aperto o rivolto al cliente → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // di default, la scelta sicura } ``` Qui sono codificati due principi. **Di default il modello sicuro**, non quello economico — ottimizzi il costo *verso il basso* da una base che funziona, mai l'affidabilità *verso l'alto* da una rotta. E **escala, non scommettere**: lascia che Haiku gestisca l'80% facile e affida il 20% difficile a Sonnet. Quell'ibrido batte quasi sempre l'esecuzione di tutto su uno solo dei due modelli. C'è anche il prompt caching da aggiungere sopra: se il tuo prompt di sistema è grande e riutilizzato, il caching riduce sostanzialmente il costo di input indipendentemente dal livello, il che a volte rende Sonnet abbastanza economico da rendere irrilevante la questione di Haiku. ## Un esempio concreto dal mio stack Prendi uno step di triage di messaggi in arrivo ad alto volume. Gira migliaia di volte, il task è una classificazione a tre vie, e un errore significa solo che l'elemento finisce in una coda di revisione — economico da individuare, basso rischio. È un task da manuale per Haiku, e spostarlo da Sonnet ha ridotto significativamente il costo di quello step senza impatto misurabile sul risultato che contava. Ora prendi lo step che redige la risposta vera al cliente. Volume più basso, aperto, e una bozza scadente che esce costa fiducia. Quello resta su Sonnet. Stesso agente, due modelli, indirizzati per rischio. Tengo d'occhio il costo per esecuzione e le metriche di successo di entrambi, nel modo in cui descrivo in [come misuro se un agente IA sta davvero funzionando](/how-i-measure-whether-an-ai-agent-is-actually-working/) — e abbasso uno step di un livello solo dopo che la valutazione dice che il modello più economico mantiene il tasso di successo. ## FAQ ### Claude Haiku è sempre più economico di Sonnet nella pratica? Per token, sì — con ampio margine. Per risultato riuscito, non sempre. Se il tasso di successo inferiore di Haiku innesca ritentativi e pulizia umana, il costo totale può superare quello di Sonnet sui task dove gli errori sono costosi da individuare o correggere. ### Come decido tra Haiku e Sonnet per un dato task? Valuta il task su due assi: quanto è verificabile l'output e quanto è costoso un errore. Il lavoro economico da verificare, a basso rischio e alto volume va a Haiku; il lavoro aperto, rivolto al cliente o difficile da verificare va a Sonnet. Fai il routing per task, non per agente. ### Qual è l'unica metrica di costo che dovrei monitorare? Il costo per risultato riuscito — costo della chiamata per tentativi più costo di pulizia atteso, diviso il tasso di successo. Il prezzo per chiamata da solo nasconde ritentativi e tempo umano, ed è lì che i modelli economici diventano costosi senza che te ne accorga. ### Posso usare entrambi i modelli in un solo agente? Sì, e di solito dovresti. Il pattern più forte è una prima passata economica (Haiku classifica o filtra) che escala a Sonnet solo i casi ambigui. Quell'ibrido in genere batte l'esecuzione di tutto su un singolo livello. --- ## Come Debuggare un Agente IA in Produzione (Guida sul Campo) Source: https://alejandrorioja.com/it/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Debuggare un agente IA in produzione consiste soprattutto nell'isolare quale livello ha fallito — prompt, strumento, modello o orchestrazione. Registro ogni passo con un ID di traccia, riproduco gli input esatti e biseco. Nei miei agenti, ~70% dei 'bug dell'IA' si rivelano bug di idraulica, non del modello. ## Indice dei contenuti _Aggiornato giugno 2026._ **TL;DR:** Debuggare un agente IA in produzione consiste soprattutto nell'isolare quale livello ha fallito — prompt, chiamata a strumento, output del modello o orchestrazione. Registro ogni passo con un ID di traccia, riproduco gli input esatti e biseco da lì. Nei miei agenti, circa il 70% di ciò che sembra un "bug dell'IA" si rivela idraulica: un risultato di strumento malformato, un input troncato, un'eccezione silenziosamente ingoiata. **Lettura dell'operatore:** Gestisco oltre 100 agenti in produzione — flussi di prenotazione per Pickleland, pipeline di contenuti, smistatori di posta in arrivo. Si rompono come si rompe ogni software, più qualche modo nuovo. Questa è la guida sul campo che avrei voluto avere: come trovare il livello che fallisce senza fissare un muro di token. Quando un agente si comporta male in produzione, l'istinto è incolpare il modello. "Claude ha allucinato." A volte è vero. Di solito no. Il modello è un livello in uno stack di cinque o sei, e il bug è molto più spesso nel livello che hai scritto tu che in quello spedito da Anthropic. Questo articolo è il modo sistematico con cui lo trovo. ## Rendi ogni esecuzione tracciabile prima di debuggare qualsiasi cosa Non puoi debuggare ciò che non puoi vedere. La cosa a più alto rendimento che puoi fare — prima che spunti qualsiasi bug specifico — è agganciare un ID di traccia a ogni esecuzione dell'agente e registrare ogni passo che compie. Un "passo" è qualsiasi cosa che attraversa un confine: il trigger in entrata, ogni chiamata al modello (con l'array completo dei messaggi), ogni chiamata a strumento (con gli argomenti), ogni risultato di strumento e l'output finale. Registrali come JSON strutturato indicizzato dall'ID di traccia. ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` Su Cloudflare Workers li invio a una coda e in una tabella; in locale vanno su stdout. La regola è assoluta: se un passo non è registrato, non è avvenuto per quanto riguarda il debug. Questo rispecchia la strumentazione che descrivo ne [lo stack di agenti che uso](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — l'ID di traccia è la spina dorsale a cui è appeso tutto il resto. ## Isola il livello: prompt, strumento, modello o orchestrazione Una volta che hai una traccia, il debug diventa una bisezione. Ci sono quattro livelli e il bug vive in esattamente uno di essi la maggior parte delle volte. ### 1. Il livello di input (il colpevole più comune) Estrai l'esatto array `messages` che è entrato nella chiamata al modello fallita. Non una ricostruzione — il payload letterale dal log. Poi leggilo come farebbe un estraneo. Metà dei miei bug "il modello ha ignorato le istruzioni" sono in realtà: - Un risultato di strumento tornato come `"[object Object]"` perché qualcosa è stato convertito male in stringa. - Un input troncato a metà frase perché ha fatto esplodere la finestra di contesto e uno slice ingenuo l'ha tagliato. - Una variabile interpolata come `undefined` che ha avvelenato silenziosamente il prompt. Se l'input è sbagliato, il modello ha fatto il suo lavoro alla perfezione su spazzatura. Aggiusta l'idraulica. ### 2. Il livello degli strumenti Se l'input sembra pulito, controlla se uno strumento ha restituito un errore che l'agente ha trattato come successo. Un classico: un'API restituisce `200` con un corpo `{ "error": "rate limited" }`, il tuo wrapper dello strumento non controlla il corpo, e l'agente agisce con sicurezza su un messaggio di errore. Registra i risultati degli strumenti grezzi e verifica la loro forma. ### 3. Il livello del modello Solo dopo aver escluso 1 e 2 sospetto del modello. Anche allora, "bug del modello" di solito significa "il mio prompt è ambiguo." Prendi l'input esatto fallito, mettilo in uno script estemporaneo contro lo stesso modello e temperatura, e vedi se si riproduce. Se sì, la soluzione è lavoro sul prompt o una [eval più stringente](/the-eval-harness-i-use-to-ship-ai-agents/), non un cambio frenetico di modello. ### 4. Il livello di orchestrazione Se un singolo passo è a posto in isolamento ma l'esecuzione multi-passo fallisce, il bug è nel passaggio di consegne — stato perso tra i passi, una race condition, un retry che ha rieseguito un'azione non idempotente. Questi sono i più insidiosi e copro i pattern in [pattern di orchestrazione multi-agente](/multi-agent-orchestration-patterns-queues-state-handoffs/). ## Riproduci il non-determinismo invece di combatterlo Ciò che fa sembrare gli agenti impossibili da debuggare è il non-determinismo: lo stesso input produce output diversi tra le esecuzioni. Puoi domarlo. Primo, **fissa ciò che puoi.** Imposta `temperature: 0` durante il debug. Non renderà Claude completamente deterministico, ma restringe nettamente la varianza così puoi distinguere un bug reale dal rumore di campionamento. Secondo, **eseguilo N volte.** Se un fallimento si riproduce 1 volta su 20, ripeti l'input esatto 50 volte e cattura ogni output. Ora hai un campione, non un aneddoto. Un bug che scatta il 5% delle volte è un bug reale — ti serve solo volume per vederlo. ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # poi conta i fallimenti grep -c '"status":"fail"' runs.jsonl ``` Terzo, **confronta le esecuzioni che passano e quelle che falliscono.** Con la temperatura fissata e lo stesso input, una differenza nell'output significa una differenza nell'input che non hai ancora individuato — un timestamp nel prompt, un risultato di strumento che varia, un documento recuperato che è cambiato. ## Costruisci un harness di replay per smettere di debuggare in produzione Debuggare ri-attivando l'agente dal vivo è lento e rischioso — invia email reali, prenota campi reali. Invece, cattura la traccia e riproducila offline. L'harness di replay carica una traccia registrata, ricostruisce gli input esatti di qualsiasi passo e riesegue solo quel passo contro il modello. Poiché hai registrato l'array completo `messages`, non hai affatto bisogno del sistema a monte. Questo trasforma un viaggio di andata e ritorno di 10 minuti in produzione in un ciclo locale di 2 secondi, ed è la più grande accelerazione nel mio flusso di debug. Un buon harness di replay ti permette anche di **mutare e rieseguire**: cambia una riga del prompt di sistema, riproduci le stesse 50 tracce fallite e vedi quante passano ora. Questo è il ponte dal debug all'eval — una volta che hai un corpus di tracce fallite, hai l'inizio di una suite di regressione. ## Tieni d'occhio le metriche che davvero predicono le rotture Alcuni fallimenti non lanciano mai un'eccezione. L'agente gira, restituisce qualcosa di plausibile e fa silenziosamente la cosa sbagliata. Per catturare quelli osservi metriche comportamentali, non solo tassi di errore: - **Tasso di successo delle chiamate a strumento** per strumento. Un calo qui spesso precede un fallimento visibile. - **Validità dello schema di output** — quale % di output fa il parsing rispetto alla struttura attesa. Valido ogni output con Zod e allerto quando la validità cala. - **Lunghezza del ciclo** — numero medio di passi per esecuzione. Un picco improvviso di solito significa che l'agente è bloccato a riprovare. - **Costo per esecuzione** — un ciclo fuori controllo si mostra come un picco di costo prima di mostrarsi come un reclamo. (Quando il costo conta, vale la pena conoscere la [matematica Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet).) Traccio queste come traccio tutto il resto — vedi [come misuro se un agente IA funziona davvero](/how-i-measure-whether-an-ai-agent-is-actually-working/). La metrica che cattura un fallimento silenzioso vale dieci che catturano quelli rumorosi. ## La checklist di triage di 5 minuti Quando un agente si rompe e sono contro il tempo, eseguo questo in ordine: 1. **Ottieni l'ID di traccia** dell'esecuzione fallita. 2. **Leggi l'input esatto** del passo fallito. È ben formato? (Risolve ~50% dei casi qui.) 3. **Controlla i risultati degli strumenti** in quella traccia per errori camuffati da successo. 4. **Riproduci il passo offline** a `temperature: 0`. Si riproduce? 5. **Se si riproduce,** è un problema di prompt/modello — aggiusta e riesegui il corpus di tracce. **Se no,** è non-determinismo o un bug di stato/orchestrazione — ripetilo 50× per caratterizzarlo. L'isolamento disciplinato batte il prompting astuto ogni volta. Il modello è raramente il problema; il sistema attorno ad esso di solito lo è. ## FAQ ### Come debuggo un agente IA che fallisce solo a volte? Cattura l'input esatto da una traccia registrata e riproducilo oltre 50 volte a temperatura 0. I fallimenti intermittenti sono bug reali con bassi tassi di attivazione — il volume trasforma l'aneddoto in un campione riproducibile che puoi confrontare e correggere. ### Il bug è di solito nel modello o nel mio codice? Nei miei agenti di produzione, circa il 70% degli apparenti "bug dell'IA" è idraulica: risultati di strumento malformati, input troncati, eccezioni ingoiate o stato perso tra i passi. Escludi i livelli di input e strumento prima di sospettare del modello. ### Qual è il minimo di logging che mi serve per debuggare gli agenti? Un ID di traccia su ogni esecuzione, più log strutturati del trigger, ogni chiamata al modello (array completo dei messaggi), ogni chiamata a strumento e il suo risultato grezzo, e l'output finale. Se un passo non è registrato, non puoi debuggarlo. ### Come smetto di debuggare contro la produzione dal vivo? Costruisci un harness di replay che carichi una traccia registrata e riesegua qualsiasi singolo passo offline usando gli input catturati. Trasforma un viaggio di andata e ritorno lento e rischioso in produzione in un veloce ciclo locale e diventa il seme della tua suite di regressione. --- ## Come Misurare se la Ricerca con IA ti Sta Davvero Portando Traffico Source: https://alejandrorioja.com/it/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: La maggior parte del traffico della ricerca con IA appare come un rivolo di referral da chatgpt.com, perplexity.ai e claude.ai — ma l'effetto più grande è oscuro: le persone leggono la risposta dell'IA e non cliccano mai. Misuro entrambi, usando i referrer per i clic e l'aumento delle ricerche di brand per l'influenza. ## Indice dei contenuti _Aggiornato a giugno 2026._ **TL;DR:** La maggior parte del traffico della ricerca con IA arriva come un sottile flusso di referral da `chatgpt.com`, `perplexity.ai` e `claude.ai` — facile da contare una volta che sai dove guardare. Ma l'effetto più grande è **oscuro**: le persone leggono la risposta dell'IA, assorbono il tuo brand e non cliccano mai. Traccio i clic con i segmenti di referrer e l'influenza con l'aumento delle ricerche di brand, i cambiamenti del traffico diretto e il monitoraggio delle citazioni. Contare solo i clic sottovaluta gravemente la ricerca con IA. **Lettura dell'operatore:** Gestisco un motore di contenuti e ne controllo le analitiche ogni giorno. La domanda "la ricerca con IA mi sta portando traffico?" ha una risposta frustrante: sì, ma gran parte del valore non appare nel tuo report delle sessioni. Ecco come misuro la parte che appare e deduco quella che non appare. Tutti vogliono un solo numero: "quanto traffico mi sta portando ChatGPT?". La risposta onesta è che la ricerca con IA produce due effetti molto diversi, e servono due misurazioni distinte. Confondili e o andrai nel panico (i clic sembrano minuscoli) o ti illuderai (perderai l'impatto reale). ## Effetto 1: Referral diretti — contabili, e più piccoli di quanto speri Quando qualcuno clicca su una citazione dentro ChatGPT, Perplexity o una risposta di Claude, la tua analitica registra un referrer. Sono sessioni reali e attribuibili. In GA4 o in qualsiasi strumento di analisi, costruisci un segmento che catturi i motori di IA: ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` Salvalo come canale "Ricerca con IA" e osservalo nel tempo. Alcune avvertenze che fregano la gente: - **I referrer si perdono.** Alcune superfici di IA rimuovono o alterano il referrer, quindi una parte dei clic IA genuini finisce in "Diretto". Il tuo conteggio di referral è un pavimento, non la verità. - **Il volume è basso rispetto alle impression della risposta.** I motori di IA rispondono alla domanda sulla pagina; solo la minoranza curiosa clicca. Una manciata di referral giornalieri può corrispondere a molte più persone che ti hanno visto citato. Quindi il segmento dei referral è necessario ma insufficiente. Ti dice che la ricerca con IA sta portando *un po'* di traffico. Sottovaluta gravemente l'influenza. ## Effetto 2: Influenza oscura — la metà più grande e più difficile da vedere L'azione vera è a zero clic. Qualcuno fa una domanda a ChatGPT, il tuo brand appare nella risposta come fonte consigliata, e non clicca mai — si ricorda semplicemente di te. Questo si manifesta più tardi come una **ricerca di brand** o una **visita diretta**, attribuita a niente. È la stessa dinamica che rendeva frustrante misurare i featured snippet, amplificata. Non puoi misurare l'influenza oscura direttamente, ma puoi triangolarla: 1. **Volume delle ricerche di brand.** Traccia le ricerche del tuo nome/brand in Google Search Console nel tempo. Se inizi a essere citato dai motori di IA e le tue impression di brand salgono senza una campagna corrispondente, quell'aumento è un'impronta dell'influenza dell'IA. 2. **Tendenza del traffico diretto.** Un aumento sostenuto delle sessioni "Diretto" che non segue alcuna campagna spesso riflette referral IA privati del loro referrer, più persone che ti digitano dopo una menzione dell'IA. 3. **Conversioni assistite.** Guarda se le sessioni di ricerca con IA, anche se rare, appaiono come *primo* contatto nei percorsi che convertono. Un canale minuscolo all'ultimo clic può essere significativo al primo contatto. Nessuno di questi è un numero pulito. Insieme ti dicono se la metà oscura si sta muovendo. ## Traccia le citazioni, non solo i clic Ecco la metrica che mi interessa di più per la ricerca con IA, e non è affatto nella tua analitica: **vengo citato, e per quali query?** Mantieni una lista delle 20-40 query che contano per la tua attività e passale attraverso ChatGPT, Perplexity e Claude in modo programmato — settimanalmente è più che sufficiente. Registra, per ogni query e motore: sei citato, e in che posizione? Questo è l'equivalente GEO del rank tracking, ed è l'indicatore anticipatore. Le citazioni si muovono *prima* del traffico a valle e dell'aumento di brand, quindi è qui che vedi se il tuo [lavoro GEO per le attività locali](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/) sta funzionando. Ho costruito un piccolo agente che esegue questi controlli e registra i risultati — il tipo di cosa che diventa banale una volta che hai uno stack di agenti. Se preferisci farlo a mano, un foglio di calcolo e una passata settimanale di 30 minuti funziona bene per iniziare. La metodologia rispecchia il mio [test di citazioni ChatGPT vs Google](/chatgpt-search-vs-google-50-term-test/), solo eseguito in continuo invece che una volta sola. ## Costruisci la dashboard: quattro numeri, settimanalmente Non annego nelle metriche. Per la ricerca con IA tengo d'occhio quattro cose e le rivedo settimanalmente: 1. **Sessioni di referral IA** — i clic contabili dal segmento di referrer. Tendenza, non valore assoluto. 2. **Copertura delle citazioni** — % delle mie query tracciate dove sono citato sui tre motori. L'indicatore anticipatore. 3. **Impression di ricerca di brand** — da Search Console, come proxy dell'influenza oscura. 4. **Conversioni provenienti dall'IA** — anche se piccole, se le sessioni IA arrivano mai ad avviare un percorso che converte. Se la copertura delle citazioni sale mentre le sessioni di referral restano piatte, *non* è un fallimento — di solito significa che la metà oscura sta crescendo e il numero delle ricerche di brand dovrebbe seguire. Se la copertura delle citazioni cala, è un avviso anticipato su cui agire prima che si muova qualsiasi numero di traffico. È la stessa disciplina del "misurare l'indicatore anticipatore" che applico agli agenti in [come misuro se un agente di IA funziona davvero](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Cosa fare con i numeri La misurazione è utile solo se cambia ciò che fai. Il playbook: - **Copertura delle citazioni bassa per una query che ti interessa?** È un problema di contenuto + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). La pagina o non esiste, o non è strutturata per l'estrazione, o non è abbastanza autorevole da essere inclusa nella risposta. - **Citato ma senza traffico di referral?** Atteso e va bene — la ricerca con IA sta facendo lavoro di brand, non lavoro di clic. Non "aggiustarlo" inseguendo i clic; punta a essere la fonte citata. - **Referral da un motore ma non dagli altri?** I motori divergono parecchio sulle fonti (ho misurato ~40% di sovrapposizione tra ChatGPT e Google). Essere citato da uno non ti procura gli altri — lavora la copertura di ogni motore separatamente. ## Una nota sull'onestà dell'attribuzione Resisti alla tentazione di rivendicare una precisione che non hai. La misurazione della ricerca con IA nel 2026 è triangolazione, non attribuzione. Chiunque ti venda un numero pulito tipo "ChatGPT ti ha portato X dollari" sta esagerando ciò che è conoscibile, perché i referrer si perdono e l'effetto più grande è a zero clic per progettazione. La postura giusta: conta ciò che puoi contare, osserva i proxy per ciò che non puoi, e prendi decisioni sulla tendenza. La tendenza è affidabile anche quando il numero assoluto non lo è. ## FAQ ### Come vedo il traffico da ChatGPT o Perplexity in GA4? Costruisci un canale/segmento che corrisponda ai domini dei motori di IA — chatgpt.com, chat.openai.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com — come sorgente di sessione. Questo cattura i referral da clic, anche se alcuni vengono ridotti a "Diretto", quindi tratta il conteggio come un pavimento. ### Perché il mio traffico di referral della ricerca con IA è così basso? Perché la ricerca con IA è perlopiù a zero clic — il motore risponde sulla pagina e solo una minoranza clicca. I bassi conteggi di referral spesso coincidono con impression di citazioni molto più grandi. Misura le citazioni e l'aumento delle ricerche di brand per vedere la parte che i referral mancano. ### Qual è il miglior indicatore anticipatore per la ricerca con IA? La copertura delle citazioni: la percentuale delle tue query critiche per l'attività, tracciate, dove sei citato su ChatGPT, Perplexity e Claude. Si muove prima del traffico e dell'aumento di brand, quindi ti dice in anticipo se il tuo lavoro GEO sta funzionando. ### Posso ottenere un'attribuzione esatta dei ricavi dalla ricerca con IA? No, non in modo affidabile nel 2026. I referrer si perdono in Diretto e gran parte dell'impatto è a zero clic per progettazione. Tratta la misurazione della ricerca con IA come triangolazione — conta i clic, osserva i proxy di ricerca di brand e traffico diretto, e decidi sulla tendenza, non su una cifra in dollari falsamente precisa. --- ## Pattern di Orchestrazione Multi-Agente: Code, Stato e Handoff Source: https://alejandrorioja.com/it/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: I sistemi multi-agente affidabili non si basano su prompt ingegnosi — si basano sulla noiosa disciplina dei sistemi distribuiti: code durevoli tra gli agenti, stato tenuto fuori dal modello e handoff idempotenti che sopravvivono ai retry. Il modello è il worker; la coda è la spina dorsale. ## Indice _Aggiornato giugno 2026._ **TL;DR:** I sistemi multi-agente affidabili non si vincono con prompt ingegnosi — si vincono con la noiosa disciplina dei sistemi distribuiti. Metti una **coda** durevole tra gli agenti, tieni lo **stato fuori dal modello** e rendi ogni **handoff idempotente** così che un retry non possa agire due volte. Il modello è il worker; la coda è la spina dorsale. Azzecca questi tre punti e l'orchestrazione smette di fare paura. **Lettura dell'operatore:** La maggior parte dei miei oltre 100 agenti è a singolo step. Quelli che non lo sono — le pipeline che classificano, poi arricchiscono, poi agiscono — sono diventati affidabili solo quando ho smesso di pensare a una "catena di prompt" e ho iniziato a pensare a una "coda di job con worker LLM". Questa è architettura, non prompt engineering. "Multi-agente" suona come se gli agenti si parlassero tra loro. In pratica, la versione affidabile è l'opposto: gli agenti non comunicano direttamente affatto. Lasciano messaggi su una coda e prelevano lavoro da una coda, e l'orchestrazione vive nelle tubature tra di loro. Ecco i pattern che reggono in produzione. ## Pattern 1: Metti una coda durevole tra ogni agente Il primo istinto è chiamare l'agente B direttamente da dentro l'agente A. Non farlo. Le chiamate dirette accoppiano i due: se B è lento, A si blocca; se B fallisce, il lavoro di A è perso; se devi scalare B, non puoi senza toccare A. Invece, A termina il suo lavoro e **accoda un messaggio** per B. B è un worker separato che svuota la coda al proprio ritmo. ```typescript // L'agente A finisce e fa l'handoff via coda — nessuna chiamata diretta a B await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // Il lavoro di A è fatto. B lo preleverà in modo indipendente. ``` Su Cloudflare uso Workers Queues esattamente per questo — le stesse primitive dietro [lo stack di agenti che uso](/the-agent-stack-i-use-to-run-30-production-agents-no-python/). La coda ti dà quattro cose gratis: **buffering** (B può essere down senza perdere lavoro), **retry** (i messaggi falliti vengono riconsegnati), **backpressure** (un picco si accoda invece di far crashare) e **disaccoppiamento** (scala o ridistribuisci B senza toccare A). Ognuna di queste è qualcosa che altrimenti dovresti costruire a mano e sbagliare. ## Pattern 2: Tieni lo stato fuori dal modello, sempre Il bug multi-agente più comune è assumere che il modello ricordi qualcosa tra uno step e l'altro. Non lo fa. Ogni chiamata al modello è stateless; l'unica memoria è ciò che metti nel prompt. Quindi la fonte di verità per "a che punto è questo job nella pipeline" deve vivere in un database, non in una conversazione. Tengo un singolo record di job che ogni agente legge e aggiorna: ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` Ogni agente fa lo stesso ciclo: **leggere** lo stato del job, fare il proprio lavoro, **scrivere** il nuovo stato, accodare lo stage successivo. Il modello non tiene mai lo stato — riceve la porzione rilevante come input e restituisce un risultato. Questo è ciò che rende il sistema riavviabile: se un worker muore a metà job, il record di stato dice ancora esattamente a che punto erano le cose, e il messaggio di coda riconsegnato riprende da lì. Rende anche il debug gestibile, perché la tabella di stato è un record interrogabile del percorso di ogni job — la stessa mentalità di strumentazione di [come misuro se un agente sta funzionando](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Pattern 3: Rendi ogni handoff idempotente Le code garantiscono la consegna *almeno una volta*, non esattamente una volta. Questo significa che un messaggio può essere consegnato due volte — interruzioni di rete, retry, ridistribuzioni. Se l'azione del tuo agente non è idempotente, una doppia consegna agisce due volte: due email di conferma, due prenotazioni, due addebiti. Questa è la classe di bug di orchestrazione più insidiosa, ed è quella che i team scoprono in produzione. La soluzione è rendere le azioni idempotenti con una chiave: ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // Già elaborato oltre questo stage — è una consegna duplicata. Salta. return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` Il controllo dello stage rende l'operazione sicura da eseguire due volte: la seconda consegna vede che il job è già avanzato e non fa nulla. Per gli effetti collaterali esterni (inviare un'email, addebitare una carta), passa una chiave di idempotenza all'API a valle così che *anch'essa* deduplichi. Assumi che ogni messaggio verrà consegnato due volte e progetta in modo che sia innocuo — perché prima o poi accadrà. ## Pattern 4: Orchestratore vs coreografia — scegli deliberatamente Ci sono due modi di cablare il flusso, e la scelta giusta dipende dalla complessità. **Coreografia** (la mia scelta di default): ogni agente conosce solo lo step successivo e lo accoda. Il flusso emerge dalla catena. Semplice, decentralizzata, facile da estendere — aggiungi uno stage inserendo una coda. Lo svantaggio è che nessun singolo posto descrive l'intero flusso, quindi una pipeline complessa può diventare difficile da ragionare. **Orchestrazione** (un coordinatore centrale): un orchestratore possiede il flusso, chiama ogni agente a turno e decide cosa segue in base ai risultati. L'intero flusso vive in un unico posto leggibile e la logica di branching è esplicita. Il costo è un componente centrale che deve essere esso stesso durevole — se lo stato proprio dell'orchestratore non è esternalizzato (Pattern 2), diventa il single point of failure. La mia regola: **coreografia finché il branching non diventa complesso, poi un orchestratore durevole.** Una pipeline lineare a tre stage è coreografia. Un flusso con routing condizionale, fan-out parallelo e join vuole un orchestratore il cui stato vive nel database così da poter riprendere dopo un crash. ## Pattern 5: Fan-out, fan-in senza perdere pezzi Quando un job genera N sotto-task paralleli (arricchire 50 record, riassumere 20 documenti) e devi aspettarli tutti prima di continuare, ti serve un **join**. Il trucco è un contatore nello stato del job: 1. Il padre accoda N messaggi figli e scrive `expected: N, completed: 0` nel record del job. 2. Ogni figlio fa il suo lavoro e **incrementa atomicamente** `completed`. 3. Il figlio che porta `completed` a eguagliare `expected` accoda lo stage successivo. L'incremento atomico è cruciale — senza di esso, due figli che finiscono simultaneamente possono entrambi credere di non essere l'ultimo, e il join non scatta mai. Usa un contatore che il datastore può incrementare atomicamente, o una transazione. Questo pattern ti permette di parallelizzare il costoso centro di una pipeline (spesso lavoro economico per Haiku — vedi la [matematica dei costi Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet)) mantenendo un join pulito alla fine. ## Cosa eviterei Non ti serve un framework di agenti pesante per fare niente di tutto questo. Code, una tabella di stato e chiavi di idempotenza sono primitive che ogni piattaforma ha già. Ho visto team ricorrere a elaborati framework multi-agente per ottenere funzionalità che una coda dà gratis, ed ereditare una scatola nera più difficile da debuggare delle tubature che sostituiva. Inizia con le noiose primitive. Ricorri a un framework solo quando hai sentito un dolore specifico che esso risolve. Il riassunto: gli agenti sono worker stateless, le code sono la spina dorsale durevole, lo stato vive in un database e ogni handoff è sicuro da eseguire due volte. Questo è tutto il gioco. ## FAQ ### Gli agenti dovrebbero chiamarsi direttamente o passare per una coda? Per una coda. Le chiamate dirette accoppiano gli agenti — il fallimento o la lentezza di uno si propaga all'altro, e non puoi scalare o ridistribuire in modo indipendente. Una coda durevole ti dà buffering, retry, backpressure e disaccoppiamento gratis. ### Dove dovrebbe vivere lo stato multi-agente? Fuori dal modello, in un database, come record di job che ogni agente legge e aggiorna. Le chiamate al modello sono stateless, quindi la fonte di verità per il progresso della pipeline deve essere esterna — è questo che rende il sistema riavviabile dopo un crash. ### Come impedisco a un agente di agire due volte sullo stesso job? Rendi gli handoff idempotenti. Controlla lo stage del job prima di agire e non fare nulla se è già avanzato, e passa chiavi di idempotenza alle API esterne. Le code consegnano almeno una volta, quindi assumi che ogni messaggio possa arrivare due volte e progetta in modo che i duplicati siano innocui. ### Mi serve un framework multi-agente? Di solito no. Code durevoli, una tabella di stato e chiavi di idempotenza coprono la maggior parte delle esigenze di produzione con primitive che la tua piattaforma fornisce già. Adotta un framework solo quando incontri un problema concreto che esso risolve in modo unico, non di default. --- ## L'Harness di Eval che Uso per Rilasciare Agenti IA Senza Paura Source: https://alejandrorioja.com/it/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Rilasciare agenti senza paura dipende da una cosa sola: un harness di eval. Un insieme fisso di casi di test valutati, calcolati automaticamente (assertion più un giudice LLM), eseguito prima di ogni modifica al prompt o al modello. Se il punteggio regge, rilasci. Il set di test si costruisce dai fallimenti reali in produzione. ## Indice dei contenuti _Aggiornato giugno 2026._ **TL;DR:** Il motivo per cui posso modificare un prompt o sostituire un modello su un agente in produzione senza trattenere il respiro è una cosa sola: un **harness di eval**. Un insieme fisso di casi di test valutati, calcolati automaticamente — assertion rigide dove posso scriverle, un giudice LLM dove non posso — eseguito prima di ogni modifica. Se il punteggio regge, rilascio. Se cala, no. Il set di test non è sintetico; è costruito dai fallimenti reali in produzione, così ogni bug diventa un test di regressione permanente. **Lettura dell'operatore:** Su oltre 100 agenti, la differenza tra quelli che tocco con sicurezza e quelli di cui ho paura sta nel fatto che abbiano o meno degli eval. Nessun harness di eval significa che ogni ritocco al prompt è una scommessa. Un harness di eval trasforma "credo che questo sia meglio" in "questo è misurabilmente 4 punti migliore e non ha rotto nulla". È tutto lì lo sblocco. Non rilasceresti codice senza test. La gente rilascia agenti senza eval di continuo, poi si chiede perché un "piccolo ritocco al prompt" ha rotto la produzione. Un harness di eval è la suite di test per il software non deterministico. Ecco quello che eseguo davvero. ## Parti da un set di test costruito sui fallimenti reali L'harness vale tanto quanto i suoi casi di test, e i casi migliori vengono dalla produzione, non dalla tua immaginazione. Ogni volta che un agente fallisce sul campo, catturo l'input esatto (registro ogni esecuzione con un trace ID — vedi [come fare il debug di un agente in produzione](/how-to-debug-an-ai-agent-in-production)) e lo trasformo in un caso di eval: ```typescript interface EvalCase { id: string; input: AgentInput; // l'input esatto di produzione expected?: string; // ground truth, quando esiste assertions: Assertion[]; // controlli rigidi che devono passare rubric?: string; // per il giudice LLM, quando l'output è aperto } ``` Due pratiche contano qui. **Attingi dalla produzione**, così i tuoi eval testano ciò che si rompe davvero, non ciò che hai immaginato potesse rompersi. E **copri lo spettro** — il percorso felice, i casi limite, gli input avversariali e gli input vuoti/malformati che causano fallimenti silenziosi. Un set di test di 30-50 casi ben scelti cattura molto più di 500 pigri. Preferisco avere 40 casi che rappresentino ciascuno un reale modo di fallimento piuttosto che mille che testano tutti lo stesso percorso facile. ## Valuta prima con le assertion, poi con un giudice LLM Non ogni output ha bisogno di un modello che lo valuti. Ricorro al valutatore più economico che funzioni. **Assertion rigide** per tutto ciò che è strutturato. L'output si parsa come JSON valido? Contiene il campo richiesto? La data estratta è nell'intervallo? Ha chiamato lo strumento giusto con gli argomenti giusti? Sono deterministiche, gratuite e inequivocabili — scrivine quante più puoi. ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` **Un giudice LLM** per il resto aperto — tono, utilità, "ha davvero risposto alla domanda". Qui dai a un modello l'input, l'output e una rubrica, e gli chiedi di valutare. Due regole mantengono onesto il giudice: rendi la rubrica **specifica** (una scala da 1 a 5 con ancore descritte batte "valuta la qualità"), e usa un **modello forte come giudice** — giudicare è un compito di ragionamento, quindi questo è un punto in cui pago volentieri per Sonnet anche quando l'agente stesso gira su Haiku secondo la [matematica dei costi](/ai-agent-cost-math-when-haiku-beats-sonnet). Una rubrica vaga o un giudice debole ti dà rumore che sembra segnale. ## Esegui l'harness prima di ogni modifica L'harness esiste per rispondere a una domanda: *questa modifica ha reso l'agente migliore o peggiore?* Quindi lo eseguo prima di ogni modifica al prompt, sostituzione di modello o cambio di strumento. ```bash # baseline su main npm run eval -- --suite=booking-agent > baseline.json # fai la modifica, poi riesegui npm run eval -- --suite=booking-agent > candidate.json # confronta npm run eval:diff baseline.json candidate.json ``` Il diff mostra il punteggio aggregato, il passa/fallisce per caso e — cosa cruciale — **quali casi specifici sono regrediti.** Un aggregato che sale mentre tre casi si rompono in silenzio non è un miglioramento; è uno scambio che voglio vedere e approvare, non uno che si insinua. Sorvegliare il diff per caso è come eviti "ho sistemato una cosa, ne ho rotte altre due", il modo di fallimento che fa avere paura alla gente dei propri prompt. ## Imposta un gate di regressione e lascia che blocchi Una volta che ti fidi dell'harness, collegalo al percorso verso la produzione come gate. La mia regola è netta: **una modifica che fa scendere il punteggio sotto la soglia di baseline non si rilascia.** Non "ci guarderò dopo" — è bloccata, esattamente come un test CI fallito. ```typescript const PASS_THRESHOLD = 0.90; // il 90% dei casi deve passare if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` È questo che trasforma gli eval da un optional nella cosa che ti permette di muoverti veloce. Il gate è ciò che rende "rilasciare senza paura" letteralmente vero: lo scenario peggiore per una modifica sbagliata è un'esecuzione di eval in rosso, non un incidente in produzione. E poiché il set di test cresce ogni volta che qualcosa si rompe, il gate diventa più rigido e più protettivo nel tempo, da solo. ## Tieni conto del non-determinismo nella valutazione Una sottigliezza che fa inciampare la gente: lo stesso input può ottenere punteggi diversi tra le esecuzioni perché il modello campiona in modo diverso. Se esegui ogni caso una volta sola, vedrai regressioni fantasma — un caso "rotto" che in realtà è solo rumore di campionamento. Due mitigazioni. Esegui gli eval a **`temperature: 0`** per ridurre la varianza (non la eliminerà del tutto). E per i casi che hai visto vacillare, **eseguili N volte e prendi il tasso di successo**, non un singolo passa/fallisce. Un caso che passa 9 su 10 è in forma migliore di uno che passa 5 su 10 anche se entrambi possono mostrare una singola esecuzione verde. È lo stesso principio del volume-sull'aneddoto che uso quando faccio [il debug di fallimenti intermittenti](/how-to-debug-an-ai-agent-in-production) — un'esecuzione è un'opinione, cinquanta esecuzioni sono dati. ## Chiudi il ciclo con il monitoraggio in produzione L'harness di eval testa contro casi noti. La produzione ne lancia di inediti. Quindi il ciclo è: monitora il comportamento dal vivo, cattura un nuovo modo di fallimento, trasformalo in un caso di eval, sistemalo, e ora è protetto in modo permanente. Il lato del monitoraggio — tracciare il tasso di successo, la validità dell'output e il costo per esecuzione sul traffico dal vivo — è ciò che copro in [come misuro se un agente IA funziona davvero](/how-i-measure-whether-an-ai-agent-is-actually-working/). Eval e monitoraggio sono due metà dello stesso sistema: il monitoraggio trova i bug, gli eval si assicurano che restino morti. Quel ciclo di feedback è il vero prodotto. Qualsiasi singolo set di eval invecchia; un *processo* che converte ogni fallimento in produzione in un test permanente si rafforza ogni settimana. È così che un agente passa da "spaventoso da toccare" a qualcosa che rifattorizzo un venerdì pomeriggio senza battere ciglio. ## FAQ ### Cosa entra in un set di eval per un agente IA? Input reali di produzione trasformati in casi valutati — percorso felice, casi limite, input avversariali e malformati — ciascuno con assertion rigide e, per gli output aperti, una rubrica per il giudice LLM. Da 30 a 50 casi tratti da fallimenti reali battono centinaia di casi sintetici che testano tutti il percorso facile. ### Dovrei usare un LLM per valutare gli output dell'agente? Usa assertion rigide ovunque l'output sia strutturato (JSON valido, campo corretto, chiamata allo strumento giusto) — sono gratuite e deterministiche. Riserva un giudice LLM per qualità aperte come tono e utilità, con una rubrica specifica e un modello giudice forte così ottieni segnale, non rumore. ### Come impedisco a una modifica del prompt di rompere la produzione in silenzio? Esegui l'harness di eval prima di ogni modifica e fai il diff contro una baseline, sorvegliando le regressioni per caso, non solo il punteggio aggregato. Poi vincola i deploy al risultato così che ogni modifica che scende sotto la soglia di baseline venga bloccata come un test fallito. ### Come gestisco il non-determinismo negli eval? Esegui a temperatura 0 per ridurre la varianza, e per i casi che vacillano, eseguili più volte e valuta il tasso di successo invece di una singola esecuzione. Un caso che passa 9 volte su 10 è più sano di uno che passa 5 su 10, anche se una singola esecuzione li mostra entrambi verdi. --- ## Come Automatizzare la tua Newsletter con un Agente IA Source: https://alejandrorioja.com/it/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: Un agente Claude legge la mia coda di contenuti, sceglie l'angolazione più forte della settimana, bozza una newsletter con la mia voce, segmenta la lista per livello di coinvolgimento e pianifica l'invio tramite l'API di Kit — tutto senza che io apra un editor. Revisiono un'anteprima renderizzata e clicco su approva. Il lavoro creativo difficile è mio; l'esecuzione meccanica è dell'agente. ## Indice _Aggiornato giugno 2026._ **TL;DR:** Un agente Claude legge la mia coda di contenuti, sceglie l'angolazione più forte della settimana, bozza una newsletter con la mia voce, segmenta la lista per livello di coinvolgimento e pianifica l'invio tramite l'API di Kit — tutto senza che io apra un editor. Revisiono un'anteprima renderizzata e clicco su approva. Il lavoro creativo difficile è mio; l'esecuzione meccanica è dell'agente. **[Lettura dell'operatore]** Una newsletter che invia in modo consistente supera una che è "migliore" ma che viene inviata quando arriva l'ispirazione. Il vincolo era il carico di esecuzione, non le idee. Avevo idee; non avevo la larghezza di banda per formattarle, pianificarle e segmentarle ogni settimana. L'agente ha eliminato quel divario. ## Il vero collo di bottiglia nella maggior parte dei workflow di newsletter La maggior parte dei consigli sull'automazione delle newsletter si concentra sulla cosa sbagliata: sequenze di benvenuto, automazioni, logica di tagging. Va bene, ma non risolve il problema di creazione settimana per settimana. Il vero problema è questo: sai cosa vuoi dire, ma sedersi per formattarlo, scrivere le varianti della riga dell'oggetto, scegliere il segmento giusto e pianificarlo al momento giusto costa 2-3 ore di cambio di contesto a settimana. Moltiplicato per 52 settimane, hai trascorso un'intera settimana lavorativa solo a *inviare* newsletter. L'agente gestisce ogni passaggio dopo "so qual è l'angolazione di questa settimana." ## Lo stack che sto usando - **[Kit](/recommends/convertkit)** (già ConvertKit) — la piattaforma email. Eccellente API, solido tagging degli iscritti, analisi pulita. L'API compatibile con gli agenti è ciò che mi ha convinto. - **Claude (Anthropic SDK)** — il livello di generazione - **Cloudflare Workers** — trigger pianificato (si esegue ogni martedì alle 8 CT) - **Airtable** — coda di contenuti e casella di approvazione Se non sei su Kit, lo stesso schema funziona con qualsiasi piattaforma che abbia un'API REST per creare e pianificare trasmissioni. ## Passo 1: La coda di contenuti L'agente ha bisogno di una fonte di verità su "di cosa stiamo scrivendo." La mia è una tabella [Airtable](/recommends/airtable) con colonne: - `Topic` — l'angolazione o la domanda - `Status` — Queue / Approved / Sent - `Tier` — se questo è per tutti gli iscritti o solo per quelli più coinvolti - `Notes` — qualsiasi vincolo (evitare questo tono, includere questo link, ecc.) Ogni settimana, passo 10 minuti ad aggiungere 2-3 argomenti alla coda. Questo è il mio contributo creativo. Il resto è il lavoro dell'agente. ## Passo 2: L'agente di bozza ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## Passo 3: Il passaggio di approvazione L'agente crea la trasmissione nello stato di bozza di Kit e contrassegna il record Airtable come "Approved." Kit mi invia una notifica con un link di anteprima. Clicco su di esso, lo leggo, e se sembra giusto, confermo l'invio. Se voglio modifiche, modifico direttamente in Kit. Questo è il cancello che impedisce all'agente di essere completamente autonomo sull'email in uscita. Mi fido delle bozze circa il 90% delle volte. Il 10% che rilevo nella revisione — un tono leggermente sbagliato, una statistica che voglio verificare, un link che voglio aggiungere — vale i 3 minuti di revisione. ## Cosa gestisce l'agente che non voglio mai più fare - Scrivere varianti della riga dell'oggetto e scegliere la migliore - Formattare il testo del preheader - Calcolare il tempo di invio corretto (il mio pubblico apre il giovedì mattina; l'agente lo sa) - Segmentare correttamente in base al livello dell'argomento - Registrare tutto in Airtable in modo da avere un archivio ## Cosa possiedo ancora L'*idea*. L'argomento nella coda è mio. L'angolazione è mia. L'agente è un ottimo esecutore di un brief chiaro; non è un livello strategico. Se metto un argomento sbagliato nella coda, ottengo una newsletter ben scritta su un argomento sbagliato. Anche: il cancello della prima revisione. Ogni singolo invio viene esaminato da me prima di partire. Questo non cambierà. ## La conclusione dell'operatore Se stai spendendo più di un'ora a settimana sulla meccanica della newsletter — formattazione, pianificazione, segmentazione — dovresti automatizzarla. L'API di Kit è pulita, il trigger cron del Worker è solido come una roccia, e la qualità della bozza di Claude è abbastanza alta da permettermi di approvare ~90% delle prime bozze senza modifiche. Costruisci la coda in Airtable, collega il Worker e torna a creare idee invece di eseguire invii. --- ## Come Posizionarsi nella Ricerca IA senza Scrivere un Solo Nuovo Post Source: https://alejandrorioja.com/it/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-06 Tags: GEO, SEO TL;DR: I motori IA citano contenuti che rispondono direttamente alle domande, rivendicano una chiara attribuzione e strutturano la conoscenza in modo da facilitare il recupero. La maggior parte dei post di blog esistenti può essere adattata per soddisfare tutti e tre i criteri con modifiche, non riscritture. Il piano: aggiungere un TL;DR diretto, rafforzare i segnali di entità, aggiungere lo schema FAQ e inviare a llms.txt. Il nuovo contenuto è opzionale; la ristrutturazione non lo è. ## Indice _Aggiornato giugno 2026._ **TL;DR:** I motori IA citano contenuti che rispondono direttamente alle domande, rivendicano una chiara attribuzione e strutturano la conoscenza in modo da facilitare il recupero. La maggior parte dei post di blog esistenti può essere adattata per soddisfare tutti e tre i criteri con modifiche, non riscritture. Il piano: aggiungere un TL;DR diretto, rafforzare i segnali di entità, aggiungere lo schema FAQ e inviare a llms.txt. Il nuovo contenuto è opzionale; la ristrutturazione non lo è. **[Lettura dell'operatore]** Ho applicato questo processo a 341 post esistenti prima di scrivere un singolo nuovo articolo orientato al GEO. Le citazioni in ChatGPT e Perplexity sono aumentate. Il nuovo contenuto ha accelerato i guadagni — ma l'audit del contenuto esistente è stato il mio punto di partenza, e ha reso prima del previsto. ## Perché i motori IA non citano il tuo contenuto esistente Prima di scrivere qualcosa di nuovo, chiediti: perché quello che ho già non viene citato? La risposta non è quasi mai "il contenuto non esiste." Di solito è uno di questi: 1. **Nessuna risposta diretta in cima** — il post seppellisce la risposta nel paragrafo 6 2. **Segnali di attribuzione deboli** — nessuna entità autore chiara, nessuna credenziale nel contenuto 3. **Rumore strutturale** — lunghe introduzioni, sezioni irrilevanti, nessuna gerarchia di titoli chiara 4. **Nessuna Q&A leggibile dalla macchina** — i motori IA preferiscono coppie domanda-risposta strutturate; la maggior parte dei post di blog non le ha 5. **Non in nessun indice leggibile dall'IA** — nessun llms.txt, nessuna sitemap che i crawler trovino Tutti e cinque sono correggibili sul contenuto esistente. Nessuno richiede un nuovo post. ## Il processo di retrofitting in quattro passaggi ### Passaggio 1: Aggiungere un TL;DR diretto nelle prime 100 parole I motori IA fanno qualcosa di analogo a ciò che fai quando scorri — cercano la risposta diretta prima di andare più a fondo. Se il tuo post inizia con una storia, una domanda o una contestualizzazione, il modello potrebbe non leggere mai abbastanza lontano per trovare la tua risposta vera. Soluzione: Aggiungi un blocco **TL;DR** nelle prime 100 parole. Formato: conclusione → perché → vincolo o avvertenza. Da due a quattro frasi. Nessun riempitivo. Esempio prima: > *Ti sei mai chiesto perché alcune aziende sembrano dominare i risultati di ricerca di Google? In questo post, esploreremo le strategie che usano i siti meglio posizionati...* Esempio dopo: > **TL;DR:** Tre cose spostano l'ago per la SEO locale nel 2026: completezza del Profilo Aziendale di Google, coerenza delle citazioni nelle directory e schema strutturato per i tuoi dati NAP. Tattiche come "posta ogni giorno" e "ottieni 100 recensioni in fretta" sono secondarie rispetto a queste tre. Il limite è l'accuratezza del tuo GBP — sistema quello prima. La riscrittura non è più lunga. È solo caricata in avanti. ### Passaggio 2: Rafforzare i tuoi segnali di entità I motori IA costruiscono un grafo della conoscenza. Vogliono sapere: chi ha scritto questo, di cosa si tratta e l'autore è credibile su questo argomento? Per l'entità autore: assicurati che la tua pagina Chi siamo sia collegata da ogni post, il tuo schema autore includa link `sameAs` a LinkedIn e Twitter, e la tua bio autore in ogni post menzioni credenziali specifiche (non "professionista del marketing" — "ha gestito la SEO per tre aziende SaaS da 0 a 100K visitatori mensili"). Per l'entità argomento: usa i termini esatti che il tuo pubblico cerca. Se stai coprendo il "GEO" (ottimizzazione del motore generativo), di' "ottimizzazione del motore generativo" da qualche parte, non solo l'abbreviazione. I modelli usano la co-occorrenza dei termini per classificare il contenuto. ### Passaggio 3: Aggiungere lo schema FAQ a ogni post che risponde a domande Lo schema FAQPage è il tipo di schema di maggiore leva per la citazione GEO perché mappa esplicitamente domanda a risposta in un formato che i modelli possono analizzare direttamente. Prendi le 3–5 domande a cui il tuo post risponde implicitamente e rendile esplicite: ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` Aggiungi questo al `` del tuo post o tramite il campo schema del tuo CMS. Ogni motore IA principale esegue il crawl e analizza questo. ### Passaggio 4: Inviare a llms.txt e all'indice IA della tua piattaforma `llms.txt` è uno standard emergente — un file di testo normale su `tuosito.com/llms.txt` che indica ai crawler IA quale contenuto è di alta qualità e come prioritizzarlo. È analogo a `robots.txt` ma per i LLM. Un llms.txt base: ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` Abbina questo a una sitemap pulita che includa timestamp `lastmod`. I crawler IA danno meno priorità ai contenuti che sembrano obsoleti. ## Come prioritizzare quali post retrofittare Non ogni post vale la pena retrofittare. Concentra il tuo primo passaggio su: 1. **Post che già si posizionano a pagina 1 per una parola chiave in formato domanda** — questi sono i più vicini ad essere citati; hanno solo bisogno della correzione della struttura 2. **Post su argomenti per cui sei verificabilmente credibile** — i motori IA pesano molto l'attribuzione; un post dove le tue credenziali sono rilevanti ottiene un aumento di citazione dai segnali di entità 3. **Post che rispondono direttamente a una domanda vs. post che informano** — "Come fare X" e "Cosa è X" si retrofittano meglio delle listicle o dei pezzi di opinione Usa i dati della tua Search Console: filtra per query che sono domande (come, cosa, perché, modo migliore di). I post in posizione 5–15 per quelle query sono i tuoi migliori candidati al retrofit — sono rilevanti ma non ancora abbastanza vicini al top per essere citati. ## L'errore che fa la maggior parte delle persone Scrivono un nuovo post ottimizzato per la ricerca IA prima di retrofittare il loro archivio esistente. Il nuovo contenuto aiuta, ma i post esistenti hanno età, backlink e storia di crawl dalla loro parte. Un post di tre anni ben strutturato supererà un nuovo post sullo stesso argomento per mesi. Fai prima il retrofit. Scrivi nuovo contenuto dove ci sono lacune genuine — domande a cui i tuoi post esistenti non rispondono affatto. È lì che il nuovo è meglio del vecchio. ## La conclusione dell'operatore Se hai più di 20 post di blog esistenti, il tuo lavoro GEO inizia con audit e retrofit, non con un calendario editoriale. Aggiungi TL;DR, rafforza i segnali di entità, aggiungi lo schema FAQ e invia a llms.txt. Fallo sui tuoi 20 post migliori prima di scrivere qualcosa di nuovo. Vedrai miglioramenti nelle citazioni in settimane, non mesi — e avrai una base di partenza più pulita per misurare se il nuovo contenuto sposta davvero l'ago. --- ## Ho creato una competenza Claude che gestisce i miei annunci Facebook — ecco il codice Source: https://alejandrorioja.com/it/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: Ho creato una competenza Claude che legge il mio account Meta Ads tramite la Graph API, identifica i sotto-performer, riscrive il testo degli annunci nella mia voce di marca e crea nuovi set di annunci senza che io debba toccare Gestione annunci. Il tutto in meno di 300 righe di TypeScript. Il ROI è stato immediato: ho ridotto il tempo settimanale di gestione degli annunci da ~3 ore a circa 20 minuti. ## Indice _Aggiornato giugno 2026._ **TL;DR:** Ho creato una competenza Claude che legge il mio account Meta Ads tramite la Graph API, identifica i sotto-performer, riscrive il testo degli annunci nella mia voce di marca e crea nuovi set di annunci senza che io debba toccare Gestione annunci. Il tutto in meno di 300 righe di TypeScript. Il ROI è stato immediato: ho ridotto il tempo settimanale di gestione degli annunci da ~3 ore a circa 20 minuti. **[Lettura dell'operatore]** Gestisco annunci per Pickleland e per il mio brand di consulenza. Due account, pubblici diversi, affaticamento creativo costante. Passavo i pomeriggi della domenica in Gestione annunci a fare cose che dovrebbe fare un modello. Così l'ho automatizzato. ## Perché ho smesso di gestire manualmente gli annunci Facebook Il lavoro reale di gestione degli annunci Facebook si divide in tre compiti: 1. **Monitoraggio** — verificare quali set di annunci stanno bruciando soldi vs. generandoli 2. **Diagnosi** — capire *perché* qualcosa sta sotto-performando (affaticamento creativo? targeting sbagliato? pagina di destinazione?) 3. **Iterazione** — scrivere nuovo testo, creare nuovi set di annunci, regolare i budget Il compito 1 è meccanico. Il compito 3 è principalmente meccanico (con un vincolo di voce). Il compito 2 richiede giudizio — ed è l'unico che trae vantaggio dall'avere un umano nel ciclo. Una competenza Claude può fare il 1 e il 3. Rivedo i risultati del compito 2 prima che qualsiasi cosa venga pubblicata. Questa è l'architettura su cui mi sono assestato. ## La configurazione della Meta Graph API (questa è la parte noiosa) Prima di qualsiasi codice: è necessario un account Meta Business, un Utente di sistema e un token di accesso permanente. Il portale per sviluppatori di Facebook è ostile ma il percorso è: 1. Creare una **Meta App** su developers.facebook.com (tipo: Business) 2. Aggiungere il prodotto **Marketing API** 3. Nel tuo Portfolio aziendale → Impostazioni → Utenti → Utenti di sistema, creare un utente di sistema e dargli il ruolo `ADVERTISER` sul tuo account pubblicitario 4. Generare un token con questi permessi: `ads_read`, `ads_management`, `business_management` Memorizza il token come `META_ACCESS_TOKEN` e l'ID del tuo account pubblicitario (formato: `act_XXXXXXXX`) come `META_AD_ACCOUNT_ID` nel tuo `.env`. ## La struttura dei file della competenza ``` .claude/skills/fb-ads/ SKILL.md ← istruzioni che Claude legge index.ts ← l'implementazione effettiva dello strumento types.ts ← tipi condivisi ``` Il `SKILL.md` è ciò che dice a Claude quando e come usare la competenza. Il mio dice: ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` Il vincolo "non attivare mai automaticamente" è non negoziabile. Questa competenza crea elementi nello stato IN PAUSA. Rivedo e attivo manualmente. Qualsiasi cosa che tocchi la spesa pubblicitaria in tempo reale necessita di un punto di controllo umano. ## Il codice TypeScript principale (I blocchi di codice rimangono in inglese — viene tradotto solo il testo circostante.) ## Come lo uso quotidianamente La competenza viene invocata da Claude Code (il mio strumento quotidiano). Una tipica sessione del lunedì mattina: ``` > check my ads from the last 7 days ``` Claude esegue `runAdsReport(7)`, formatta i risultati come una tabella, segnala i sotto-performer e chiede se voglio riscritture. Dico di sì. Genera nuovo testo, mi mostra entrambe le versioni fianco a fianco e crea set di annunci IN PAUSA con il nuovo creativo. Li rivedo in Gestione annunci, attivo quelli che mi piacciono e archivio i perdenti. Tempo totale: 20 minuti. Zero pomeriggi della domenica in Gestione annunci. ## Cosa questo non sostituisce La competenza non può dirmi se un problema di adattamento prodotto-mercato si sta travestendo da problema di testo. Se il ROAS è pessimo ovunque, si tratta di un problema di funnel o di offerta, non di titolo. Claude riscriverà fedelmente il testo su un funnel rotto — e le riscritture non lo salveranno. Il passaggio diagnostico è ancora mio. Leggo il report, guardo i dati del funnel e decido se stiamo iterando il creativo o risolvendo qualcosa a monte. L'agente è veloce in tutto *tranne* che in quel giudizio. ## La conclusione dell'operatore Se stai gestendo annunci manualmente e toccando Gestione annunci più di due volte a settimana, stai svolgendo operazioni che dovrebbe fare uno script. La Graph API è ben documentata e il flusso di permessi di Meta, sebbene fastidioso, è una configurazione una tantum. Costruisci la competenza in un pomeriggio. Il ritorno in tempo recuperato si manifesta nella prima settimana. --- ## I 5 Strumenti IA che Uso Davvero per Gestire la Mia Azienda (2026) Source: https://alejandrorioja.com/it/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: Cinque strumenti: Claude (livello operatore + programmazione), Cursor (sviluppo TypeScript), Airtable (spina dorsale dei dati per tutti gli agenti), Kit (newsletter + automazione email) e Cloudflare Workers (hosting degli agenti). Tutto il resto che ho provato è stato sostituito da uno di questi o eliminato completamente. Questo è lo stack che ricostruirei se dovessi ricominciare da zero oggi. ## Indice _Aggiornato giugno 2026._ **TL;DR:** Cinque strumenti: Claude (livello operatore + programmazione), Cursor (sviluppo TypeScript), [Airtable](/recommends/airtable) (spina dorsale dei dati per tutti gli agenti), [Kit](/recommends/convertkit) (newsletter + automazione email) e Cloudflare Workers (hosting degli agenti). Tutto il resto che ho provato è stato sostituito da uno di questi o eliminato completamente. Questo è lo stack che ricostruirei se dovessi ricominciare da zero oggi. **[Lettura dell'operatore]** Gestisco due aziende: un brand personale di consulenza IA (alejandrorioja.com) e Pickleland, una struttura di pickleball a Pflugerville, TX. Contesti diversi, pubblici diversi, operazioni diverse. Questi cinque strumenti gestiscono entrambe. Non li elenco perché sono di tendenza; li elenco perché ho eliminato i loro sostituti. ## 1. Claude — il livello operatore Claude (tramite Claude Code e l'Anthropic SDK) è il cervello di tutto ciò che si muove. Lo uso in tre modalità: **Claude Code** è il mio strumento quotidiano di sviluppo. Scrivo TypeScript, costruisco agenti, eseguo debug di problemi infrastrutturali e gestisco contenuti — tutto dall'interfaccia di Claude Code. Non è solo autocompletamento; è un collaboratore che può leggere un file di 500 righe, capire l'intenzione e proporre un refactoring che non avevo considerato. **L'Anthropic SDK** alimenta ogni agente che ho costruito. Il mio agente newsletter, la mia abilità per le inserzioni Facebook, il mio pipeline di contenuti, il mio generatore di carte OG — tutto Claude nel backend. La qualità del modello è abbastanza alta da farmi fidare delle prime bozze circa l'85% delle volte. **Il giudizio di voce e brand di Claude** è sottovalutato. Quando scrivo qualcosa che deve suonare come me, ho scoperto che Claude + un system prompt dettagliato supera ogni altro modello che ho testato. Il trucco è un system prompt specifico e con opinioni — non "scrivi in tono casual" ma "scrivi come Alejandro: diretto, praticante, senza hype, numerato, prima persona, con avvertenze oneste." Pago per Claude Max. È l'abbonamento più utilizzato che ho, e il ROI non è paragonabile. ## 2. Cursor — dove viene scritto il TypeScript Cursor è l'IDE. Sono passato da VS Code circa un anno fa e non ho guardato indietro. Il completamento con tab è abbastanza veloce da cambiare genuinamente come scrivo codice — penso a un'altitudine più elevata e lascio che Cursor gestisca il boilerplate sintattico. La vista diff per i suggerimenti IA è pulita. La finestra di contesto multi-file significa che posso chiedergli di aggiornare una funzione e aggiorna anche i chiamanti. Non uso Cursor per le decisioni architetturali. Le schizzo ancora su carta o in Claude. Ma una volta che il design è chiaro, Cursor è il percorso più veloce dal design al TypeScript funzionante. Il più grande sblocco: Cursor + Claude Code in parallelo. Uso Claude Code per la pianificazione ad alto livello e l'orchestrazione degli agenti; uso Cursor per il lavoro di dettaglio dell'implementazione. Non entrano in conflitto — coprono altitudini diverse. ## 3. Airtable — la spina dorsale dei dati Ogni agente IA che gestisco ha bisogno di un posto da cui leggere e scrivere. Quel posto è [Airtable](/recommends/airtable). Ecco per cosa lo uso in entrambe le aziende: - **Coda di contenuti** — post e argomenti newsletter in corso, con tracciamento dello stato - **Record di prenotazioni** — prenotazioni dei campi Pickleland sincronizzate dal sistema di prenotazione - **Catalogo link affiliati** — oltre 105 slug con metadati che l'agente di contenuti legge al momento della generazione - **Log di audit degli agenti** — cosa è stato eseguito, quando, cosa ha prodotto, eventuali errori L'API è pulita e veloce. Airtable non è un database per carichi di lavoro ad alto throughput — ma per tabelle ausiliarie degli agenti, code di revisione e flussi di lavoro di approvazione con intervento umano, è esattamente lo strumento giusto. L'interfaccia visiva significa che posso ispezionare qualsiasi tabella senza scrivere una query. L'alternativa che ho provato: database Notion. L'API Notion è più lenta e il modello di dati è più goffo per le letture degli agenti. Airtable vince per i dati adiacenti agli agenti. ## 4. Kit — newsletter e automazione email Sono passato a [Kit](/recommends/convertkit) (precedentemente ConvertKit) per un motivo: l'API è davvero buona. La maggior parte delle piattaforme email tratta la propria API come un ripensamento. Kit la tratta come un prodotto di prima classe. Posso creare trasmissioni, pianificare invii, segmentare per tag e leggere analisi — tutto programmaticamente. Il mio agente newsletter fa tutto questo senza che io tocchi il compositore. Cose specifiche di Kit che uso: - **API Broadcasts** — il mio agente crea trasmissioni pianificate programmaticamente ogni settimana - **Tagging degli iscritti** — taggo gli iscritti per comportamento (ha aperto gli ultimi 5 invii = "coinvolto"; non apre da 60 giorni = "a rischio") e il mio agente punta ai segmenti di conseguenza - **Moduli + pagine di destinazione** — puliti, a caricamento rapido, senza codice. Non li manipolo programmaticamente; funzionano e basta. Se sei su Mailchimp o una piattaforma legacy: la migrazione vale la pena. L'API di Mailchimp richiede tre chiamate extra per fare ciò che Kit fa in una. ## 5. Cloudflare Workers — dove vivono gli agenti Ogni agente pianificato viene eseguito su Cloudflare Workers. L'argomento: distribuzione globale all'edge, zero cold start sul livello gratuito e un sistema di trigger cron che funziona davvero. I miei agenti non hanno bisogno di un server. Hanno bisogno di una funzione pianificata che funzioni in modo affidabile, possa fare chiamate API esterne e costi quasi nulla alla mia scala. Workers è la risposta. Cosa ho in esecuzione su Workers: - **Pipeline di contenuti** — genera post EN, si distribuisce su 12 traduzioni, genera carta OG - **Agente newsletter** — bozza e pianifica l'invio settimanale - **Monitor inserzioni Facebook** — legge le prestazioni, segnala i sottoperformanti, mi notifica - **Reporter di occupazione Pickleland** — legge i dati di prenotazione, mi invia un riepilogo giornaliero Costo mensile totale per tutto questo: ~$5. Questo è il piano Workers a pagamento. Gli agenti funzionano in modo affidabile secondo il programma cron; ho avuto un guasto in sei mesi (un problema DNS da parte di Meta, non mio). ## Cosa ho tagliato e perché **Zapier** — sostituito da Workers + le rispettive API di piattaforma direttamente. Zapier aggiunge latenza, costa di più in scala e ha un limite che Workers non ha. **ChatGPT** — la finestra di contesto, l'uso degli strumenti e la qualità del system prompt di Claude sono migliori per il caso d'uso dell'operatore. Mantengo una scheda ChatGPT per ricerche web rapide ma non ci costruisco sopra. **Webflow** — ho spostato il mio sito su Astro + Cloudflare Pages. Più controllo, prestazioni migliori, processo di build contro cui posso programmare. **Grammarly** — Claude fa tutto ciò che Grammarly fa e mantiene meglio la mia voce. ## La conclusione dell'operatore I cinque strumenti sopra non sono i più nuovi o i più discussi. Sono quelli che hanno resistito all'uso quotidiano in produzione in due aziende diverse. Prima di aggiungere un nuovo strumento al tuo stack, chiedi: quale di questi cinque potrebbe fare questo lavoro? Rimarrai sorpreso da quanto spesso la risposta sia "uno di loro può già farlo." --- ## Perché il tuo Agente IA Continua a Fallire in Produzione (E Come Risolverlo) Source: https://alejandrorioja.com/it/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: La maggior parte dei guasti degli agenti in produzione deriva da cinque cause: prompt fragili che non gestiscono i casi limite, logica di retry mancante per errori API transitori, nessuna osservabilità per vedere cosa si rompe, loop incontrollabili senza condizione di uscita e definizioni di strumenti abbastanza ambigue da far scegliere al modello quella sbagliata. Tutti e cinque sono risolvibili senza cambiare modelli o framework. ## Indice _Aggiornato giugno 2026._ **TL;DR:** La maggior parte dei guasti degli agenti in produzione deriva da cinque cause: prompt fragili che non gestiscono i casi limite, logica di retry mancante per errori API transitori, nessuna osservabilità per vedere cosa si rompe, loop incontrollabili senza condizione di uscita e definizioni di strumenti abbastanza ambigue da far scegliere al modello quella sbagliata. Tutti e cinque sono risolvibili senza cambiare modelli o framework. **[Lettura dell'operatore]** Gestisco più di 30 agenti in produzione. Ho avuto tutti questi guasti. Quelli che hanno bruciato più tempo non erano quelli esotici — erano i noiosissimi guasti infrastrutturali che pensavo di aver gestito. ## Guasto 1: Prompt fragili che si rompono su input di casi limite Un prompt che funziona sui tuoi casi di test fallirà su input che non hai anticipato. Non è una limitazione del modello — è un problema di scrittura delle istruzioni. **Sintomi:** L'agente produce output insensato, chiama lo strumento sbagliato o restituisce JSON malformato quando l'input è leggermente diverso da ciò che hai testato. **Causa principale:** Il tuo system prompt descrive solo il percorso felice. Non dice al modello cosa fare quando i dati mancano, sono malformati o ambigui. **Correzione:** Aggiungi gestione esplicita dei casi limite al tuo system prompt: ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` Il modello segue le istruzioni esplicite per i casi limite in modo affidabile. L'errore è presumere che generalizzerà le istruzioni del percorso felice per gestire i casi disordinati. ## Guasto 2: Nessuna logica di retry per errori API transitori Ogni API esterna che il tuo agente chiama fallirà ad un certo punto. L'API di Claude, la Meta Graph API, il tuo database — tutte restituiscono errori 5xx, timeout o rate limit. Se il tuo agente non ha logica di retry, un errore transitorio uccide l'intera esecuzione. **Sintomi:** Le esecuzioni degli agenti falliscono casualmente a diversi passaggi. I log mostrano un 503 o 429 senza tentativo di follow-up. **Correzione:** Avvolgi ogni chiamata esterna in un retry con backoff esponenziale: ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` Tre retry con backoff esponenziale gestisce ~99% dei guasti transitori. Aggiungi questo ad ogni chiamata esterna e metà dei tuoi guasti casuali scomparirà. ## Guasto 3: Nessuna osservabilità — non riesci a vedere cosa si rompe Questa è la modalità di guasto più comune in produzione e quella che costa più tempo nel debug: l'agente fallisce silenziosamente o produce output errato, e non hai idea di dove nella catena sia andato storto. **Sintomi:** Sai che qualcosa non va ma non riesci a identificare il passaggio. Aggiungi istruzioni `console.log` e riesegui manualmente cercando di riprodurre. **Correzione:** Logging strutturato ad ogni passaggio, con un ID di esecuzione che traccia l'intera esecuzione: ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` Se sei su Cloudflare Workers, questi log vanno a Logpush o Workers Tail. Se stai girando localmente o su un VPS, invia a un aggregatore di log. Il JSON strutturato significa che puoi filtrare per `runId` per vedere esattamente cosa è successo in una singola esecuzione. ## Guasto 4: Loop incontrollabili senza condizione di uscita I loop agentici — dove il modello chiama strumenti e itera fino a quando una condizione non è soddisfatta — possono andare avanti all'infinito se quella condizione non viene mai soddisfatta o il modello la identifica erroneamente. **Sintomi:** L'agente spende centinaia di dollari in costi API prima del timeout. O esegue la stessa chiamata allo strumento ancora e ancora senza fare progressi. **Correzione:** Avere sempre un limite di iterazione rigido e un controllo del progresso: ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` Questo cattura sia le modalità di guasto "è andato avanti troppo a lungo" che "ha girato sul posto". Il limite dovrebbe essere abbastanza generoso per il percorso felice ma abbastanza stretto da limitare il raggio di esplosione. ## Guasto 5: Definizioni di strumenti ambigue che il modello risolve in modo errato Se dai al modello due strumenti con descrizioni sovrapposte, a volte chiamerà quello sbagliato. Questo è particolarmente comune con strumenti come `search_database` vs `get_record` o `send_email` vs `create_draft`. **Sintomi:** Il modello chiama la categoria giusta di strumento ma sceglie quello specifico sbagliato. O chiama uno strumento nel contesto sbagliato (usando uno strumento di scrittura quando solo la lettura era appropriata). **Correzione:** Rendi le descrizioni degli strumenti mutuamente esclusive e aggiungi esplicitamente "quando NON usare questo": ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` La clausola "NON usare quando X" è la parte che la maggior parte delle persone salta. È la parte più importante. I modelli sono più bravi a seguire vincoli negativi espliciti che a inferirli da descrizioni positive. ## Ancora una cosa: testa i tuoi agenti su input negativi La maggior parte degli agenti viene testata solo su input puliti del percorso felice. La produzione ha input sporchi: stringhe vuote, campi null, casi limite Unicode, risposte API che restituiscono 200 ma con uno schema inaspettato. Aggiungi una suite di test che eserciti esplicitamente: - Input vuoti o null - Input alla lunghezza massima che ti aspetteresti - Input con caratteri speciali o testo non-ASCII - API esterne che restituiscono forme di risposta inaspettate Se il tuo agente si rompe su uno di questi, correggilo prima che vada in produzione. L'ambiente di produzione troverà ogni ipotesi che hai fatto. ## La conclusione dell'operatore La maggior parte dei guasti degli agenti in produzione sono problemi infrastrutturali che si mascherano da problemi del modello. Prima di cambiare modelli, aggiungi retry, logging strutturato, limiti di loop e gestione esplicita dei casi limite ai tuoi prompt. Correggi le definizioni di strumenti ambigue. Poi testa su input negativi. Fai tutto questo prima di incolpare il modello — nella mia esperienza, il modello di solito è l'ultima cosa che deve cambiare. --- ## Come Costruire il Tuo Primo Agente IA in 15 Minuti Source: https://alejandrorioja.com/it/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-02 Tags: AI Agents TL;DR: Non ti serve un framework, un corso o un dottorato. Ti servono Node.js, l'SDK di Anthropic e 25 righe di TypeScript. Questo tutorial costruisce un agente reale e funzionante — un riassuntore di contenuti strutturato che puoi distribuire su Cloudflare nella stessa sessione. L'unico prerequisito è una chiave API gratuita. ## Indice dei contenuti _Aggiornato giugno 2026._ **TL;DR:** Non ti serve un framework, un corso o un dottorato. Ti servono Node.js, l'SDK di Anthropic e 25 righe di TypeScript. Questo tutorial costruisce un agente reale e funzionante — un riassuntore di contenuti strutturato che puoi distribuire su Cloudflare nella stessa sessione. L'unico prerequisito è una chiave API gratuita. **[Lettura dell'operatore]** La cosa più comune che sento dai fondatori che vogliono automatizzare con l'IA è "prima devo imparare di più". Non è vero. Il pattern dell'agente è semplice, e il modo più veloce per capirlo è costruirne uno. Ecco il percorso esatto che seguirei se ripartissi da zero oggi. ## Perché la maggior parte dei tutorial "costruisci un agente IA" ti delude O usano Python (ottimo per gli ingegneri ML, attrito per tutti gli altri), nascondono il codice reale dietro un framework come LangChain, o costruiscono qualcosa di troppo astratto per collegarlo al tuo lavoro reale. Questo tutorial fa tre cose in modo diverso: 1. **Solo TypeScript** — se hai mai scritto JavaScript, puoi seguire questo 2. **Nessun framework** — vedrai ogni riga di codice che tocca il modello 3. **Un output utile** — costruirai un riassuntore strutturato che puoi davvero usare su email dei clienti, recensioni o note di riunioni ## Cosa stai costruendo Un **agente riassuntore di contenuti**: incolla qualsiasi blocco di testo e ricevi indietro un riassunto strutturato in un formato coerente. Una richiesta HTTP in entrata, un riassunto pulito in uscita. Perché questo come primo progetto: il pattern — prompt di sistema + input dell'utente → output strutturato — è il fondamento di ogni agente che gestisco. Cambia il prompt di sistema e ottieni un risponditore di domande, un riscrittore di tono, un classificatore o un generatore di bozze. Impara questo una volta e avrai imparato l'80% di ciò che gli agenti in produzione fanno davvero. ## Prerequisiti (2 minuti) - **Node.js 18+** — verifica con `node --version`. Installa da nodejs.org se necessario. - **Una chiave API di Anthropic** — registrati su [Claude](/recommends/claude), prendi una chiave dalla console. Il piano gratuito funziona. - Un terminale e un editor di testo. Niente Docker. Niente ambiente virtuale. Niente `pip install` di nulla. ## Passo 1: Creare il progetto (2 minuti) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` Aggiungi uno script a `package.json` così da poter eseguire l'agente facilmente: ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## Passo 2: Scrivere l'agente (5 minuti) Crea `agent.ts` e incolla questo: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## Passo 3: Eseguirlo (1 minuto) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` Output atteso: ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` Questo è un agente IA funzionante. Input reale, prompt di sistema personalizzato, output strutturato. Il tutto è di 30 righe di codice. ## Passo 4: Personalizzalo per il tuo caso d'uso Il prompt di sistema è l'unica cosa che rende questo agente tuo. Ecco tre alternative pronte all'uso: **Classificatore di recensioni dei clienti:** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: