# 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 --- ## Agenti IA con Supervisione Umana: Quando Costruire un Cancello di Approvazione (e Quando No) Source: https://alejandrorioja.com/it/human-in-the-loop-ai-agents-when-to-build-an-approval-gate/ Published: 2026-07-23 Tags: AI Agents, Operations TL;DR: Un cancello di approvazione ha senso quando un errore è costoso, irreversibile o rivolto al cliente — e quando un umano può rilevarlo in tempo. Non ha senso quando il volume è troppo alto per essere esaminato, l'errore è economico da correggere o gli umani approvano senza leggere. Uso quattro domande per decidere, e la maggior parte dei miei 30+ agenti in produzione non ha alcun cancello di approvazione. ## Indice _Pubblicato luglio 2026._ **TL;DR:** Un cancello di approvazione ha senso quando un errore è costoso, irreversibile o rivolto al cliente — e quando un umano può rilevarlo in tempo. Non ha senso quando il volume è troppo alto per essere esaminato, gli errori sono economici da correggere o gli umani approvano senza leggere. Uso quattro domande per decidere, e la maggior parte dei miei 30+ agenti in produzione funziona in modo completamente automatizzato. **Nota dell'operatore:** Gestisco agenti in due aziende — un brand di consulenza e Pickleland, un impianto di pickleball a Pflugerville, TX. All'inizio ho messo cancelli di approvazione ovunque perché sembrava "sicuro." In poche settimane avevo un canale Slack pieno di notifiche che nessuno leggeva, e agenti tecnicamente supervisionati ma praticamente non sorvegliati. È peggio di nessun cancello: l'illusione di supervisione senza la sostanza. Questo articolo spiega come ragiono ora sulla decisione. ## Cosa è realmente un cancello di supervisione umana Nella sua forma più semplice, un cancello di approvazione è una pausa nel flusso di lavoro di un agente dove un umano deve confermare prima che l'agente continui. L'agente crea una bozza di e-mail — un umano la approva prima dell'invio. L'agente segnala una transazione — un umano la esamina prima che il rimborso venga elaborato. Il cancello può essere sincrono (l'agente si blocca fino a quando qualcuno approva) o asincrono (l'agente mette in coda l'azione, invia una notifica, e un umano approva da un pannello o messaggio Slack a suo tempo). L'asincrono è quasi sempre meglio per tutto ciò che non è critico in termini di tempo, poiché i cancelli sincroni creano contropressione nella coda e compromettono le garanzie di affidabilità dell'agente. Cosa un cancello non è: un ciclo di tentativi, una soglia di confidenza o un fallback a un modello più semplice. Questi sono meccanismi di gestione degli errori all'interno dell'agente. Un cancello di approvazione riguarda il giudizio umano che entra nel ciclo — deliberatamente, in un punto specifico, per un motivo. ## Le quattro domande che pongo Prima di aggiungere un cancello, percorro quattro domande. Un "sì" a una qualsiasi è un segnale per considerarne uno. Un "sì" a tutte e quattro significa che il cancello è strutturalmente necessario. **1. L'azione è irreversibile (o costosa da annullare)?** Inviare un'e-mail a 10.000 persone non può essere annullato. Inviare un pagamento non può essere facilmente richiamato. Eliminare un record di database senza backup è permanente. L'irreversibilità è l'argomento più forte per un cancello, poiché l'agente non può annullare ciò che ha fatto. Confrontalo con: etichettare una richiesta in arrivo con una categoria. Se il tag è sbagliato, lo correggi in due clic. Nessun cancello necessario. **2. Se l'agente sbaglia, chi paga?** Un'etichetta interna sbagliata — passo qualche secondo a correggerla. Un'e-mail rivolta al cliente sbagliata — il cliente paga con una brutta esperienza, e io pago con una perdita di fiducia. Una transazione finanziaria sbagliata — pago con denaro reale e potenzialmente rischio di conformità. Gli agenti che influenzano solo i sistemi interni possono tollerare più errori senza un cancello. Gli agenti che toccano clienti o denaro devono guadagnarsi il diritto di funzionare senza supervisione. **3. Un umano può davvero rilevare l'errore prima che conti?** Questa è la domanda che la maggior parte delle persone salta, ed è quella che elimina più cancelli di qualsiasi altra. Se un agente elabora 500 elementi all'ora e ricevi una notifica Slack per elemento, nessuno leggerà tutti i 500. Stai creando affaticamento degli avvisi, non supervisione. Il calcolo è semplice: un cancello aggiunge valore solo se un umano può realisticamente esaminare l'elemento segnalato nella finestra temporale disponibile. **4. Gli umani leggono in modo affidabile ciò che l'agente presenta?** Se la tua coda di approvazione si riempie e le persone approvano senza leggere, il cancello è peggio di nessun cancello — crea falsa fiducia che un umano abbia controllato il lavoro. ## Quando i cancelli hanno chiaramente senso Questi sono i pattern dove aggiungo sempre un cancello, senza eccezioni: - **Comunicazioni esterne irreversibili** — e-mail, SMS, post sui social media che vanno a persone reali. L'agente bozza; un umano invia. In base al volume. - **Azioni finanziarie sopra una soglia** — qualsiasi cosa che sposti denaro ottiene un cancello se è sopra un minimo in euro che stabilisco per contesto. - **Nuovi pattern che l'agente non ha visto prima** — se il classificatore dell'agente segnala qualcosa come "sconosciuto" o fuori dalla sua distribuzione di training, quella è un'escalation forzata. - **Output sensibili alla conformità** — qualsiasi cosa che tocchi HIPAA, PCI, avvisi legali o contenuti finanziari regolamentati viene esaminata da una persona. ## Quando i cancelli uccidono silenziosamente il prodotto Questi sono i pattern dove un cancello sembra sicuro ma rompe silenziosamente l'adozione: - **Operazioni ad alto volume e reversibili** — se puoi annullarlo in due clic e avviene 200 volte al giorno, la stanchezza da revisione vincerà. - **Flussi di lavoro sensibili al tempo** — un agente che risponde alle richieste dei clienti in arrivo in 30 secondi non dovrebbe avere un cancello sincrono. - **Compiti dove l'umano ha meno contesto dell'agente** — se l'agente ha letto 50 pagine di contesto per fare una classificazione e il revisore ottiene un riepilogo di una riga, la revisione è teatro. - **Arricchimento ed etichettatura interne** — etichettare record CRM, categorizzare spese, riassumere note di riunioni. Le poste in gioco non giustificano l'interruzione. ## I tre pattern di cancello che implemento davvero Quando un cancello è giustificato, scelgo una di tre implementazioni: **1. Approvazione asincrona via Slack/e-mail** L'agente completa la sua bozza, pubblica un messaggio in un canale Slack designato con l'azione proposta e un pulsante approva/rifiuta, e mette in pausa. Uso Cloudflare Queues per trattenere l'azione in attesa, e un Worker separato che ascolta il webhook di approvazione prima di riprendere. Funziona bene per: bozze di e-mail, contenuti social, aggiornamenti significativi del CRM. **2. Escalation basata sulla confidenza** L'agente funziona completamente automatizzato per output ad alta confidenza (diciamo, ≥0,85 di confidenza su uno schema strutturato) e instrada gli elementi a bassa confidenza a una coda umana. Funziona bene per: classificazione, routing, triage. **3. Revisione in dashboard con approvazione in batch** Invece di un cancello per elemento, tutti gli output dell'agente arrivano in un dashboard di revisione. Un umano esamina in batch — ad esempio, ogni mattina — e approva o corregge in gruppo. Funziona bene per: generazione di contenuti, redazione di report, riepiloghi programmati. ## La trappola dell'affaticamento degli avvisi Ogni cancello che aggiungi è una tassa permanente sull'attenzione di qualcuno. Il rischio non è solo che un cancello venga ignorato — è che tre cancelli creino un canale Slack rumoroso, che allena le persone a ignorare tutte le notifiche. La disciplina che ho costruito: ogni cancello ha un proprietario esplicito e un SLA esplicito. Se nessuno esamina costantemente entro lo SLA, il cancello viene rimosso e sostituito con una traccia di audit. Faccio un audit mensile di tutte le code di approvazione. ## Collegamento all'affidabilità dell'agente Un cancello è uno strato di uno stack di affidabilità, non l'intero stack. Il mio stack di affidabilità completo per un agente in produzione: 1. **Eval harness** — conferma output corretti prima del deployment. 2. **Output strutturati con validazione dello schema** — l'output dell'agente è vincolato a uno schema tipizzato. 3. **Soglia di confidenza** — gli output a bassa confidenza vanno in revisione umana. 4. **Log di audit** — ogni azione dell'agente viene registrata. 5. **Cancello di approvazione umana** — solo per le azioni dove quanto sopra non è sufficiente. ## La mia regola pratica Se non vorrei che un dipendente junior lo facesse senza consultarmi prima, l'agente ha bisogno di un cancello. Se lascierei che un dipendente junior lo facesse senza pensarci due volte, l'agente dovrebbe funzionare senza supervisione. ## FAQ ### Come gestire un agente che necessita di approvazione ma funziona ad alto volume? Cambia l'architettura: non richiedere approvazione per elemento — richiedere approvazione per pattern. Lascia funzionare l'agente, ma fagli presentare anomalie statistiche per la revisione umana. ### E se un errore potesse causare danni gravi ma non posso permettermi una revisione umana completa? Di solito è un segnale per non distribuire ancora l'agente per quell'azione. In alternativa, usa una soglia di confidenza. Se usi [Claude](/recommends/claude) come strato del modello, i pattern di utilizzo degli strumenti dell'SDK Anthropic rendono facile definire uno strumento di "escalation" che l'agente può chiamare quando manca di confidenza. --- ## Claude Tool Use: Come Do Capacità Reali ai Miei Agenti IA Source: https://alejandrorioja.com/it/claude-tool-use-production-agents/ Published: 2026-07-21 Tags: AI Agents, Claude TL;DR: Il tool use di Claude permette al tuo agente di compiere azioni — non solo generare testo. Definisci strumenti come schemi JSON, Claude decide quando chiamarli, e il tuo codice esegue l'azione nel mondo reale. Il loop ha tre fasi: invia messaggio → ricevi blocco tool_use → esegui e restituisci risultato. Ho implementato questo in 15+ agenti di produzione su Cloudflare Workers. Il punto di guasto non è quasi mai l'IA — sono i risultati ambigui che tornano dagli strumenti. ## Indice _Aggiornato luglio 2026._ **TL;DR:** Il tool use di Claude permette al tuo agente di compiere azioni — non solo generare testo. Definisci strumenti come schemi JSON, Claude decide quando chiamarli, e il tuo codice esegue l'azione nel mondo reale. Il loop ha tre fasi: invia messaggio → ricevi blocco tool_use → esegui e restituisci risultato. Ho implementato questo in 15+ agenti di produzione su Cloudflare Workers. Il punto di guasto non è quasi mai l'IA — sono i risultati ambigui che tornano dagli strumenti. **[Nota dell'operatore]** Gestisco 30+ agenti IA in produzione tra un brand di consulenza e Pickleland, una struttura di pickleball a Pflugerville, TX. Circa la metà usa il tool use — la funzione dell'API Claude che permette al modello di chiamare funzioni definite dal tuo codice. Ecco il pattern a cui sono giunto dopo aver implementato e iterato in produzione. ## Perché il tool use cambia ciò che un agente può fare Senza strumenti, un agente può solo generare testo. Questo è utile per la sintesi, la redazione e la classificazione — ma non è ciò che la maggior parte delle automazioni aziendali richiede davvero. Le automazioni aziendali devono consultare informazioni, scrivere su database, chiamare API, inviare messaggi. Il tool use è il modo in cui dai questo accesso a Claude. Definisci un insieme di strumenti come schemi JSON. Claude legge gli schemi, decide quale strumento chiamare e con quali argomenti, e restituisce un blocco di contenuto `tool_use` strutturato. Il tuo codice esegue la funzione reale. Claude ottiene il risultato e decide cosa fare dopo — incluso chiamare un altro strumento o produrre una risposta testuale finale. La chiave: **Claude decide quando e se chiamare uno strumento.** Tu definisci le capacità. Il modello ragiona su quando usarle. ## Come funziona il flusso API Il loop di tool use ha tre fasi. Eseguirai questo loop una o più volte a seconda di quante chiamate di strumento effettua il modello. **Fase 1: Invia il tuo messaggio con gli strumenti definiti** ```typescript const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ { name: "check_court_availability", description: "Check if a court is available at a given date, time, and duration", input_schema: { type: "object", properties: { date: { type: "string", description: "Date in YYYY-MM-DD format", }, time: { type: "string", description: "Start time in HH:MM format (24h)", }, duration_minutes: { type: "number", description: "Duration of the booking in minutes", }, }, required: ["date", "time", "duration_minutes"], }, }, ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, ], }); ``` **Fase 2: Controlla se Claude vuole chiamare uno strumento** ```typescript if (response.stop_reason === "tool_use") { const toolUseBlock = response.content.find( (block): block is Anthropic.ToolUseBlock => block.type === "tool_use" ); if (!toolUseBlock) throw new Error("Expected tool_use block"); // Run your actual function const toolResult = await checkCourtAvailability( toolUseBlock.input as CourtAvailabilityInput ); // Step 3: Return the result to Claude const finalResponse = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ /* same tools as before */ ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, { role: "assistant", content: response.content }, { role: "user", content: [ { type: "tool_result", tool_use_id: toolUseBlock.id, content: JSON.stringify(toolResult), }, ], }, ], }); // finalResponse.content now has the text answer } ``` Questo è l'intero pattern. Tre interazioni API per chiamata di strumento: definire strumenti → ricevere blocco `tool_use` → restituire risultato. ## Esempio reale: il verificatore di disponibilità di Pickleland Pickleland è una struttura di pickleball. Riceviamo richieste di prenotazione su Facebook Messenger, nei commenti e tramite un chatbot. La domanda è quasi sempre una variazione di "siete aperti sabato alle 15?" o "posso prenotare un campo per il mio gruppo di 8 persone?" L'agente verificatore di disponibilità usa il tool use per interrogare il sistema di prenotazione reale in tempo reale invece di dare una risposta standard. Ecco l'agente completo — semplificato ma fedele alla produzione: ```typescript // workers/availability-checker.ts import Anthropic from "@anthropic-ai/sdk"; const anthropic = new Anthropic(); const AVAILABILITY_TOOLS: Anthropic.Tool[] = [ { name: "check_availability", description: "Check court availability for a date, time, and group size. Returns available courts and their prices.", input_schema: { type: "object", properties: { date: { type: "string", description: "YYYY-MM-DD" }, start_time: { type: "string", description: "HH:MM (24h)" }, duration_minutes: { type: "number" }, players: { type: "number", description: "Number of players" }, }, required: ["date", "start_time", "duration_minutes"], }, }, { name: "get_pricing", description: "Get current pricing for court rentals and open play sessions", input_schema: { type: "object", properties: { session_type: { type: "string", enum: ["court_rental", "open_play", "clinics"], }, }, required: ["session_type"], }, }, ]; export async function handleInquiry( userMessage: string, env: Env ): Promise { const messages: Anthropic.MessageParam[] = [ { role: "user", content: userMessage }, ]; // Agentic loop — keep going until stop_reason is "end_turn" while (true) { const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 512, system: "You are the booking assistant for Pickleland, a pickleball facility in Pflugerville, TX. " + "Use the tools to look up real availability and pricing. Never make up availability or prices. " + "If the customer wants to book, direct them to pickleland.com/book.", tools: AVAILABILITY_TOOLS, messages, }); // Push the assistant's response into message history messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const textBlock = response.content.find( (b): b is Anthropic.TextBlock => b.type === "text" ); return ( textBlock?.text ?? "I wasn't able to answer that — please call us directly." ); } if (response.stop_reason === "tool_use") { // Process ALL tool calls in this response (Claude can request multiple at once) const toolResults: Anthropic.ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; let result: unknown; switch (block.name) { case "check_availability": result = await checkAvailability( block.input as AvailabilityInput, env ); break; case "get_pricing": result = await getPricing(block.input as PricingInput, env); break; default: result = { error: `Unknown tool: ${block.name}` }; } toolResults.push({ type: "tool_result", tool_use_id: block.id, content: JSON.stringify(result), }); } // Return all tool results in a single user message messages.push({ role: "user", content: toolResults }); } } } ``` Due cose da evidenziare qui. **Il loop agentico.** Continuo finché `stop_reason === "end_turn"`. Claude potrebbe chiamare `check_availability`, decidere che ha bisogno anche dei prezzi, chiamare `get_pricing`, e poi produrre la risposta finale — sono tre chiamate API per un singolo messaggio dell'utente. Il loop gestisce questo senza alcuna logica speciale. **Chiamate multiple di strumenti per turno.** Claude può restituire più blocchi `tool_use` in una singola risposta. Li elaboro tutti e restituisco tutti i risultati in un singolo messaggio `user`. Se li elabori uno alla volta e li restituisci individualmente, interrompi il flusso della conversazione e sprechi token. ## Esempio reale: l'agente di ricerca lead Il mio brand di consulenza usa un agente di ricerca che arricchisce i lead in entrata prima che io li contatti. Quando qualcuno compila il modulo di contatto, l'agente ricerca l'azienda ed estrae ciò che devo sapere prima della chiamata. Le definizioni degli strumenti per questo includono uno strumento di scrittura — ed è qui che il pattern diventa interessante: ```typescript const RESEARCH_TOOLS: Anthropic.Tool[] = [ { name: "search_company", description: "Search for information about a company", input_schema: { type: "object", properties: { company_name: { type: "string" }, website: { type: "string", description: "Company website if known" }, }, required: ["company_name"], }, }, { name: "save_research", description: "Save the completed research summary to Airtable. Call this when all research is complete.", input_schema: { type: "object", properties: { company_summary: { type: "string" }, estimated_size: { type: "string", enum: ["1-10", "11-50", "51-200", "200+"], }, likely_use_case: { type: "string" }, priority: { type: "string", enum: ["high", "medium", "low"] }, notes: { type: "string" }, }, required: [ "company_summary", "estimated_size", "likely_use_case", "priority", ], }, }, ]; ``` `save_research` è quello che chiamo uno **strumento di scrittura** — il suo scopo non è ottenere informazioni, ma confermare l'output di Claude in un database in forma strutturata. Uso questo pattern invece di cercare di fare il parse di JSON da una risposta testuale. Claude sa quando la ricerca è completata e chiama `save_research` con campi correttamente tipizzati. Non scrivo mai un parser. Questa è l'applicazione più pulita del tool use: definisci uno strumento di "azione finale" con lo schema esatto che vuoi, e Claude fornisce output strutturato tramite la chiamata allo strumento. Nessun parsing di testo, nessuna regex, nessuna validazione JSONSchema di output in testo libero. ## Uno strumento vs. molti L'istinto quando si inizia con il tool use è di costruire un unico strumento gigante che fa tutto. Resisti a questo. Gli strumenti piccoli e focalizzati sono migliori per tre ragioni: 1. **Claude ragiona meglio sugli strumenti piccoli.** Uno strumento chiamato `get_court_status` che restituisce la disponibilità è più facile da elaborare per il modello rispetto a uno strumento chiamato `manage_facility` che prende un parametro `mode` e si ramifica internamente. 2. **Gli strumenti piccoli sono più facili da testare.** Ogni strumento è una funzione TypeScript che puoi testare unitariamente indipendentemente dall'LLM. Dovresti farlo — i bug degli strumenti sono difficili da debuggare all'interno di una conversazione attiva. 3. **Claude può parallelizzare gli strumenti piccoli.** Se due strumenti non dipendono l'uno dall'altro, Claude può chiamarli nella stessa risposta e tu li elabori in parallelo. Questo funziona solo se gli strumenti sono genuinamente indipendenti. L'eccezione: strumenti che necessitano di accesso a molto stato interno condiviso. Se la funzione ha bisogno di 10 variabili dalla stessa fonte di dati, uno strumento con uno schema più ricco supera 10 strumenti che accedono ciascuno separatamente al database. La mia regola pratica: inizia con uno strumento per capacità distinta. Unisci gli strumenti solo quando vedi Claude chiamarli insieme ad ogni richiesta. ## Implicazioni sui costi Il tool use aggiunge token. Ogni definizione di strumento va nel contesto del prompt di sistema. Ogni blocco `tool_use` e `tool_result` consuma token nella cronologia della conversazione. Per un loop agentico multi-turno, questo si accumula rapidamente. Per il verificatore di disponibilità di Pickleland, una conversazione tipica esegue 3–4 chiamate API in totale (messaggio iniziale + 1–2 chiamate di strumenti + risposta finale), ognuna elaborando 600–900 token. Ai prezzi di Haiku, questo costa meno di $0,001 per richiesta. Come spiego nel [post sul calcolo dei costi degli agenti IA](/ai-agent-cost-math-when-haiku-beats-sonnet/), Haiku gestisce in modo affidabile le attività di chiamata di strumenti ben definiti ed è 10× più economico di Sonnet per lo stesso volume di token. L'agente di ricerca lead funziona su Sonnet perché le decisioni di giudizio — dare priorità a un lead, stimare l'idoneità — richiedono più capacità di ragionamento di quanto Haiku offra in modo affidabile su input aperti. Il calcolo funziona ancora perché viene eseguito raramente (alcune volte a settimana, non migliaia al giorno). La scelta del modello segue la complessità del compito, non la preferenza personale. ## Il punto di guasto di cui nessuno parla Il punto di guasto più comune che vedo nel tool use in produzione non è Claude che chiama lo strumento sbagliato. È lo strumento che restituisce qualcosa su cui Claude non riesce a ragionare chiaramente. Se il tuo strumento restituisce un oggetto di database grezzo con 40 campi, Claude si confonde su quali campi siano importanti. Se il tuo strumento lancia un'eccezione (che appare come un crash del Worker invece che come un risultato dello strumento), il loop si interrompe silenziosamente. Se il tuo strumento restituisce `null` quando vuole dire "nessun risultato", Claude non sa se riprovare o arrendersi. Tre regole per i risultati degli strumenti: **Restituisci risultati concisi ed espliciti.** `{ available: true, courts: ["Court 3", "Court 5"], price_per_hour: 20 }` — non la riga completa del database. **Cattura gli errori all'interno della funzione dello strumento e restituiscili come risultati strutturati.** `{ error: "booking system timeout", retry: true }` — non un'eccezione lanciata che fa crashare il Worker. **Rendi "nessun risultato" esplicito.** `{ available: false, next_available: "2026-07-23T14:00:00Z" }` — non `null` o un array vuoto senza contesto. Claude ragiona molto meglio su segnali chiari che su valori di ritorno ambigui. Ogni ora che ho trascorso a debuggare il tool use in produzione riguardava risultati poco chiari, non il ragionamento del modello. ## La conclusione dell'operatore Il tool use è la funzione che trasforma Claude da un generatore di testo in un operatore. Definisci strumenti focalizzati con schemi di input chiari. Gestisci tutti i blocchi `tool_use` in una singola risposta al modello. Esegui il loop agentico finché `stop_reason === "end_turn"`. Restituisci risultati puliti e concisi dalle tue funzioni degli strumenti — non oggetti di dati grezzi, non eccezioni lanciate, non null ambigui. Il modello gestisce il ragionamento. Il tuo codice gestisce le azioni nel mondo reale. Tieni questi due compiti chiaramente separati e l'architettura rimane manutenibile anche quando aggiungi strumenti. Se stai costruendo il tuo primo agente con tool use, inizia con il pattern del verificatore di disponibilità sopra — uno strumento, uno scopo, un loop agentico. Metti in produzione quello. Poi aggiungi il secondo strumento. --- **Correlati:** [Lo stack di agenti che uso per gestire 30+ agenti in produzione](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Haiku vs Sonnet: il calcolo dei costi per i task degli agenti](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Agenti event-triggered vs schedulati: quale pattern per quale lavoro](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) **Stai costruendo un agente con tool use e sei bloccato?** [Contattami](/contact/) — progetto e costruisco architetture di agenti di produzione per team di operatori. ## FAQ ### Il tool use di Claude funziona con tutti i modelli? Sì — il tool use è supportato da tutti i modelli Claude attuali. [Claude](/recommends/claude) Haiku gestisce in modo affidabile strumenti ben definiti con schemi chiari ed è l'opzione più economica per i tipi di task ad alto volume. Sonnet gestisce meglio le decisioni di chiamata di strumenti più ambigue o aperte. Inizia con Haiku; passa a un modello superiore se la qualità dell'output non è sufficiente. ### Qual è la differenza tra il tool use di Claude e il function calling di OpenAI? Meccanicamente identici. OpenAI ha coniato "function calling"; Anthropic lo chiama "tool use". In entrambi i casi: definisci schemi JSON, il modello restituisce chiamate strutturate, il tuo codice esegue la funzione. La forma dell'API differisce ma il concetto è lo stesso. ### Claude può chiamare più strumenti in una singola risposta? Sì. Claude può restituire più blocchi `tool_use` in una singola risposta `assistant`. Elaborali tutti e restituisci tutti i risultati in un singolo messaggio `user`. Vedi il pattern del loop agentico nell'esempio di Pickleland sopra — il ciclo `for` su `response.content` lo gestisce correttamente. ### Quanti strumenti dovrei definire per agente? Rimango sotto 8–10 strumenti per agente. Oltre questo, ho visto Claude occasionalmente scegliere lo strumento sbagliato al primo tentativo, il che spreca token in un loop di correzione. Se hai bisogno di più di 10 capacità, dividi l'agente in più agenti con set di strumenti specializzati invece di costruire un agente che sa tutto. ### Dovrei usare il tool use per ottenere output strutturato? Sì — il pattern dello strumento di scrittura `save_research` è più pulito che chiedere a Claude di restituire JSON in un blocco testuale e poi fare il parse. Definisci uno strumento di "azione finale" con lo schema esatto che vuoi. Claude lo chiamerà con campi correttamente tipizzati quando ha finito. Nessun parser necessario. --- ## Come i Motori di Ricerca Valutano Davvero la Qualità dei Contenuti nel 2026 Source: https://alejandrorioja.com/it/how-search-engines-evaluate-content-quality/ Published: 2026-07-20 Tags: SEO, GEO ## Indice dei contenuti _Pubblicato a luglio 2026._ **TL;DR:** I motori di ricerca e i motori IA hanno entrambi smesso di valutare le pagine in isolamento. Valutano i siti — la profondità di copertura su un argomento, i segnali di fiducia che reggono al controllo, e la coerenza nel tempo, non un solo grande articolo. Gestisco 384 post in inglese distribuiti in 13 lingue e controllo settimanalmente se vengo citato su ChatGPT, Perplexity e Google AI Overviews. Il pattern è coerente: i post isolati si stabilizzano su un plateau, i cluster si moltiplicano, e i segnali di fiducia che spostano i tassi di citazione sono noiosi, strutturali ed economici da costruire. **Lettura dell'operatore:** Non sto teorizzando sulla qualità dei contenuti — gestisco il motore di contenuti di questo sito e osservo cosa succede ai tassi di citazione quando cambio qualcosa. Questo post è costruito interamente su cose che ho misurato su alejandrorioja.com: dimensioni reali dei cluster, un vero esperimento di citazione durato sei settimane, veri test di schema markup. Niente qui è una congettura su come gli algoritmi "probabilmente" funzionano. ## La qualità ha smesso di essere una questione per-pagina già da un po' Il modello mentale che la maggior parte delle persone ha ancora è: scrivi un buon articolo, si posiziona. Non è mai stato del tutto vero, e ora è attivamente fuorviante per qualsiasi cosa al di là di un termine di coda lunga molto ristretto. Ho un modo diretto per vederlo sul mio stesso sito. Pubblico in una manciata di cluster reali — un cluster di 29 post su Agenti IA e Claude, un cluster di post esplicativi sui modelli di business "Come Fa Soldi X" arrivato a 20 post (Google, OpenAI, Anthropic, Uber, Salesforce e altri), e un grande cluster SEO/GEO che è il singolo argomento più grande del sito per numero di tag. Un post autonomo su un argomento che ho toccato una sola volta si comporta in modo completamente diverso da un post che si trova dentro uno di questi cluster, anche quando il pezzo autonomo è oggettivamente scritto meglio. I post in cluster ottengono più citazioni, si posizionano in modo più stabile e recuperano più velocemente dopo un aggiornamento dell'algoritmo. Quelli isolati o hanno un picco o non ce l'hanno, e quando non ce l'hanno, non c'è un'autorità circostante su cui appoggiarsi. È il meccanismo reale dietro a quella che spesso viene venduta come una [strategia di autorità tematica per l'IA](https://www.linkbuildinghq.com/blog/how-to-build-topical-authority-for-ai/) — non un misterioso punteggio di fiducia, ma il semplice fatto che una pagina posizionata accanto ad altre 28 pagine sullo stesso argomento offre sia al crawler di Google sia alla fase di retrieval di un LLM più contesto corroborante su cui appoggiarsi. Ho descritto [tutta la meccanica di questa struttura](/pillar-content/) deliberatamente — in breve, un cluster funziona solo se ogni post al suo interno rimanda al pillar e il pillar rimanda a sua volta a ognuno di essi, così la mappa tematica è esplicita invece di essere qualcosa che il crawler deve ricostruire da solo. Il test pratico che applico prima di pubblicare qualsiasi cosa di nuovo: questo post estende un cluster che possiedo già, o ne avvia uno nuovo isolato? I pezzi isolati non sono vietati — alcune query hanno davvero bisogno di una sola pagina — ma so già in partenza che un pezzo isolato compete solo sui segnali a livello di pagina, senza nessuno dei benefici composti che un post in cluster ottiene gratuitamente. ## "Valore reale, non riempitivo" è un'affermazione verificabile, non una sensazione La versione generica di questo consiglio dice "aggiungi profondità e contesto, non ripetere informazioni comunemente disponibili". Vero, ma inutile senza un modo per verificarlo. Ecco il mio test reale, eseguito su scala reale: ho 384 post in inglese. Ognuno viene tradotto in altre 12 lingue da [un agente che ho costruito esattamente per questo](/how-to-translate-one-blog-post-into-13-languages-with-one-agent/). Tradurre è economico — l'intero arretrato di 341 post è costato circa 1,70 dollari in chiamate API su Haiku. Scrivere non lo è. Se potessi gonfiare il volume riscrivendo leggermente la stessa idea in dieci formulazioni diverse, quell'agente mi permetterebbe di scalare la duplicazione con la stessa facilità con cui scala la traduzione. Non lo faccio, perché una formulazione duplicata non supera il test reale: questa pagina risponde a una domanda a cui nessun'altra pagina del mio sito risponde già altrettanto bene o meglio? Questo è il filtro che conta più di qualsiasi linea guida di stile. Il "riempitivo" non è un problema di tono, è un problema di ridondanza — una pagina che ripete una pagina vicina senza aggiungere una nuova angolazione, un nuovo numero o un nuovo esempio. Lo verifico prima di pubblicare chiedendomi se il nuovo post cannibalizzerebbe le citazioni di uno esistente invece di aggiungere nuova superficie di citazione. Se due post sul mio sito soddisfano allo stesso modo la stessa query, uno dei due è riempitivo, indipendentemente da quanto sia scritto bene. ## Segnali di fiducia che ho davvero costruito e misurato "Affidabilità" è il termine più vago di ogni articolo SEO generico, di solito seguito da una lista tipo "cita le fonti, mostra competenza, mantieni l'accuratezza" senza alcun modo per verificare che qualcosa di tutto ciò abbia davvero spostato qualcosa. La versione concreta che applico: lo schema markup, perché è l'unico segnale di fiducia che un motore IA analizza meccanicamente invece di dedurlo. Ho descritto [l'implementazione completa](/schema-markup-for-geo/) altrove e sono andato più a fondo su [quali tipi ripagano davvero](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). In breve: `Article`/`BlogPosting` con un vero autore nominato e un `dateModified` onesto è l'ancora di autorialità; `FAQPage` e `HowTo` sono i tipi con la resa più alta perché consegnano al modello una domanda già risposta o una procedura già strutturata invece di costringerlo a dedurla dalla prosa; gli schema `Person` e `Organization` esistono perché il modello non mi confonda con qualcun altro che condivide il mio nome. Niente di tutto questo è astratto per me — è l'intervento dietro un risultato reale. Applicare un overlay strutturale in quattro parti (blocco TL;DR, passaggi numerati, sezione FAQ, citazioni di fonti primarie) a 41 post pillar che già attivavano gli AI Overview di Google ha portato la frequenza di citazione da 4 su 41 a 19 su 41 in sei settimane — il [test completo di sei settimane è descritto qui](/google-ai-overview-citation-case-study/). Non è "aggiungi segnali di fiducia e spera bene". È un prima/dopo misurato sulle mie stesse pagine, con l'avvertenza che il post stesso dichiara chiaramente: ha funzionato solo su pagine che avevano già il pavimento di autorità dato dal posizionarsi tra le prime 5 posizioni organiche. La struttura amplifica un segnale già esistente; non lo fabbrica dal nulla. ## La coerenza si moltiplica, ma "coerenza" non significa aggiornamenti costanti L'affermazione generica qui è di solito "la freschezza conta ma non ogni articolo va aggiornato", detta senza alcuna cadenza reale allegata. Ecco la mia. Non tocco la maggior parte dei post dopo la pubblicazione. Mantengo però un insieme rotante di post pillar e li aggiorno ogni 6-12 mesi quando i fatti sottostanti cambiano — esce un nuovo modello, cambiano i prezzi di uno strumento, una statistica diventa obsoleta. `dateModified` cambia solo quando il contenuto cambia davvero; ho testato il fingere un aggiornamento e non funziona — i motori vedono attraverso una data spostata senza una modifica sostanziale, esattamente quello che ha trovato anche il case study sugli AI Overview. Il segnale di coerenza che controllo davvero ogni settimana non è la cadenza di pubblicazione, è la copertura delle citazioni: passo settimanalmente una lista tracciata di query critiche per il business attraverso ChatGPT, Perplexity e Google e registro se vengo citato — [la metodologia è qui](/how-to-measure-ai-search-traffic/). La copertura delle citazioni è un indicatore anticipatore — si muove prima del traffico di referral o dell'aumento della ricerca di brand, quindi è il numero che mi dice se un cluster sta davvero guadagnando autorità nel tempo o se sta semplicemente lì fermo. Un sito che pubblica una volta e poi tace non ottiene un secondo sguardo da quel controllo settimanale; un sito che continua a estendere un cluster sì. ## Cosa premia davvero la valutazione "a livello di sito", strato per strato I tre motori che monitoro non pesano gli stessi segnali in modo identico. Questa è la tabella pratica che tengo a mente quando decido dove investire gli sforzi: | Strato di qualità | Come si presenta davvero nella pratica | Dove l'ho misurato | | --- | --- | --- | | Profondità tematica | 20-30+ post interconnessi su un argomento, il pillar che rimanda a ogni post del cluster e viceversa | Cluster Agenti IA (29 post), cluster "Come Fa Soldi X" (20 post) | | Estraibilità strutturale | Blocco TL;DR, passaggi numerati, FAQ, allineati alla formulazione reale degli utenti | 4/41 → 19/41 citazioni AI Overview in 6 settimane | | Autorialità/fiducia | Autore nominato + `dateModified` accurato + schema Person/Organization | Schema markup per GEO, analisi dei tipi di schema | | Coerenza nel tempo | Tracciamento settimanale delle citazioni sui motori, non riscritture costanti | Metodologia di misurazione della ricerca con IA | Il fallimento più comune che vedo nei consigli generici è trattare questi elementi come un unico punteggio indifferenziato di "qualità". Non lo sono. Una pagina può eccellere nell'estraibilità strutturale e comunque perdere contro un competitor con più profondità tematica. Una pagina può trovarsi dentro un cluster profondo e comunque perdere una citazione specifica a favore di un competitor più fresco e con uno schema migliore. Sapere quale strato è davvero il collo di bottiglia per una determinata pagina è la maggior parte del lavoro. ## Dove questo si rompe — le avvertenze oneste Preferisco segnalare i limiti piuttosto che vendere il pattern in modo eccessivo: - **L'autorità di dominio resta un cancello.** L'intervento sugli AI Overview ha funzionato solo su pagine che già si posizionavano tra le prime 5 posizioni organiche. La struttura ha amplificato un segnale esistente; non ha creato autorità da una pagina fredda. - **I motori divergono su cosa premiano.** Facendo passare gli stessi 50 termini principali attraverso ChatGPT e Google, ho trovato solo circa il 40% di sovrapposizione su quali fonti venivano citate — [analisi completa qui](/chatgpt-search-vs-google-50-term-test/). Ottimizzare per "i motori di ricerca" come un unico bersaglio è già la cornice sbagliata; stai ottimizzando per più motori che concordano sulle basi e divergono sul resto. - **Alcune categorie non hanno davvero bisogno di un cluster.** Una manciata delle mie pagine con le migliori performance sono veri pezzi isolati. La profondità è una leva, non un requisito universale — forzare un cluster dove lo spazio della query non lo supporta produce esattamente quel contenuto sottile e riempito che l'intero framework dovrebbe evitare. ## FAQ ### Un singolo articolo eccellente può mai superare un cluster mediocre? Sì, per una query abbastanza ristretta con bassa competizione. Ma per qualsiasi termine principale con competizione reale, le pagine che mantengono la posizione a lungo termine sono quasi sempre sostenute da un cluster. Ho visto post isolati avere un picco e poi svanire in un modo che i post in cluster non fanno. ### Quanti post servono a un argomento prima che conti come un vero cluster? Non c'è un numero fisso, ma nei miei dati l'effetto diventa chiaramente visibile intorno a 8-10 post genuinamente distinti sui sotto-argomenti dello stesso tema — abbastanza perché il pillar possa rimandare in modo significativo e ogni post del cluster abbia un posto specifico dove inviare i lettori che vogliono più approfondimento. ### Lo schema markup è davvero necessario, o basta una buona scrittura? Una buona scrittura è necessaria ma non sufficiente per la citazione da parte dei motori IA nello specifico. I motori estraggono fatti strutturati in modo più affidabile dagli schema `FAQPage` e `HowTo` che dalla sola prosa, perché lo schema rimuove il passaggio di inferenza. Ho misurato aumenti percentuali di citazione da una singola cifra fino a metà decina aggiungendolo a post che prima non avevano schema. ### Ogni quanto dovrei aggiornare i vecchi contenuti invece di pubblicarne di nuovi? Aggiorno i post pillar ogni 6-12 mesi quando cambia un fatto reale, e non sposto mai `dateModified` senza una modifica sostanziale. La maggior parte del mio budget di contenuti va verso nuovi post che estendono i cluster, non verso riscritture — la freschezza conta, ma non è la leva dominante rispetto alla profondità tematica e alla struttura. ### Qual è la cosa singola con la leva più alta da sistemare per prima? Se una pagina si posiziona già ragionevolmente bene a livello organico ma non viene citata dai motori IA, aggiungi un blocco TL;DR pulito che risponda direttamente alla query principale. Nel mio test di sei settimane, questa è stata di gran lunga la leva singola più grande — più grande dello schema FAQ, più grande delle citazioni di fonti primarie, più grande dei passaggi numerati. ## In sintesi La valutazione della qualità dei contenuti si è spostata dalla pagina al sito, e i segnali a livello di sito che davvero spostano l'ago sono misurabili, non misteriosi: profondità di cluster che puoi contare, overlay strutturali che puoi testare in A/B, schema che puoi validare, e un numero di copertura delle citazioni che puoi tracciare ogni settimana. Niente di tutto ciò richiede di indovinare cosa "vuole" un algoritmo. Richiede di pubblicare dentro una vera struttura tematica, dare ai motori una risposta pulita ed estraibile invece di costringerli a dedurla, e controllare il risultato abbastanza spesso da sapere se sta funzionando. Applico tutte e quattro queste discipline su questo sito ogni settimana, e i numeri qui sopra sono ciò che hanno davvero prodotto — non ciò che una guida generica sostiene che dovrebbero produrre. --- ## Claude vs ChatGPT per le Aziende nel 2026: Il Punto di Vista Onesto di un Operatore Source: https://alejandrorioja.com/it/claude-vs-chatgpt-for-business-2026/ Published: 2026-07-18 Tags: AI Agents, Productivity TL;DR: Claude vince nella costruzione di agenti, nel lavoro con contesti lunghi, nella programmazione e in tutto ciò che gira in produzione su larga scala. ChatGPT vince nelle integrazioni consumer, nella modalità vocale e nell'ecosistema di plugin più ampio se il tuo flusso di lavoro vive nell'interfaccia chat. Se stai costruendo workflow automatizzati o agenti IA, Claude è la base migliore. Se vuoi un assistente chat capace con più connessioni di terze parti, ChatGPT ha il vantaggio. Per la maggior parte degli imprenditori, la vera domanda è: stai chattando con l'IA o stai costruendo con l'IA? Questa risposta determina lo strumento. ## Indice _Pubblicato luglio 2026._ **TL;DR:** Claude vince nella costruzione di agenti, nel lavoro con contesti lunghi, nella programmazione e in tutto ciò che gira in produzione su larga scala. ChatGPT vince nelle integrazioni consumer, nella modalità vocale e nell'ecosistema di plugin più ampio se il tuo flusso di lavoro vive nell'interfaccia chat. Se stai costruendo workflow automatizzati o agenti IA, Claude è la base migliore. Se vuoi un assistente chat capace con più connessioni di terze parti, ChatGPT ha il vantaggio. Per la maggior parte degli imprenditori, la vera domanda è: stai chattando con l'IA o stai costruendo con l'IA? Questa risposta determina lo strumento. **[Prospettiva dell'operatore]** Gestisco due attività — un brand di consulenza e Pickleland, una struttura di pickleball a Pflugerville, TX — con oltre 30 agenti IA in produzione che gestiscono risposte sui social media, promozione di eventi, follow-up sulle prenotazioni, bozze di newsletter e altro ancora. L'intero mio stack di agenti è costruito su [Claude](/recommends/claude). Ho anche usato ChatGPT abbastanza da sapere dove ciascuno fallisce. Questa non è una recensione di benchmark. È il punto di vista di un professionista. ## La domanda che conta davvero La maggior parte dei confronti chiede "quale modello è più intelligente?" È la domanda sbagliata per l'uso aziendale. La domanda giusta è: **cosa stai costruendo e cosa deve fare in modo affidabile su larga scala?** Un responsabile marketing che vuole che l'IA lo aiuti a scrivere contenuti ha requisiti diversi da quelli di un fondatore che costruisce una pipeline automatizzata di qualificazione dei lead. Un solopreneur che usa l'IA per prepararsi alle riunioni ha esigenze diverse da quelle di un operatore che costruisce agenti che elaborano 500 richieste di clienti a settimana. Lo strumento che vince per uno è spesso quello sbagliato per l'altro. Questa prospettiva determina tutto ciò che segue. ## Dove Claude vince ### 1. Lavoro con contesti lunghi La finestra di contesto nativa di Claude — 200K token — gestisce cose che fanno crashare altri modelli. Passo regolarmente a Claude interi cronologie di conversazioni con i clienti, bozze di contratti complete o sintesi di ricerche multi-documento e gli chiedo di sintetizzare o fare riferimenti incrociati. Mantiene il filo. I modelli concorrenti supportano tecnicamente i contesti lunghi ora, ma il degrado pratico su compiti complessi è ancora peggiore di quello di Claude. Per i compiti aziendali che implicano la lettura di documenti lunghi, l'analisi di esportazioni di dati dense o il mantenimento della coerenza in workflow lunghi, Claude ha un vantaggio genuino. ### 2. Comportamento dell'agente in produzione Quando esegui Claude come agente — chiamando strumenti, prendendo decisioni in un loop, scrivendo su database, gestendo errori — si comporta in modo più coerente di ChatGPT nella mia esperienza. Segue le istruzioni del system prompt in modo più affidabile, produce output strutturati più facili da parsare ed è meno probabile che si allontani dal compito quando il contesto cresce. Questo conta enormemente per gli agenti. Un modello che segue il tuo system prompt il 95% delle volte rispetto al 99% delle volte sembra simile. Con 500 chiamate al giorno, sono 25 casi di deriva al giorno da rilevare e correggere. L'articolo che ho scritto su [come scrivere system prompt per agenti IA che non falliscono in produzione](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/) copre questo in dettaglio, ma la versione breve è: il rispetto delle istruzioni di Claude a livello di system prompt è il migliore che ho testato. ### 3. Programmazione e lavoro tecnico Costruisco quasi tutto in TypeScript su Cloudflare Workers. Claude Code è il mio strumento di sviluppo quotidiano — ed è genuinamente utile piuttosto che semplicemente "abbastanza buono". Per le domande architetturali, il debugging, il refactoring e la scrittura della logica degli agenti da zero, Claude supera costantemente ciò che ho usato sull'equivalente di ChatGPT. Questa non è solo una comparazione Claude Code versus ChatGPT Chat. Anche il Claude Opus 4.8 grezzo via API scrive codice più pulito con meno import allucinati dell'equivalente GPT-4o sugli stessi compiti. ### 4. Esperienza dello sviluppatore sull'API Se stai costruendo con l'API — non solo chattando — l'esperienza dello sviluppatore di Claude è migliore nel 2026. L'Anthropic SDK è pulito, l'endpoint di conteggio dei token è genuinamente utile per la stima dei costi, il cache dei prompt è ben implementato e risparmia denaro reale su contesti ripetuti, e la gestione degli errori è prevedibile. Per chiunque costruisca agenti in modo programmatico, il divario nella qualità dell'API conta. Non è grande, ma è coerente. ### 5. Fedeltà delle istruzioni su prompt complessi Claude gestisce system prompt sfumati con più condizioni meglio di ChatGPT. Quando ho bisogno che un agente segua un insieme di regole — "se il commento è una domanda, fai X; se è un reclamo, fai Y; se menziona i concorrenti, segnalalo per la revisione umana" — Claude analizza e applica queste ramificazioni in modo più coerente. Per prompt semplici, la differenza è minima. Per la logica condizionale complessa incorporata in un system prompt, Claude è più affidabile. ## Dove ChatGPT vince ### 1. Integrazioni consumer e plugin L'ecosistema di plugin di ChatGPT e la gamma di strumenti disponibili tramite l'interfaccia nativa sono più ampi. Se il tuo flusso di lavoro vive già in strumenti che hanno integrazioni native con ChatGPT — certi CRM, app di produttività, strumenti di ricerca — e lavori principalmente tramite un'interfaccia chat, le connessioni out-of-the-box di ChatGPT risparmiano attrito. Per gli utenti avanzati che vogliono fare tutto dall'interfaccia chat senza costruire integrazioni personalizzate, questo conta. ### 2. Modalità vocale L'Advanced Voice Mode di ChatGPT è genuinamente eccellente. Per l'uso mobile, sviluppare idee verbalmente o prepararsi per le chiamate mentre si guida, è la migliore interfaccia vocale IA che ho usato. Claude ha l'input vocale ma nulla di paragonabile alla modalità vocale conversazionale completa di GPT-4o a metà 2026. Se la voce è un'interfaccia principale per il tuo caso d'uso, ChatGPT vince chiaramente. ### 3. Generazione di immagini (tramite DALL-E) ChatGPT Plus include la generazione di immagini tramite DALL-E nello stesso abbonamento. Claude non genera immagini in modo nativo. Se vuoi un unico strumento per il lavoro testuale e visivo senza aggiungere Midjourney o un altro servizio, ChatGPT ha un vantaggio. ### 4. Familiarità e adozione Più persone hanno usato ChatGPT. Se stai introducendo strumenti IA in un team senza alcuna esperienza IA, iniziare con ChatGPT ha meno attrito — la maggior parte delle persone lo ha almeno aperto una volta. Questo non è un vantaggio di capacità, ma la velocità di integrazione è un fattore operativo reale. ## Confronto dei costi È qui che le cose diventano sfumate, e dove la maggior parte dei confronti è fuorviante. Entrambe le piattaforme hanno prezzi a livelli. A livello di API: - **Claude Haiku 4.5** e **GPT-4o mini** sono i cavalli di battaglia economici per i compiti semplici ad alto volume. Sono comparabili nella fascia di prezzo, con la scelta guidata principalmente dai requisiti del compito. - **Claude Sonnet/Opus** e **GPT-4o** sono il livello medio-alto. Claude ha il [cache dei prompt](/prompt-caching-cut-your-claude-costs-without-switching-models/) che riduce significativamente i costi sui workflow con contesto ripetuto — se i tuoi agenti riutilizzano lo stesso system prompt e la stessa finestra di contesto tra le chiamate, il prezzo con cache di Claude può essere del 50–80% più economico della tariffa senza cache. ChatGPT non ha un equivalente diretto. - Al livello più alto, Claude Fable 5 e le ultime varianti di GPT-4 sono nella stessa fascia di costo grezzo, ma la differenza di tokenizer conta — Fable 5 ha un tokenizer che conta i token diversamente dai modelli precedenti, quindi i conteggi di token di riferimento non si traducono direttamente. Conclusione sui costi: **per gli agenti in produzione con alto volume di chiamate, il cache dei prompt di Claude lo rende materialmente più economico** sui carichi di lavoro che riutilizzano il contesto. Per il puro pay-per-call su contesti freschi, sono abbastanza vicini da far sì che le prestazioni debbano guidare la scelta, non il prezzo di listino. Il framework che uso per valutarlo è nell'[articolo sulla matematica dei costi degli agenti IA](/ai-agent-cost-math-when-haiku-beats-sonnet/). ## La matrice decisionale | Caso d'uso | Vincitore | |---|---| | Costruzione di agenti IA in produzione | Claude | | Programmazione complessa e architettura | Claude | | Analisi di documenti con contesto lungo | Claude | | Assistente chat con integrazioni di plugin | ChatGPT | | Workflow con voce come interfaccia principale | ChatGPT | | Immagini + testo in un'unica interfaccia | ChatGPT | | Automazione guidata da API su larga scala | Claude | | Integrazione del team senza esperienza IA | ChatGPT | | Agenti rivolti ai clienti in produzione | Claude | | Efficienza dei costi su pipeline ad alto volume | Claude (con cache) | ## La mia risposta reale Uso [Claude](/recommends/claude) per tutto in produzione. Non perché vinca ogni benchmark — non è così — ma perché: 1. I miei agenti seguono le istruzioni del system prompt in modo sufficientemente affidabile da farmi passare quasi nessun tempo a ripulire output allucinati o fuori tema. 2. Lo stack Cloudflare Workers + Claude API costa meno di $100/mese per il mio carico di lavoro combinato, e il cache dei prompt ha ridotto i costi sui miei workflow più pesanti di oltre la metà. 3. Claude Code è diventato la mia interfaccia di programmazione principale, e avere lo stesso modello disponibile sia per lo sviluppo che per la produzione semplifica il modello mentale. 4. Per i compiti con contesto lungo — leggere PDF, sintetizzare tra documenti, mantenere la coerenza in workflow a più passaggi — Claude gestisce la finestra completa di 200K meglio di quanto ho sperimentato altrove. Se gestissi un team che ha bisogno di strumenti assistiti dall'IA senza costruire infrastrutture personalizzate, probabilmente li metterei su ChatGPT Plus — l'ampiezza dei plugin out-of-the-box e la modalità vocale sono genuinamente utili a livello consumer. Ma per costruire cose piuttosto che usarle semplicemente, Claude è la base giusta. ## Domande frequenti ### Claude è più intelligente di ChatGPT? Nessuno dei due è universalmente più intelligente. Claude è migliore nel ragionamento con contesti lunghi, nel rispetto delle istruzioni e nella programmazione. ChatGPT (GPT-4o) è migliore nei compiti multimodali che coinvolgono immagini e voce. I benchmark specifici si alternano tra loro ad ogni nuova versione del modello. La domanda più utile è quale modello è migliore per il tuo compito specifico. ### Posso usare sia Claude che ChatGPT? Sì, e per alcuni workflow potresti volerlo. L'API di Claude e l'API di OpenAI sono entrambe semplici da integrare. Alcuni team usano Claude per i backend degli agenti e ChatGPT per le interfacce chat rivolte agli utenti con integrazioni. Detto questo, gestire due provider IA aggiunge complessità operativa — gestione delle credenziali, tracciamento dei costi, differenze di comportamento da gestire. Inizia con uno. ### Quale è migliore per la scrittura di contenuti? Claude, nella mia esperienza. Produce output che suona meno generico, mantiene uno stile specifico meglio quando vengono forniti esempi e gestisce i contenuti in formato lungo in modo più coerente. Per contenuti social brevi o email dove entrambi funzionerebbero, la differenza è piccola. ### Claude ha un livello gratuito? Sì — Claude.ai ha un livello gratuito con limiti di messaggi. [Gli abbonamenti Claude Pro e Max](/recommends/claude) rimuovono i limiti e aggiungono accesso prioritario, caricamento di file e la finestra di contesto completa. ChatGPT ha similmente un livello gratuito con accesso a GPT-4o limitato dall'utilizzo. ### Dovrei passare da ChatGPT a Claude? Se usi principalmente l'IA come interfaccia chat e sei soddisfatto di ChatGPT, il costo del passaggio potrebbe non valerne la pena a meno che tu non abbia un'esigenza specifica che Claude gestisce meglio. Se stai costruendo automazioni, agenti o facendo lavoro di programmazione, raccomanderei vivamente di provare Claude — il comportamento dell'agente e l'esperienza dello sviluppatore fanno una differenza significativa per i carichi di lavoro in produzione. --- ## Come costruire un servizio prodottizzato: il mio framework per trasformare l'esperienza in entrate scalabili Source: https://alejandrorioja.com/it/productized-service-how-to-package-your-expertise/ Published: 2026-07-16 Tags: Entrepreneurship, Marketing TL;DR: Un servizio prodottizzato è un'offerta a ambito fisso e prezzo fisso che consegni nello stesso modo ogni volta. Quattro passi: trova il lavoro per cui i clienti ti assumono già ripetutamente, definisci duramente i confini dell'ambito, stabilisci il prezzo in base al valore del risultato (non alle ore), e costruisci il sistema di consegna prima di vendere al prossimo cliente. La maggior parte dei consulenti salta il quarto passo e rimane bloccata a scambiare tempo per denaro. Quello è l'unico passo che crea davvero scala. ## Indice _Pubblicato nel luglio 2026._ **TL;DR:** Un servizio prodottizzato è un'offerta a ambito fisso e prezzo fisso che consegni nello stesso modo ogni volta. Quattro passi: trova il lavoro per cui i clienti ti assumono già ripetutamente, definisci duramente i confini dell'ambito, stabilisci il prezzo in base al valore del risultato (non alle ore), e costruisci il sistema di consegna prima di vendere al prossimo cliente. La maggior parte dei consulenti salta il quarto passo e rimane bloccata a scambiare tempo per denaro. Quello è l'unico passo che crea davvero scala. **[Nota dell'operatore]** Ho trascorso anni facendo consulenze personalizzate — ognuna con un ambito diverso, un prezzo diverso, una consegna diversa. Il risultato era un'attività che richiedeva la mia attenzione diretta su ogni progetto. La prodottizzazione ha cambiato tutto: trasformare il mio lavoro più richiesto in offerte definite con deliverable chiari, prezzi fissi e un playbook di consegna ripetibile. Ecco il framework esatto e gli errori che ho commesso costruendolo. ## Cos'è davvero un servizio prodottizzato Un servizio prodottizzato non è un retainer. Non è un abbonamento. È un'offerta definita e ripetibile con un ambito fisso, un prezzo fisso e un processo di consegna documentato abbastanza bene da funzionare nello stesso modo ogni volta. Il contrasto con la consulenza personalizzata: invece di "facciamo strategia di automazione IA per $X–Y a seconda dell'ambito," vendi "una roadmap di automazione IA: un audit scritto di 5 flussi di lavoro, raccomandazioni di build prioritizzate e una chiamata di consegna di 30 minuti, per 2.500 €." Ambito fisso. Prezzo fisso. Cronoprogramma fisso. L'unica variabile è se il cliente dice sì. La differenza da un retainer è che è basato su progetto. Inizio chiaro. Fine chiaro. Nessuna fatturazione mensile aperta, nessuna deriva dell'ambito, nessuna conversazione "puoi dare un'occhiata anche a questo?" dopo i fatti. Cosa lo rende scalabile: il sistema, non l'offerta. Un'offerta a prezzo fisso è solo lavoro personalizzato con prezzo rinegoziato. Un servizio prodottizzato ha un playbook di consegna dietro. ## Passo 1: Trova ciò per cui i clienti ti assumono già Il servizio prodottizzato più facile da costruire è quello che stai già consegnando ripetutamente ma trattando come lavoro personalizzato ogni volta. Scorri i tuoi ultimi 10–15 clienti o progetti e cerca modelli: - Quale problema emerge più spesso? - Quale deliverable produci più frequentemente? - Quale tipo di incarico va più liscio e riceve il miglior feedback dai clienti? Per me, il modello era chiaro: i clienti continuavano a chiedere la stessa cosa — aiuto per mappare i loro processi, scegliere quali automatizzare e selezionare gli strumenti giusti. Lo facevo ripetutamente ma con un ambito diverso ogni volta. Quel modello è il tuo punto di partenza. Non un nuovo servizio che pensi il mercato abbia bisogno. Ciò che stai già facendo. Un filtro: prodottizza solo il lavoro in cui il risultato è in gran parte lo stesso per tutti i clienti. Se ogni cliente riceve un deliverable completamente diverso, il lavoro non è ancora prodottizzabile — è ancora genuinamente personalizzato. Va bene; significa solo che il lavoro di definizione viene prima. ## Passo 2: Definisci i confini dell'ambito — e rispettali Qui è dove la maggior parte dei consulenti fallisce. Definiscono l'offerta vagamente, lasciano l'ambito aperto all'interpretazione e finiscono nelle stesse conversazioni di deriva dell'ambito di prima. Un servizio prodottizzato richiede confini di ambito rigidi. Definisci cosa è incluso e cosa non lo è, per iscritto, prima della prima chiamata di vendita. Esempio di definizione dell'ambito per uno sprint di strategia di automazione IA: **Incluso:** - Chiamata di intake strutturata di 60 minuti - Audit scritto di fino a 5 flussi di lavoro - Roadmap di automazione prioritizzata con raccomandazioni di strumenti - Valutazione build-vs-buy per i 3 candidati principali - Chiamata di consegna walkthrough di 30 minuti **Non incluso:** - Implementazione (costruzione di agenti o integrazioni) - Revisioni dopo la consegna - Più di 5 flussi di lavoro - Lavoro al di fuori dell'ambito di automazione concordato L'elenco "non incluso" conta quanto l'elenco "incluso." Quando un cliente chiede qualcosa al di fuori dei confini, hai due scelte: dire che è fuori da questa offerta, o creare un add-on con il proprio ambito e prezzo. Quello che non fai è assorbirlo. Questo sembra scomodo all'inizio. Sei abituato a dire sì per tenere i clienti soddisfatti. La prodottizzazione richiede di dire "quello è un incarico separato" — e di sostenerlo in modo coerente. ## Passo 3: Stabilisci il prezzo in base al valore del risultato, non alle tue ore La fatturazione oraria e i servizi prodottizzati non si mescolano. Nel momento in cui inizi a calcolare in base al tuo tempo, hai di nuovo reso il lavoro personalizzato. Tre variabili per stabilire il prezzo di un'offerta prodottizzata: 1. **Il costo per il cliente di non risolvere il problema.** Una roadmap di automazione IA che libera 4.000 €/mese di efficienza operativa vale migliaia per l'acquirente. Le tue 8 ore di lavoro sono l'ancora di prezzo sbagliata. 2. **Cosa i compratori spendono per risultati comparabili.** Non quello che fanno pagare i concorrenti — quello che i clienti spendono effettivamente per risultati simili da consulenti, executive frazionari o software che risolve parzialmente il problema. Questo stabilisce il tuo soffitto. 3. **Il tuo piano minimo.** Quanto devi guadagnare su questa offerta perché valga la tua attenzione, tenendo conto del tempo di consegna, della gestione del cliente e dei costi generali? Questo stabilisce il tuo piano. Stabilisci il tuo prezzo in quella fascia. Per le prime offerte prodottizzate, inizia nel mezzo. Man mano che raccogli testimonianze e affini la velocità di consegna, spostati verso il soffitto. Non scontare. Se qualcuno non può permettersi l'offerta, non è il cliente giusto per essa. Puoi costruire un'offerta a prezzo più basso per un segmento diverso — ma non diluire l'offerta principale con sconti ad-hoc, o torni ai prezzi personalizzati. ## Passo 4: Costruisci il sistema di consegna prima della prossima vendita Questo passo è ciò che determina se hai un servizio prodottizzato o solo un incarico a prezzo fisso. Dopo la tua prima consegna — prima di vendere al prossimo — fai questo: 1. **Documenta ogni passo in ordine.** Non un contorno vago. Una checklist abbastanza dettagliata da permettere a qualcuno che conosce il dominio di eseguire l'80% del processo. Le tengo in [Notion](/recommends/notion) — una pagina per ogni passo del flusso di lavoro, con template, esempi di output e alberi decisionali per i giudizi difficili. 2. **Identifica cosa ha richiesto più tempo del dovuto.** Ogni prima consegna è più lenta del necessario. Trova i colli di bottiglia e sistematizzali: moduli di intake, template di deliverable, framework pre-costruiti. 3. **Costruisci il processo di intake strutturato.** Ottenere le informazioni del cliente in un modulo standardizzato prima della chiamata è ciò che rende la consegna prevedibile. La chiamata è per domande di chiarimento, non raccolta di informazioni. 4. **Crea il template del deliverable.** Ogni cliente riceve la stessa struttura di output. Il contenuto varia; la struttura no. Questo rende la consegna veloce e l'output coerente e professionale ogni volta. Se salti questo passo e vendi semplicemente il prossimo, stai ancora facendo lavoro personalizzato — hai solo dato un prezzo fisso. Il sistema è ciò che lo rende davvero scalabile. ## Cosa sblocca davvero la prodottizzazione Il vantaggio principale non è un fatturato più alto. È un fatturato migliore: domanda prevedibile, consegna più rapida, meno conversazioni di negoziazione e la capacità di dire no ai clienti che vogliono qualcosa al di fuori dell'offerta. Un secondo vantaggio: la documentazione di consegna diventa proprietà intellettuale. Il playbook che costruisci per un'offerta di consulenza prodottizzata è la maggior parte del contenuto di un corso o programma di formazione. L'ho fatto con la consulenza in automazione IA — il playbook di consegna è diventato direttamente la spina dorsale del curriculum del mio corso AI Agents for Beginners. Un terzo vantaggio: leva. Con un sistema documentato, puoi formare qualcuno per eseguire parti della consegna — l'audit, la ricerca, la redazione di documenti — mentre ti concentri sulle chiamate di intake e consegna. Questo è l'inizio dell'uscita dal tapis roulant uno-per-uno di tempo per denaro. ## Gli strumenti che uso per gestire le offerte prodottizzate **[Airtable](/recommends/airtable)** — una riga per incarico cliente, tracciando stato, link ai deliverable e pagamenti. Scala da uno a cinquanta clienti senza complessità. **[Notion](/recommends/notion)** — playbook di consegna e workspace orientati al cliente. Ogni cliente riceve un workspace Notion condiviso costruito da un template affinato attraverso consegne ripetute. **[ConvertKit](/recommends/convertkit)** — gestione della lista d'attesa e sequenze di follow-up. Quando un'offerta è piena (la capacità si riempie rapidamente con lavoro a ambito fisso), una sequenza di lista d'attesa mantiene i lead caldi coinvolti fino alla prossima apertura. ## Gli errori più comuni **Prodottizzare prima di aver consegnato abbastanza volte.** Se non hai fatto questo lavoro 3–5 volte, non conosci ancora l'ambito reale. Consegnalo prima come lavoro personalizzato. Impara dove sono i confini. Poi definisci il prodotto. **Lasciare l'ambito vago.** Un servizio prodottizzato con ambito indefinito è un incarico personalizzato a prezzo fisso — che è il peggio di entrambi i mondi. Definisci cosa è incluso, definisci cosa non lo è, mettilo per iscritto e mettilo sulla pagina di vendita. **Dire sì alle richieste fuori ambito.** Quando un cliente chiede di più, crea un add-on con il proprio ambito e prezzo. Non assorbirlo questa volta soltanto. **Saltare il sistema di consegna.** Non hai finito dopo la prima consegna. Costruisci il playbook prima di vendere il secondo. Il sistema è ciò che fa il prodotto. ## FAQ ### Con quante offerte prodottizzate dovrei iniziare? Una. Costruiscila, consegnala, affina il sistema, raccogli testimonianze, poi considera una seconda. La maggior parte delle persone che ne lancia due insieme finisce con due sistemi a metà e nessuna testimonianza per nessuno dei due. ### Ho bisogno di una landing page prima di iniziare a vendere? No. Per le prime 5–10 vendite, un PDF di una pagina o un'e-mail ben scritta è sufficiente. Non lasciare che la costruzione di un sito web sia il motivo per cui non hai ancora venduto nulla. ### Cosa faccio se un cliente vuole qualcosa al di fuori dell'ambito? Digli che è un incarico separato. Quota un add-on sul posto o pianifica una chiamata di scoping. Non assorbirlo nel progetto corrente. La disciplina nel mantenere l'ambito è ciò che fa funzionare il modello. ### Come ottengo il primo cliente? Racconta dell'offerta a 10 persone che conoscono il tuo lavoro — conversazioni calde con persone che si fidano di te o conoscono qualcuno che ne ha bisogno. La prima vendita viene quasi sempre da una conversazione diretta, non da una landing page. Una volta che hai un caso di studio, [l'approccio di vendita guidato dal fondatore](/founder-led-sales-how-to-reach-decision-makers/) inizia a scalarlo. ### Posso prodottizzare qualcosa che ho fatto solo una volta? No. Non capisci ancora l'ambito reale. Consegnalo due o tre volte in più come lavoro personalizzato, poi formalizza ciò che hai imparato nel prodotto. --- **Prossimi passi:** Il mio [corso AI Agents for Beginners](/course/) copre i sistemi di automazione che rendono scalabile la consegna prodottizzata. Il [programma cowork](/cowork/) è per gli operatori che costruiscono aziende guidate da sistemi e vogliono un ambiente strutturato per farlo. --- ## Strategia di lead generation su LinkedIn: come ottengo clienti B2B senza pubblicità a pagamento Source: https://alejandrorioja.com/it/linkedin-lead-generation-strategy/ Published: 2026-07-14 Tags: Marketing, Growth, Entrepreneurship TL;DR: LinkedIn è il canale gratuito con la maggiore leva per la generazione di lead B2B — a patto di trattarlo come un motore di fiducia piuttosto che come uno sparatore di messaggi freddi in massa. Ottimizza il tuo profilo come una landing page, pubblica in modo coerente su un angolo della tua competenza e costruisci una breve sequenza di contatto che guida con valore. L'effetto composto richiede 60–90 giorni per farsi sentire, poi funziona quasi da solo. Gli annunci a pagamento sono facoltativi; un profilo solido e un feed di contenuti utili non lo sono. ## Indice _Pubblicato nel luglio 2026._ **TL;DR:** LinkedIn è il canale gratuito con la maggiore leva per la generazione di lead B2B — a patto di trattarlo come un motore di fiducia piuttosto che come uno sparatore di messaggi freddi in massa. Ottimizza il tuo profilo come una landing page, pubblica in modo coerente su un angolo della tua competenza e costruisci una breve sequenza di contatto che guida con valore. L'effetto composto richiede 60–90 giorni per farsi sentire, poi funziona quasi da solo. Gli annunci a pagamento sono facoltativi; un profilo solido e un feed di contenuti utili non lo sono. **Prospettiva dell'operatore:** Ho usato LinkedIn per generare richieste di consulenza, acquirenti di corsi e conversazioni di partnership — tutto senza pubblicare un singolo annuncio. Ciò che funziona non è un trucco né uno strumento; è mostrarsi come qualcuno genuinamente utile in uno spazio che i tuoi acquirenti già frequentano. Questo è il manuale esatto che uso e l'ordine in cui lo eseguirei se ricominciassi da zero oggi. ## Perché LinkedIn nel 2026 La portata organica di LinkedIn si è mantenuta meglio di quasi ogni altra piattaforma. Un post di una persona con alcune centinaia di follower rilevanti può ancora raggiungere migliaia di professionisti mirati — qualcosa che su molti altri canali costa denaro reale. L'algoritmo continua a premiare i contenuti ricchi di competenza che generano salvataggi e condivisioni, non solo like. Per il B2B nello specifico, LinkedIn non ha un sostituto credibile: - I decision maker sono più raggiungibili qui che su qualsiasi altra piattaforma. - Il segnale di intento è professionale — le persone sono in "modalità lavoro", non a scorrere senza meta. - Un commento o un post crea un registro pubblico del tuo pensiero che i prospect possono trovare settimane o mesi dopo. - Le InMail e le richieste di connessione rimangono tra i meccanismi di prospezione con il costo di acquisizione più basso disponibili. Il caveat: la stessa apertura che rende LinkedIn prezioso lo riempie anche di outreach di massa, post generici di thought leadership e pitch appena velati. L'asticella per distinguersi è bassa. La maggior parte delle persone semplicemente non la supera. ## Passo 1: Sistemare il profilo prima di pubblicare qualsiasi cosa Il tuo profilo LinkedIn è la prima cosa che un prospect legge quando riceve la tua richiesta di connessione o si imbatte in un post che hai scritto. Se non comunica immediatamente a chi aiuti e come, tutto il resto che fai viene compromesso. I quattro punti che contano di più: 1. **Titolo** — Non la tua qualifica. La formula che funziona: _[Cosa faccio] per [chi] così possono [risultato]_. "Aiuto i fondatori SaaS B2B a chiudere i loro primi 10 contratti enterprise senza un team di vendita" è ricercabile, specifico e immediatamente auto-qualificante. 2. **Immagine di copertina** — Usala per rafforzare lo stesso messaggio. Un visual pulito con la tua nicchia o una breve dichiarazione di prova batte un gradiente generico. 3. **Sezione "Info"** — Scrivi in prima persona. Due brevi paragrafi: cosa fai e per chi, poi uno o due punti di prova (clienti, risultati, traguardi — reali). Termina con un chiaro invito all'azione: "Scrivimi un DM se stai cercando di fare X." 4. **Sezione In evidenza** — Fissa uno o due elementi: un lead magnet, il tuo post migliore, un case study, un link di prenotazione. Questo è spazio di prima scelta che la maggior parte delle persone lascia vuoto. Il test: leggi il tuo profilo come uno sconosciuto. In 10 secondi, riescono a capire cosa fai, per chi lo fai e cosa fare dopo? Se no, continua a modificare. ## Passo 2: Pubblica su un angolo, in modo coerente L'errore LinkedIn più comune è pubblicare in modo casuale — un consiglio di marketing il lunedì, una citazione motivazionale il mercoledì, un pitch di prodotto il venerdì. L'algoritmo ti ignora e anche il tuo pubblico. Ciò che funziona è scegliere un angolo specifico della tua competenza e appropriartene. Pubblica da quell'angolo tre o quattro volte a settimana per 90 giorni. Volume e coerenza battono ispirazione e rifinitura nelle fasi iniziali. ### Il mix di contenuti che genera effetto composto | Formato | Usalo per | Perché funziona | | --- | --- | --- | | Post di testo breve (3–5 righe) | Opinioni controcorrente, framework rapidi, lezioni dal lavoro recente | Ampia portata, basso sforzo di consumo, genera commenti | | Post lista | Ripartizioni passo dopo passo, confronti, strumenti | Salvataggi e condivisioni; favorito dall'algoritmo | | Post storia | Una situazione specifica che ho vissuto, cosa ho fatto, cosa è successo | Costruisce fiducia più velocemente di qualsiasi altro formato | | Articolo lungo | Guide approfondite, spiegazioni sempreverdi | Indicizzato dalla ricerca; ti posiziona come esperto nel tempo | | Carosello (documento) | Framework visivi, riepiloghi di post più lunghi | Il tasso di salvataggio più alto di tutti i formati | Il rapporto che uso: 70% post brevi e liste, 20% storie, 10% formato lungo o caroselli. I post lunghi non ottengono molta portata ma si accumulano nel tempo nella ricerca e nelle condivisioni via DM. ## Passo 3: Costruisci la tua base di connessioni in modo intenzionale Far crescere il giusto seguito su LinkedIn è diverso dal farlo crescere in termini di dimensioni. Mille follower che sono esattamente il tuo acquirente valgono più di diecimila che sono tuoi pari o osservatori casuali. I miei criteri di targeting: - Decision maker nei settori che servo - Fondatori e operatori in aziende nella fascia di fatturato con cui lavoro - Connessioni di secondo grado da clienti e collaboratori esistenti (la fonte più calda) - Persone che interagiscono con concorrenti o colleghi nel mio spazio Invio 15–20 richieste di connessione al giorno, ognuna con una nota di una riga che chiarisce perché mi sto connettendo. Non un pitch — solo contesto: "Ho visto il tuo commento su [argomento], in linea con ciò su cui lavoro — felice di connetterci." Quella nota porta il tasso di accettazione dal ~30% (generico) al ~55–65% (specifico). La nota ha al massimo due frasi. Non connetterti con tutti. Una lista di connessioni gonfiata piena di account non qualificati ti danneggia effettivamente — l'algoritmo di LinkedIn distribuisce parzialmente i tuoi post alle tue connessioni, quindi un pubblico di bassa qualità sopprime la tua portata. ## Passo 4: Sequenzia il tuo outreach — l'approccio dei tre tocchi Una volta che qualcuno si connette, l'obiettivo non è fare subito un pitch. È avviare una conversazione che potrebbe, nel tempo, portare a una riunione. Le persone che trattano la connessione come un permesso per incollare un deck di vendita avvelenano ogni punto di contatto successivo. La sequenza che uso: **Tocco 1 (Giorno 1, entro 24 ore dalla connessione):** Invia un breve messaggio di benvenuto caloroso. Fai riferimento al motivo per cui ti sei connesso e condividi una risorsa utile — un post, un framework, un articolo — pertinente a qualcosa che hanno condiviso. Nessuna richiesta. Terminalo come un'affermazione, non come una domanda. **Tocco 2 (Giorni 5–7):** Interagisci genuinamente con uno dei loro post — non solo un like, un commento riflessivo reale che aggiunge alla conversazione. Questo mantiene il tuo nome visibile nel loro feed senza inviare un altro DM. **Tocco 3 (Giorni 14–21):** Fai un follow-up in DM con una richiesta morbida e specifica. Una domanda chiara e facile da rispondere, legata a qualcosa di rilevante che hai notato nel loro lavoro. Se i tempi sono giusti e il dolore è reale, è qui che si prenotano le riunioni. Altrimenti, vai avanti — l'account è caldo e conoscono il tuo nome. L'errore che vedo costantemente: saltare i tocchi 1 e 2 e passare direttamente a un messaggio call-to-action nel momento in cui qualcuno si connette. Questa non è generazione di lead; è una tassa sulla reputazione. ## Passo 5: Converti le conversazioni in riunioni Una buona conversazione in DM ha bisogno di un'uscita pulita verso un invito in calendario. Nel momento in cui qualcuno mostra interesse genuino, è allora che fai la richiesta. Il messaggio che converte: > "Sembra che [cosa specifica che hanno detto] sia reale per te. Ho aiutato alcune aziende in situazioni simili — felice di passare 20 minuti a spiegare come l'abbiamo affrontata, senza pitch, solo per vedere se è rilevante. [link di prenotazione] — prendi un posto se ti è utile." Breve, poco impegnativo, facile da accettare. Il link di prenotazione elimina l'attrito nella pianificazione che uccide metà delle riunioni che dovrebbero avvenire. ## Cosa non fare I comportamenti che fanno ignorare, segnalare o bannare gli account: 1. **Richieste di connessione di massa senza contesto** — LinkedIn limiterà il tuo account e il tuo tasso di accettazione crollerà. 2. **DM con pitch prima** — Il primo messaggio non è il posto per presentare il tuo prodotto, il tuo prezzo o il tuo link al calendario. 3. **Engagement pod** — L'engagement falso gonfia le metriche di vanità e viene penalizzato algoritmicamente. 4. **Pubblicare ogni giorno senza punto di vista** — Il volume senza prospettiva è rumore. Un post a settimana con vera intuizione batte sette "opinioni calde" a settimana senza sostanza. 5. **Automatizzare l'outreach** — Il rilevamento dei bot di LinkedIn è diventato aggressivo. Gli strumenti di connessione automatizzati e le sequenze DM scritte da IA su larga scala vengono segnalati. La sequenza nel Passo 4 richiede circa 30 minuti al giorno e ha un rapporto segnale-rumore che nessuno strumento può eguagliare. ## Misurare ciò che conta davvero Metriche di vanità da ignorare: impressioni, visualizzazioni del profilo, conteggio dei follower. I numeri che ti dicono se il sistema funziona: - **Tasso di accettazione delle connessioni** — obiettivo 50%+ con nota; se è inferiore al 30%, riscrivi la nota. - **Tasso di risposta ai messaggi di follow-up** — 20–30% è salutare per un elenco ben mirato. - **DM in entrata al mese** — persone che ti contattano grazie ai tuoi contenuti. Tieni traccia mese per mese. - **Riunioni prenotate da LinkedIn al mese** — l'unico numero che si correla ai ricavi. Tengo traccia di questo in una semplice tabella di Notion. L'obiettivo nei primi 90 giorni è raggiungere un DM in entrata a settimana e una riunione prenotata al mese solo da LinkedIn. Al terzo mese, se i contenuti funzionano, quei numeri salgono senza uno sforzo proporzionalmente maggiore. ## Il bilancio dell'operatore LinkedIn funziona per la generazione di lead B2B perché è l'unico network professionale in cui la portata organica ha ancora peso e dove la tua reputazione si accumula pubblicamente nel tempo. La meccanica è semplice: un profilo che spiega a chi aiuti, contenuti che dimostrano che sai di cosa stai parlando e una sequenza di contatto che guida con valore invece di un pitch. Fallo in modo coerente per 90 giorni e i contatti in entrata iniziano ad arrivare. Fallo per un anno e diventa una delle tue fonti più affidabili di conversazioni qualificate — senza budget pubblicitario. --- **Correlato:** [Vendita guidata dal fondatore](/founder-led-sales-how-to-reach-decision-makers/) · [Come costruire un brand personale](/how-to-build-a-personal-brand/) · [Strategia di outreach](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) --- ## Come ho costruito Courtlines: un SaaS per la gestione di club, sviluppato con Claude Source: https://alejandrorioja.com/it/how-i-built-courtlines-a-club-management-saas-with-claude/ Published: 2026-07-11 Tags: AI Agents, Case Study TL;DR: Courtlines è il sistema operativo per club e centri di sport con racchetta: prenotazioni, abbonamenti, coaching, punto vendita ed eventi sotto un unico tetto personalizzato. L'ho costruito da operatore solitario con Claude come partner di sviluppo. La lezione: l'AI non mi ha solo fatto programmare più in fretta, ha cambiato la dimensione del prodotto che una sola persona può credibilmente lanciare e gestire. ## Indice dei contenuti _Aggiornato a luglio 2026._ **In sintesi:** Courtlines è il sistema operativo per club e centri di sport con racchetta: prenotazioni, abbonamenti, coaching, punto vendita ed eventi sotto un unico tetto personalizzato. L'ho costruito da operatore solitario con Claude come partner di sviluppo. La lezione: l'AI non mi ha solo fatto programmare più in fretta, ha cambiato la dimensione del prodotto che una sola persona può credibilmente lanciare e gestire. **[Il punto di vista dell'operatore]** Gestisco oltre 30 agenti in produzione tra un brand di consulenza e Pickleland, la struttura di pickleball che gestisco nell'area metropolitana di Austin, in Texas. Gestire una struttura reale mi ha insegnato esattamente quanto sia scadente il software per club come il mio, così ho costruito il software che avrei voluto avere. Questa è la storia di [Courtlines](https://courtlines.com), di cosa fa e di come appoggiarmi a Claude abbia permesso a una sola persona di costruire qualcosa che di norma richiede un team. ## Perché un club ha bisogno di un sistema operativo, non di un'app Se non hai mai gestito una struttura sportiva, il problema del software è invisibile. Da fuori sembra che «la gente prenoti i campi». Da dentro, un club è un piccolo business disordinato con una dozzina di ingranaggi che devono tutti concordare tra loro. Un socio prenota un campo. Quella prenotazione deve sapere se è iscritto a un piano di abbonamento, se ha dei crediti, se il campo è già occupato per un corso, se è assegnato un coach e se la reception ha modificato manualmente il prezzo. Quando si presenta, qualcuno gli batte alla cassa un tubo di palline: quello è il punto vendita. Iscrive il figlio a un programma junior: quelli sono eventi e account familiari. Compra un pacchetto da 10 lezioni: quello è un pacchetto di coaching con la sua logica di pagamento al coach. Porta un amico: quello è un funnel di iscrizione. La maggior parte dei club gestisce tutto questo con tre o quattro strumenti scollegati, più un foglio di calcolo, più una chat di gruppo. Il sistema di prenotazione non sa nulla del punto vendita. Il punto vendita non sa nulla degli abbonamenti. A fine mese i conti di nessuno tornano. **Courtlines è la risposta alla domanda «e se tutto questo fosse un unico sistema?»** Non è un'app di prenotazione con funzionalità aggiunte a posteriori: è un unico sistema operativo dove il calendario, gli abbonamenti, la cassa, i pagamenti ai coach e le pagine pubbliche degli eventi sono tutti gli stessi dati di base. Questa è l'intera tesi, ed è il claim sul sito: il sistema operativo per club e centri sportivi. ## Cosa fa davvero Courtlines Ad alto livello, [Courtlines](https://courtlines.com) offre a un club: - **Una griglia campi in drag-and-drop** per la reception: ogni prenotazione, corso e blocco su un'unica schermata che un amministratore può riorganizzare in tempo reale. - **Prenotazione e gioco libero** per i soci, inclusi i casi limite scomodi ma essenziali: prenotazioni ricorrenti, liste d'attesa, finestre di cancellazione e crediti. - **Abbonamenti e fatturazione**: piani, account familiari, login per bambini e ragazzi collegati a un genitore, e la gestione dei solleciti che evita che i ricavi si disperdano silenziosamente. - **Coaching**: pacchetti di lezioni, pianificazione e pagamenti automatici ai coach indipendenti. - **Punto vendita**: una cassa vera per il pro shop e la caffetteria, collegata alla stessa scheda cliente di tutto il resto. - **Eventi e pagine pubbliche**: corsi, campionati e tornei con pagine pubbliche che le persone possono trovare e a cui possono iscriversi. L'obiettivo di design è che la piattaforma sparisca. Un club ci mette sopra il proprio brand e, per i suoi soci, sembra semplicemente «l'app del nostro club», non «un SaaS qualsiasi per cui paghiamo». È un contrasto voluto con i concorrenti storici del settore, i vari CourtReserve e Skedda di turno, dove il software è il brand e il club è l'inquilino. Pickleland è l'inquilino numero 1. Non posso nascondermi dietro una demo: la cosa deve davvero far funzionare una struttura di cui rispondo in prima persona. Questo vincolo è stato il miglior product manager che abbia mai avuto. Puoi [vedere Pickleland qui](https://pickleland.com): è il banco di prova nel mondo reale, e ogni spigolo che un socio incontra è un bug che sento lo stesso giorno. ## La parte che mi ha sorpreso: cosa può lanciare oggi un singolo operatore Ecco la versione onesta della storia, ed è il motivo per cui scrivo questo articolo invece di lanciare in sordina. Un SaaS multi-tenant con fatturazione, punto vendita, accessi basati sui ruoli, pagamenti ai coach e un sistema pubblico di eventi non è un progetto da fine settimana. Dieci anni fa era un team finanziato da un seed di cinque-otto ingegneri per un anno. È il tipo di ambizione per cui a un fondatore solitario si dice, gentilmente, di restringere il campo a una singola funzionalità e di raccogliere capitali. L'ho costruito da solo, con **Claude come mio principale partner di sviluppo.** Non «ogni tanto ho chiesto uno snippet a ChatGPT»: intendo che Claude ha scritto la grande maggioranza del codice di questo sistema, lavorando a partire da specifiche e decisioni di prodotto che sono mie. Il mio ruolo è passato dallo *scrivere l'implementazione* al *decidere cosa è vero*: quale debba essere il modello dati, cosa un ruolo è autorizzato a fare, cosa significhi «finito» per una funzionalità e cosa sia sicuro lanciare. Il cambiamento interessante non è la velocità, per quanto sia più veloce. È **l'ambizione.** L'AI non mi ha reso uno sviluppatore 2× sulla stessa dimensione di prodotto. Ha cambiato la dimensione del prodotto che posso credibilmente costruire e, cosa altrettanto importante, *gestire e mantenere* da solo. Una base di codice scritta da un solo essere umano crollerebbe sotto il proprio peso. Una base di codice dove un partner AI tiene il dettaglio implementativo e io tengo l'architettura e le regole di sicurezza è una cosa di natura genuinamente diversa, ed è il motivo per cui un operatore solitario può ora puntare a una categoria che prima richiedeva un'azienda. Non pubblico deliberatamente qui il mio esatto manuale operativo per Courtlines: è la parte che considero un vantaggio competitivo, e preferisco che i miei concorrenti continuino a credere che serva un grande team. Ma se vuoi vedere in dettaglio la *meccanica* di come faccio girare Claude su un progetto reale, l'ho documentata tutta per una realizzazione molto più piccola: un gioco mobile che ho pubblicato negli app store. Leggi [come ho costruito Quads, un gioco da tavolo mobile, con Claude](/how-i-built-quads-a-mobile-board-game-with-claude/): stesso stile di lavoro, niente da nascondere, tutti i trucchi sul tavolo. ## I principi su cui non scendo a compromessi Anche tenendo privato il manuale, alcuni principi vale la pena enunciarli perché valgono per chiunque costruisca software serio con l'AI: **È l'essere umano a tenere le penne pericolose.** C'è un piccolo numero di azioni in cui un errore è costoso e difficile da annullare: modifiche allo schema, deploy, tutto ciò che tocca denaro o dati di produzione. Quelle restano saldamente a me. L'AI può proporle; non le può eseguire. Tracciare quella linea con chiarezza è ciò che rende sicuro dare all'AI molto margine ovunque altrove. **I test verdi sono necessari, non sufficienti.** Un flusso di prenotazione che passa ogni test unitario può comunque essere visibilmente rotto in un browser reale. La verifica più importante per un prodotto con un'interfaccia è un essere umano — o un processo supervisionato — che ci clicca davvero attraverso con dati realistici. I test sono un gradiente che impedisce alle cose di peggiorare; non sono la prova che una funzionalità funzioni. Questa l'ho imparata nel modo costoso, e ha cambiato per sempre il modo in cui definisco «finito». **Le specifiche sono la vera interfaccia.** La leva non sta nel prompting ingegnoso, sta nel mantenere documenti chiari e aggiornati su cos'è il sistema e cosa dovrebbe fare ogni sua parte. Il tempo speso a tenerli precisi si ripaga molte volte in ogni sessione futura. Se vuoi la versione più approfondita di tutto questo, è la stessa disciplina che descrivo in [come scrivere system prompt per agenti AI che non falliscono in produzione](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/). **Costruisci la cosa con cui devi convivere.** La singola decisione migliore è stata far gestire a Courtlines una struttura di mia proprietà. È facile lanciare una demo che impressiona; è impossibile nascondersi da un software da cui dipendono i tuoi stessi soci. Se costruisci con l'AI, puntala su un problema che senti in prima persona: la prova della realtà vale più di qualsiasi suite di test. ## Come tutto questo si incastra con il resto di ciò che sto costruendo Courtlines non esiste isolato. Fa parte di un piccolo ecosistema di sport con racchetta che sto costruendo: [The Court Scout](https://thecourtscout.com) è una directory verificata di campi da pickleball, pensata per essere genuinamente più accurata delle directory raccolte tramite scraping con cui compete, e Pickleland è la struttura di punta contro cui tutto viene testato. La directory aiuta i giocatori a trovare i campi; Courtlines aiuta i club dietro quei campi a funzionare davvero. Il tessuto connettivo di tutto questo è lo stesso modello operativo: un operatore solitario amplificato dall'AI, che gestisce più superficie di quanta un operatore solitario storicamente potesse. Courtlines è finora l'espressione più ambiziosa di quel modello: una piattaforma SaaS completa che, qualche anno fa, semplicemente non avrei tentato da solo. Se gestisci un club o un centro di sport con racchetta e sei stanco di cucire insieme quattro strumenti, dai un'occhiata a [Courtlines](https://courtlines.com). E se sei uno sviluppatore che si chiede fin dove si possa spingere l'AI su un prodotto reale, questo è il senso di tutto l'articolo: più lontano di quanto probabilmente pensi. ## FAQ ### Cos'è Courtlines? Courtlines è un sistema operativo multi-tenant per club e centri di sport con racchetta: pickleball, tennis, padel e oltre. Combina prenotazioni, abbonamenti, coaching, punto vendita e gestione degli eventi in un'unica piattaforma personalizzata, così che un club gestisca tutto il suo business da un solo sistema invece che da quattro strumenti scollegati. Puoi vederlo su [courtlines.com](https://courtlines.com). ### Claude ha davvero scritto la maggior parte del codice? Sì. Claude è stato il mio principale partner di sviluppo e ha scritto la grande maggioranza dell'implementazione, lavorando a partire da specifiche, architettura e decisioni di prodotto che sono mie e sotto il mio controllo. Io tengo lo schema, i deploy e la definizione di «finito»; l'AI tiene il dettaglio implementativo. È questa divisione del lavoro a rendere sostenibile la manutenzione di un SaaS di questa portata costruito da una sola persona. ### Una sola persona può davvero costruire e gestire un SaaS così grande con l'AI? Costruirlo è ora genuinamente fattibile: questa è la parte sorprendente. La sfida più grande è gestirlo e mantenerlo, perché una base di codice ampia ha bisogno di qualcuno che ne comprenda l'architettura anche quando è stata un'AI a scriverne i dettagli. La chiave è mantenere specifiche chiare e tenere il punto sul piccolo numero di azioni ad alto rischio che un essere umano deve controllare in prima persona. Fatto così, la superficie mantenibile da un solo operatore è di gran lunga più ampia di quanto fosse un tempo. ### Perché costruire il tuo software per club invece di usare CourtReserve o Skedda? Perché gestire Pickleland mi ha mostrato esattamente dove gli strumenti esistenti falliscono: il sistema di prenotazione, la cassa e gli abbonamenti non condividono un'unica fonte di verità, quindi niente si riconcilia in modo pulito. Volevo un sistema in cui tutto fosse gli stessi dati di base e in cui a essere visto dai soci fosse il brand del club, non quello del fornitore di software. È questo il divario che Courtlines è costruito per colmare. ### Dove posso imparare come lavori davvero con Claude giorno per giorno? Tengo privato il manuale dettagliato di Courtlines per ragioni competitive, ma ho documentato esattamente lo stesso stile di lavoro su un progetto più piccolo e completamente aperto: un gioco da tavolo mobile chiamato Quads. Leggi [come ho costruito Quads, un gioco da tavolo mobile, con Claude](/how-i-built-quads-a-mobile-board-game-with-claude/) per la meccanica, oppure [come decido se un'automazione vale la pena di essere costruita](/ai-agent-roi-how-i-decide-whether-automation-worth-building/) per il ragionamento sul ROI dietro tutto ciò che lancio. --- ## Come ho costruito Quads, un gioco da tavolo mobile, con Claude — da un hackathon di 2 ore all'App Store Source: https://alejandrorioja.com/it/how-i-built-quads-a-mobile-board-game-with-claude/ Published: 2026-07-11 Tags: AI Agents TL;DR: Quads è un gioco da tavolo mobile — una versione pulita del classico gioco astratto Quarto — nato come hackathon di 2 ore con un amico in Colombia e pubblicato negli app store. Questa è la versione completamente aperta di come costruisco con Claude: worktree di agenti in parallelo, una vera AI di gioco (non un LLM), design offline-first e le insidie specifiche che mi sono costate ore. ## Indice dei contenuti _Aggiornato a luglio 2026._ **In sintesi:** Quads è un gioco da tavolo mobile — una versione pulita del classico gioco astratto Quarto — nato come hackathon di 2 ore con un amico in Colombia e pubblicato negli app store. Questa è la versione completamente aperta di come costruisco con Claude: worktree di agenti in parallelo, una vera AI di gioco (non un LLM), design offline-first e le insidie specifiche che mi sono costate ore. **[Il punto di vista dell'operatore]** Gestisco oltre 30 agenti in produzione tra un brand di consulenza e Pickleland, la mia struttura di pickleball nell'area metropolitana di Austin. La maggior parte di ciò che costruisco è software gestionale serio in cui tengo il manuale privato. Quads è l'opposto: un progetto secondario divertente che posso mostrarti dall'inizio alla fine. Se vuoi vedere esattamente come lavoro con Claude, senza niente di limato, questo è l'articolo. Puoi trovare il gioco su [playquads.com](https://playquads.com). ## È iniziato come un hackathon di 2 ore in Colombia L'origine è quasi imbarazzantemente casuale. Ero in viaggio in Colombia e io e un amico ci siamo dati un hackathon di 2 ore: scegli qualcosa di piccolo, costruiscilo con l'AI, vedi fin dove arrivi. Siamo finiti su Quarto — un bellissimo piccolo gioco di strategia astratta, facile da imparare e sorprendentemente profondo. Due ore dopo avevamo un prototipo giocabile, e l'idea era troppo bella per lasciarla su un laptop. Quella che era iniziata come una sfida a tempo si è trasformata in una vera app mobile pubblicata su iOS e Android. Quell'arco — *da prototipo scherzoso a scheda nello store* — è l'intera ragione per cui penso che questo progetto valga la pena di essere raccontato. La distanza tra «idea divertente» e «cosa che degli sconosciuti possono scaricare» si è ridotta, e Quads è un caso di studio pulito su come. Prima, una breve digressione sul nome. Il gioco è una reimplementazione di **Quarto**, che è un gioco registrato di proprietà di Gigamic. Quindi la primissima decisione non tecnica è stata *non* chiamarlo Quarto in nessun punto che un cliente potesse vedere. È passato da Quarto (la meccanica) a un paio di nomi intermedi fino a **Quads** — un nome che posso usare liberamente. Se stai reimplementando un classico, risolvi la questione del marchio prima di innamorarti di un nome. ## Cos'è davvero Quads Per chi non lo conosce: Quads si gioca su una scacchiera 4×4 con 16 pezzi unici. Ogni pezzo ha quattro attributi binari — alto o basso, scuro o chiaro, quadrato o rotondo, pieno o cavo — e i 16 pezzi coprono ogni possibile combinazione esattamente una volta. Vinci completando una linea di quattro pezzi che condividono *anche solo uno* qualsiasi degli attributi. Il colpo di genio che lo rende brillante: **non scegli il pezzo che posizioni. È il tuo avversario a consegnartelo.** Poi tu consegni a lui il suo. Così ogni turno è un doppio vincolo: cerchi di posizionare il pezzo che ti è stato dato senza preparare una vittoria, mentre scegli un pezzo da dare che non regali la partita al tuo avversario. È elegante e genuinamente difficile. L'app offre quattro modi di giocare, tutti completamente offline: contro il computer su cinque livelli di difficoltà, pass-and-play su un unico dispositivo, un puzzle giornaliero e una modalità asincrona «sfida un amico». Nessun account, nessun server, nessun login. Questa decisione offline-first ha guidato gran parte dello sviluppo, ed è una grossa parte del motivo per cui una realizzazione solitaria è stata gestibile. ## La logica di gioco: un intero insieme di regole che scaturisce dalla matematica dei bit Questa è la mia parte preferita, perché è il tipo di cosa che è soddisfacente indipendentemente dal fatto che l'abbia scritta un'AI o meno. Ognuno dei 16 pezzi è semplicemente un numero intero da 0 a 15. Ognuno dei quattro bit è un attributo. Tutto qui: l'intero insieme di pezzi sono i numeri da 0 a 15, perché quattro bit danno esattamente 16 combinazioni. Il rilevamento della vittoria diventa quindi quasi banale. Per ogni linea di quattro pezzi, mantieni due accumulatori in corso: i bit che valgono `1` in *ogni* pezzo, e i bit che valgono `0` in *ogni* pezzo. Se dopo tutti e quattro uno dei due accumulatori è diverso da zero, i pezzi concordano su almeno un attributo: è una vittoria. L'intero insieme di regole si riduce a un paio di AND bit a bit. Poiché la logica è fatta di funzioni pure su numeri interi — nessun framework, nessuna interfaccia, nessuno stato — è direttamente testabile con unit test ed è banale da estendere. Quads include perfino una variante con regole della casa in cui anche i nove quadrati 2×2 contano come forme vincenti, il che è un'aggiunta di due righe sopra lo stesso trucco dei bit. Quando tu e un partner AI tenete la logica di base così pulita, aggiungere una funzionalità è un piacere invece che un rischio. ## L'avversario AI non è un LLM (ed è la scelta giusta) Ecco un momento didattico a cui tengo: **non ogni «AI» dovrebbe essere un modello linguistico di grandi dimensioni.** L'avversario di Quads è pura AI di gioco classica, e deve esserlo. A ogni turno prende due decisioni — dove posizionare il pezzo che gli è stato consegnato e quale pezzo restituire — e la difficoltà scala quanto ci pensa duramente: - **Principiante** gioca essenzialmente a caso e ti regalerà la vittoria. - I livelli intermedi aggiungono euristiche: cogli una vittoria immediata se ne esiste una, ed evita di regalare un pezzo con cui l'avversario può vincere, preferendo il pezzo che arma il minor numero di minacce future. - **Maestro e Gran Maestro** eseguono una ricerca negamax limitata — vera ricerca sull'albero di gioco — ma con un rigido **budget di nodi** così che una mossa non possa mai bloccare il thread principale del telefono. All'inizio della partita, dove la ricerca perfetta è intrattabile, ripiega su euristiche veloci; verso la fine della partita, dove l'albero è abbastanza piccolo, cerca sul serio. Due cose vale la pena rubarle da tutto questo. Primo, un modello linguistico sarebbe *peggiore* qui — più lento, più costoso, non deterministico e battibile — di cinquanta righe di negamax. Abbina lo strumento al problema. Secondo, il budget di nodi è la vera ingegneria: su un dispositivo mobile, «corretto ma occasionalmente si blocca per quattro secondi» è una funzionalità fallita. Limitare la ricerca così che una mossa sia sempre veloce, anche se occasionalmente subottimale, è la differenza tra un giocattolo e un prodotto. Sapere *quando* ricorrere a un LLM è lo stesso criterio che applico a ogni automazione: è il cuore di [come decido se una realizzazione con l'AI ne vale la pena](/ai-agent-roi-how-i-decide-whether-automation-worth-building/). ## Come faccio girare davvero Claude: agenti in parallelo nei worktree Ora la parte che tengo privata sui miei prodotti più grandi ma che qui posso mostrarti per intero. Non costruisco con una sessione di Claude alla volta. Ne faccio girare **diverse in parallelo**, ciascuna nel proprio git worktree sul proprio branch. Un agente aggiunge l'internazionalizzazione, un altro costruisce il sistema del puzzle giornaliero, un altro fa la modalità per daltonici, un altro collega il sonoro — ciascuno isolato nella propria copia di lavoro così che non possano calpestarsi a vicenda, e ciascuno viene reintegrato quando è verde. La cronologia git di Quads è un muro di commit `Merge branch 'worktree-agent-…'`, che è esattamente come appare quel flusso di lavoro visto da fuori. Il motivo per cui i worktree contano è semplice: agenti in parallelo che modificano la stessa directory di lavoro si pestano i piedi all'istante. Dai a ciascuno un checkout isolato e puoi genuinamente avere quattro funzionalità in costruzione contemporaneamente, per poi fonderle come qualsiasi altro branch. È il singolo cambiamento a maggior leva nel mio modo di lavorare: sono passato da una conversazione, una funzionalità, a una piccola flotta. Se vuoi la disciplina dietro i prompt su cui girano quegli agenti, è la stessa che descrivo in [come scrivere system prompt per agenti AI che non falliscono in produzione](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/): la leva sta in specifiche chiare e aggiornate, non nel modo di frasare astuto. ## L'insidia che mi è costata un'ora (così non ne costerà una a te) Ogni progetto ti insegna una lezione stupida e costosa. Su Quads è stata questa: **lo strumento di anteprima non mostra sempre il branch che pensi stia mostrando.** Quando fai girare più agenti in più worktree e visualizzi in anteprima il loro lavoro, l'anteprima può avviarsi da una directory *diversa* da quella in cui si trova la tua sessione corrente, così fai lo screenshot dell'app, non vedi nessuna delle tue modifiche e inizi a fare debug di un'interfaccia «mancante» che non è mai mancata. La funzionalità era a posto; l'anteprima puntava al checkout sbagliato. Ho perso tempo vero per questo prima di capire cosa stesse succedendo, e l'ho annotato nelle note del progetto stesso così che l'io del futuro (e ogni agente a cui passo il repo) controlli il target dell'anteprima *prima* di fare debug di bug fantasma. La trappola correlata: il file di configurazione che definisce quelle anteprime è condiviso tra le sessioni in parallelo, quindi due agenti che lo modificano contemporaneamente possono sovrascriversi silenziosamente le voci a vicenda. Se hai intenzione di far girare una flotta, tratta la configurazione condivisa come una risorsa contesa: ti morderà esattamente una volta, e poi mai più se scrivi la lezione da qualche parte. Quell'abitudine — catturare ogni insidia conquistata a fatica in un file durevole che la sessione successiva leggerà — è la spina dorsale silenziosa del costruire con l'AI a qualsiasi scala. Il contesto evapora tra le sessioni; le lezioni scritte no. ## I trucchi offline-first di cui vado fiero Poiché Quads non ha backend, alcuni problemi richiedevano risposte ingegnose e senza server: - **Il puzzle giornaliero** viene scelto in modo deterministico a partire dal giorno locale dell'anno, così ogni giocatore nel mondo riceve lo stesso puzzle con zero coordinamento del server. (Lezione bonus: ho pubblicato, e poi corretto subito, un errore di uno nell'ora legale in quella matematica delle date. Le date sono sempre più difficili di quanto sembrino.) - **«Sfida un amico»** codifica un puzzle in un breve codice testuale — qualcosa come `QC1-01-03-3` — protetto da un checksum così che un errore di battitura non possa produrre una sfida valida-ma-sbagliata. Il tuo amico lo digita nella propria copia dell'app e gioca la posizione esatta, interamente offline. Nessun account, nessun matchmaking, nessun server. - **Le anteprime ricche dei link** sono l'unico punto in cui ho usato un pizzico di codice server. Quando condividi un link di sfida, una singola Cloudflare Pages Function genera tag Open Graph specifici per ogni codice così che il link si espanda bene in iMessage o WhatsApp. I crawler dei social non eseguono JavaScript, quindi un'anteprima generata lato client sembrerebbe identica per ogni link — una piccola funzione risolve la cosa senza bisogno di un vero backend. Nessuno di questi è difficile una volta che lo vedi, ma ciascuno è un punto in cui la risposta pigra è «tira su un server e un database» e la risposta migliore è «fai la cosa offline ingegnosa». Evitare del tutto un backend è il motivo per cui una sola persona ha potuto pubblicare e mantenere questa cosa. ## Dall'hackathon alla scheda nello store L'ultimo tratto — la parte che nessuno ti racconta di un «progetto di 2 ore» — è tutto ciò che sta tra «funziona sul mio telefono» e «gli sconosciuti possono scaricarlo». Internazionalizzazione in otto lingue in un colpo solo. Testi dello store che non usano mai il nome registrato. Strumenti di build per gli app store, versioning e le pulizie dei permessi specifiche per piattaforma che evitano che una revisione dello store ti respinga. È poco affascinante, ed è il punto in cui molti progetti secondari muoiono in silenzio. Farlo con Claude non ha reso la checklist più corta, ma ha reso ogni voce abbastanza economica da farmela effettivamente finire. Questa è la vera storia di Quads: non che l'AI abbia scritto un gioco da tavolo — un sacco di gente sa prototiparne uno — ma che ha abbassato il costo dell'*ultimo miglio* abbastanza da far diventare uno scherzo da hackathon un prodotto pubblicato. Se hai una piccola idea su cui sei rimasto seduto, ecco tutta la mia proposta. Comincia dalla versione di 2 ore. Ti sorprenderà quanto si sia avvicinato il traguardo. E se vuoi vedere fin dove sale su per la scala questo stesso stile di lavoro, l'ho portato fino a un SaaS multi-tenant completo — [come ho costruito Courtlines, una piattaforma di gestione per club, con Claude](/how-i-built-courtlines-a-club-management-saas-with-claude/). Gioca a Quads su [playquads.com](https://playquads.com). ## FAQ ### Cos'è Quads? Quads è un gioco da tavolo mobile per iOS e Android — una reimplementazione pulita del classico gioco di strategia astratta Quarto. Giochi su una scacchiera 4×4 con 16 pezzi unici, e il colpo di scena è che è il tuo avversario a scegliere il pezzo che devi posizionare. È gratuito, con modalità in solitaria, pass-and-play, un puzzle giornaliero e sfide asincrone. Lo trovi su [playquads.com](https://playquads.com). ### Claude ha scritto l'intero gioco? Claude ha scritto la grande maggioranza del codice, lavorando a partire dal design e dalle decisioni che sono mie. Ho fatto girare diverse sessioni di Claude in parallelo, ciascuna nel proprio git worktree, costruendo funzionalità diverse che ho poi fuso insieme. La logica di gioco, l'avversario AI, l'internazionalizzazione, i suoni e il sistema dei puzzle sono stati in gran parte costruiti così e revisionati da me. ### L'avversario AI nel gioco è alimentato da un LLM? No — e deliberatamente. L'avversario usa AI di gioco classica: euristiche alle difficoltà più basse e una ricerca negamax limitata ai livelli più alti, con un rigido budget di nodi così che una mossa non blocchi mai il dispositivo. Un modello linguistico sarebbe più lento, più costoso e più debole per questo compito. Scegliere il tipo giusto di AI per il problema conta più che ricorrere sempre al modello più grande. ### Quanto ci è voluto per costruire Quads? Il primo prototipo giocabile è uscito da un hackathon di 2 ore con un amico durante un viaggio in Colombia. Trasformare quel prototipo in un'app rifinita e pubblicabile su entrambi gli app store — con internazionalizzazione, un vero avversario AI, sfide offline e conformità agli store — ha richiesto notevolmente di più, ma ogni singolo passo era abbastanza economico con l'AI da far sì che il progetto raggiungesse davvero il traguardo. ### Qual è la lezione più grande dal costruire Quads con Claude? Due cose. Primo, fai girare gli agenti in git worktree isolati così da poter costruire diverse funzionalità in parallelo senza che si calpestino a vicenda. Secondo, scrivi ogni insidia in un file durevole che la sessione successiva leggerà — il contesto evapora tra le sessioni, ma le lezioni scritte si accumulano. Per il quadro più ampio di questo stile di lavoro, vedi [come ho costruito Courtlines con Claude](/how-i-built-courtlines-a-club-management-saas-with-claude/). --- ## Come scrivere prompt di sistema per agenti IA che non falliscono in produzione Source: https://alejandrorioja.com/it/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/ Published: 2026-07-11 Tags: AI Agents TL;DR: Un prompt di sistema in produzione ha cinque livelli: identità (chi è l'agente e cosa non può fare), contesto (cosa sa dell'ambiente), compito (come appare il successo passo dopo passo), formato di output (il livello più sottovalutato) e casi limite (cosa fare quando gli input sono difettosi). La maggior parte dei prompt fallisce perché salta i livelli 4 e 5. Scrivi il formato di output prima di tutto il resto — ti obbliga a essere preciso su cosa vuoi davvero. ## Sommario _Aggiornato luglio 2026._ **TL;DR:** Un prompt di sistema in produzione ha cinque livelli: identità (chi è l'agente e cosa non può fare), contesto (cosa sa dell'ambiente), compito (come appare il successo passo dopo passo), formato di output (il livello più sottovalutato) e casi limite (cosa fare quando gli input sono difettosi). La maggior parte dei prompt fallisce perché salta i livelli 4 e 5. Scrivi il formato di output prima di tutto il resto — ti obbliga a essere preciso su cosa vuoi davvero. **[Prospettiva dell'operatore]** Gestisco oltre 30 agenti IA in produzione per il mio brand di consulenza e Pickleland, un impianto di pickleball a Pflugerville, TX. Ho riscritto più prompt di sistema di quanti ne abbia scritti — di solito perché la prima versione sembrava funzionare bene nei test e poi si degradava silenziosamente in produzione. Questo è quello che ho imparato su come scrivere prompt che durano. ## Il problema del prompt di sistema che nessuno ammette La maggior parte dei prompt di sistema per gli agenti viene scritta in circa 20 minuti, testata su due o tre esempi e poi non viene mai più toccata. Il modello viene distribuito. Per un po' funziona. Poi qualcosa cambia — gli input diventano più caoticii, il modello viene aggiornato, appare un nuovo caso limite — e l'agente inizia a produrre spazzatura. In silenzio. Su scala. Il problema non è che il prompt originale fosse cattivo. È che la maggior parte dei prompt viene scritta per dimostrare il percorso felice. Sono progettati per l'input che avevi in mente quando hai costruito l'agente, non per la distribuzione completa degli input che l'agente vedrà effettivamente. ## I cinque livelli di un prompt di sistema in produzione Penso a ogni prompt di sistema che scrivo in cinque livelli. Non devono apparire in questo ordine — ma devono essere tutti presenti. ### Livello 1: Identità L'identità dice al modello chi è e quali sono i suoi vincoli operativi. Non un personaggio di gioco di ruolo — una definizione funzionale di cosa fa e non fa questo agente. Un forte livello di identità risponde a tre domande: - Di cosa è responsabile questo agente? - Di cosa NON è esplicitamente responsabile (e dovrebbe escalare o rifiutare)? - Quali standard mantiene? Il perimetro esplicito di cosa NON è incluso è la parte che la maggior parte degli operatori salta. Senza di essa, il modello cercherà di essere utile al di fuori del suo ambito — ed è lì che le cose vanno storte. ### Livello 2: Contesto Il contesto è ciò che l'agente sa del suo ambiente che non è nel messaggio dell'utente. Include la data e l'ora correnti (da iniettare dinamicamente — non fidarti mai del senso interno del tempo del modello), lo stato rilevante dai sistemi esterni e le regole aziendali che non sono ovvie dalla descrizione del compito. La maggior parte degli agenti che esamino è povera di contesto. Non assumere. Inietta. ### Livello 3: Compito Il livello del compito descrive cosa fa l'agente, passo dopo passo. Non "aiutare i clienti" — il vero flusso decisionale. Scrivilo come un diagramma di flusso, non come una direttiva. I diagrammi di flusso sono più robusti perché riducono la necessità del modello di inferire cosa vuoi nei casi ambigui. ### Livello 4: Formato di output Questo è il livello più sottovalutato, e quello più responsabile dei fallimenti silenziosi. Se non specifichi il formato di output con precisione, il modello produrrà un output che sembra corretto a un lettore umano ma è sufficientemente incoerente da rompere l'analisi a valle. Scrivi il formato di output per primo. Per output strutturati, specifica lo schema esatto. Per output in prosa, specifica struttura, lunghezza e vincoli di tono. Per gli agenti ad alto rischio, uso l'output strutturato di [Claude](/recommends/claude) con uno schema JSON definito. ### Livello 5: Casi limite Il livello dei casi limite risponde: cosa fa l'agente quando l'input è ambiguo, incompleto, nella lingua sbagliata, ostile o chiaramente errato? Per ogni caso limite, dai al modello un percorso di risposta esplicito. ## Come mantengo i prompt di sistema nel tempo Un prompt di sistema in produzione è un documento vivo: 1. **Controllo puntuale settimanale.** Esamino da cinque a dieci output casuali di ogni agente ad alto rischio rispetto all'output atteso. 2. **Revisione dopo l'aggiornamento del modello.** Ogni volta che la versione del modello sottostante cambia, eseguo l'agente contro il golden set completo del mio [framework di valutazione](/how-i-measure-whether-an-ai-agent-is-actually-working/). 3. **Log dei casi limite.** Tengo un log degli input che l'agente ha gestito male. Quando tre o più voci condividono un pattern, aggiungo una regola esplicita. 4. **Versionamento del prompt.** Ogni modifica significativa riceve un commento di versione. ## Domande frequenti ### Quanto dovrebbe essere lungo un prompt di sistema in produzione? Abbastanza lungo da coprire tutti e cinque i livelli. Abbastanza corto da poterlo leggere in due minuti e individuare la deriva. Per la maggior parte dei miei agenti, sono 200-600 parole. ### Quando dovrei dividere un compito complesso in più agenti invece di un singolo prompt lungo? Quando il compito ha due o più modalità distinte che richiedono contesto diverso, formati di output diversi o gestione degli errori diversa. Vedi [agenti basati su eventi vs. pianificati](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) per il pattern. ### Qual è la ragione più comune per cui un prompt che funzionava nei test fallisce in produzione? Gli input di test non erano rappresentativi della distribuzione di produzione. Costruisci un set di test dal traffico di produzione reale, non da input immaginati. --- ## ROI degli Agenti AI: Come Decido se Vale la Pena Costruire un'Automazione Source: https://alejandrorioja.com/it/ai-agent-roi-how-i-decide-whether-automation-worth-building/ Published: 2026-07-09 Tags: AI Agents, Operations TL;DR: Prima di costruire qualsiasi agente AI, eseguo una verifica del ROI in quattro parti: quantificare il costo manuale, stimare il costo di costruzione, proiettare il costo di esecuzione e aggiungere una tassa di manutenzione. Il risultato è un periodo di ammortamento. Se supera sei mesi per un'attività non strategica, la elimino. La maggior parte delle idee di agenti fallisce questo test — ed è questo il punto. Costruire l'automazione sbagliata è peggio che non costruire nulla. ## Indice _Aggiornato luglio 2026._ **TL;DR:** Prima di costruire qualsiasi agente AI, eseguo una verifica del ROI in quattro parti: quantificare il costo manuale, stimare il costo di costruzione, proiettare il costo di esecuzione e aggiungere una tassa di manutenzione. Il risultato è un periodo di ammortamento. Se supera sei mesi per un'attività non strategica, la elimino. La maggior parte delle idee di agenti fallisce questo test — ed è questo il punto. **[Prospettiva dell'operatore]** Gestisco più di 30 agenti in produzione per un brand di consulenza e Pickleland, una struttura di pickleball a Pflugerville, TX. Ho abbandonato almeno tanti agenti quanti ne ho lanciati. Quelli che ho abbandonato non erano cattive idee — erano buone idee che hanno fallito la matematica. Questo framework è ciò che eseguo prima di scrivere una sola riga di codice agente. ## La domanda che nessuno pone per prima Tutti nel 2026 chiedono "come posso automatizzare questo?" La domanda migliore è "dovrei automatizzare questo, e quando si ripaga?" Un agente AI non è gratuito. Costa tempo da costruire, denaro da eseguire e attenzione continua per mantenerlo. Se l'automazione non recupera questi costi più velocemente dell'alternativa manuale, hai reso la tua operazione più complessa e costosa — non più efficiente. L'istinto di automatizzare tutto è comprensibile. Gli agenti sono genuinamente potenti, e la curva di capacità è ripida. Ma capacità e ROI sono assi diversi. ## Passo 1: Quantificare il baseline manuale Il primo numero è quanto il processo attuale costa all'anno. ``` costo_manuale_per_anno = (tempo_per_istanza × tariffa_oraria × frequenza_per_anno) + costo_errori_per_anno ``` **Tempo per istanza** è il tempo reale che qualcuno dedica — non il tempo di calendario dall'inizio alla fine. **Tariffa oraria** è il costo totale di chi svolge il lavoro. Se è il tuo tempo, usa la tua tariffa di consulenza o opportunità, non zero. **Frequenza per anno** è quante volte questa attività viene effettivamente eseguita. **Costo degli errori** è quello che la maggior parte delle persone dimentica. Esempio reale da Pickleland: inviare manualmente promozioni di eventi Facebook richiedeva 45 minuti a settimana. Alla mia tariffa di opportunità, sono $45/settimana o $2.340/anno. Questo è il baseline. ## Passo 2: Stimare il costo di costruzione onestamente Il costo di costruzione è quasi sempre sottostimato. ``` costo_di_costruzione = (ore_di_dev × tariffa_oraria) + costo_configurazione_strumenti + ore_test_e_iterazione × tariffa_oraria + ore_debug_integrazione × tariffa_oraria ``` Per il promotore di eventi Pickleland: ho stimato 6 ore per costruire, 3 ore per testare e mettere a punto, 2 ore di debug dell'integrazione. Alla mia tariffa, sono $990 in costo di costruzione. ## Passo 3: Proiettare il costo di esecuzione ``` costo_esecuzione_per_anno = (chiamate_api_per_anno × costo_per_chiamata) + costo_infrastruttura_per_anno + ore_revisione_umana × tariffa_oraria ``` **Chiamate API** sono le chiamate Claude/LLM più eventuali API di terze parti. **Infrastruttura** su Cloudflare Workers + Queues è spesso sotto i $5/mese per volume moderato. **Revisione umana** è il costo che le persone dimenticano più spesso. Per il promotore Pickleland: ~1.000 chiamate API Claude/anno. La revisione umana arriva a ~$800/anno. Costo di esecuzione totale: ~$810/anno. ## Passo 4: Applicare la tassa di manutenzione Questo è il fattore più sottostimato in ogni calcolo ROI di agente. Gli agenti si rompono. Applico un tasso fisso del 20% del costo di costruzione per anno come tassa di manutenzione. ``` costo_manutenzione_per_anno = costo_di_costruzione × tasso_manutenzione ``` Per il promotore Pickleland: $990 × 20% = $198/anno. ## La formula di ammortamento ``` risparmi_netti_annuali = costo_manuale_per_anno − costo_esecuzione_per_anno − costo_manutenzione_per_anno mesi_ammortamento = (costo_di_costruzione ÷ risparmi_netti_annuali) × 12 ``` Per il promotore di eventi Pickleland: - Costo manuale: $2.340/anno - Costo di esecuzione: $810/anno - Manutenzione: $198/anno - Risparmi netti annuali: $1.332/anno - Costo di costruzione: $990 - **Ammortamento: 8,9 mesi** Questo è limite. La mia soglia per le automazioni non strategiche è di sei mesi. ## Le mie soglie di ammortamento - **Meno di 3 mesi:** Costruire immediatamente. Questi sono rari. - **3–6 mesi:** Sì deciso. Queste sono le automazioni che si compongono. - **6–12 mesi:** Costruire se strategicamente importante. Altrimenti eliminare. - **Oltre 12 mesi:** Quasi sempre eliminare. ## Quando NON automatizzare L'errore più costoso che vedo commettere ai team è automatizzare processi instabili. Se il flusso di lavoro cambia ogni poche settimane, l'automazione blocca la versione difettosa attuale. Prima di automatizzare, chiedi: questo processo è stato stabile per almeno tre mesi? Il secondo errore è automatizzare attività a bassa frequenza con alte puntate. Terzo: non automatizzare per evitare una conversazione. ## Lo stack di agenti che esegue queste automazioni La maggior parte delle automazioni che eseguo in produzione sono su Cloudflare Workers + Queues, con [Claude](/recommends/claude) come LLM. ## FAQ ### Quale tariffa oraria dovrei usare per il mio tempo? Usa il tuo costo opportunità. Non usare zero. ### Come stimo i costi dell'API Claude prima di costruire qualcosa? Usa l'endpoint di conteggio token di Claude con un campione rappresentativo di input reali. ### Cosa conta come automazione "strategica"? Un'automazione strategica (1) serve direttamente i clienti in modo da influenzare la retention o la conversione, (2) consente una scala di operazione che non potresti raggiungere manualmente, o (3) produce dati che guidano decisioni migliori. ### Devo contare il tempo che dedico al monitoraggio dell'agente? Sì. Il tempo di monitoraggio è un costo continuo reale. ### E se l'attività è qualcosa che semplicemente odio fare? Odiare un'attività ha un costo reale. Accetterò un periodo di ammortamento più lungo per attività che detesto genuinamente, ma non è una carta bianca. --- ## Vendita guidata dal founder: come trovare e raggiungere il compratore giusto prima di costruire un team commerciale Source: https://alejandrorioja.com/it/founder-led-sales-how-to-reach-decision-makers/ Published: 2026-07-09 Tags: Entrepreneurship, Growth, Marketing TL;DR: Prima di assumere un team commerciale, devi dimostrare di saper vendere. La vendita guidata dal founder si riduce a tre cose: individuare l'unica persona che può davvero dire di sì, fare abbastanza ricerca da meritare una risposta e mettere in sequenza i canali — email per la richiesta, telefono per il follow-up urgente, LinkedIn per l'introduzione a caldo. La maggior parte delle trattative si blocca non perché il pitch era debole, ma perché è finita nella casella sbagliata. Aggira il problema e fisserai incontri che un commerciale a stipendio non riuscirebbe a ottenere. ## Indice _Pubblicato a luglio 2026._ **TL;DR:** Prima di assumere un team commerciale, devi dimostrare di saper vendere. La vendita guidata dal founder si riduce a tre cose: individuare l'unica persona che può davvero dire di sì, fare abbastanza ricerca da meritare una risposta e mettere in sequenza i canali — email per la richiesta, telefono per il follow-up urgente, LinkedIn per l'introduzione a caldo. La maggior parte delle trattative si blocca non perché il pitch era debole, ma perché è finita nella casella sbagliata. Aggira il problema e fisserai incontri che un commerciale a stipendio non riuscirebbe a ottenere. **[La lettura dell'operatore]** Ogni founder che ho visto costruire un'azienda vera ha venduto le prime trattative di persona — di solito male all'inizio, poi bene. Non c'è scorciatoia che tenga. Non puoi delegare un processo di vendita che non hai mai eseguito, perché ancora non sai a cosa risponde davvero il tuo compratore. Questo è il processo che uso e che insegno ai founder: come trovare la persona giusta, fare quel tanto di ricerca che basta a meritare una risposta e raggiungerla senza bombardare sconosciuti o comprare uno strumento di scraping. ## Perché i founder devono vendere per primi Non puoi delegare un processo che non hai mai eseguito. Se assumi un commerciale prima di aver chiuso una manciata di trattative di persona, non stai scalando un processo — stai esternalizzando la scoperta di quel processo, e paghi uno stipendio per imparare ciò che avresti dovuto imparare gratis. La vendita guidata dal founder non è una fase da sopportare finché non puoi permetterti un commerciale. È il modo in cui impari le parole esatte che usa il tuo compratore, l'obiezione che uccide nove trattative su dieci e quell'unica frase che fa drizzare le orecchie a qualcuno. Quella conoscenza diventa poi lo script, il manuale e l'asticella per le assunzioni. Saltala e la tua prima assunzione commerciale eredita un'ipotesi. La buona notizia: come founder hai un vantaggio sleale che un commerciale non avrà mai. L'hai costruita tu, la cosa. Puoi rispondere a qualsiasi domanda, piegare la roadmap durante una call e parlare con una credibilità che nessuno sconosciuto a caccia di quota può inventarsi. Il tuo compito è metterti davanti alla persona giusta abbastanza spesso da rendere concreto quel vantaggio. ## Passo 1: individua l'unica persona che può dire di sì Il motivo più comune per cui un contatto fallisce è che raggiunge il ruolo sbagliato. Il tuo messaggio non viene rifiutato — viene ricevuto da qualcuno che non ha mai avuto il potere di agire di conseguenza, e muore in silenzio. Nella maggior parte delle aziende, tre tipi di persone si frappongono tra te e una trattativa: - **Lo sponsor interno (champion)** — sente il dolore che il tuo prodotto risolve e vuole risolverlo. Spesso non è senior, ma è la persona che porterà avanti la tua causa all'interno. - **Il compratore economico** — controlla il budget e può approvare la spesa. È chi in ultima istanza dice di sì. - **Il blocco / gatekeeper** — l'ufficio acquisti, un assistente, l'IT o un luogotenente scettico il cui compito è filtrare il rumore. Non è il tuo nemico, ma nemmeno il tuo obiettivo. Prima di contattare chiunque, decidi a chi punti e perché. Per un primo incontro di solito vuoi lo sponsor interno o il compratore economico — mai un dipendente a caso il cui nome hai trovato perché era facile da trovare. Raggiungere la persona sbagliata non spreca solo il messaggio; può bruciare l'account, perché ora il tuo nome è legato a un pitch a freddo mal indirizzato. Se non sai articolare perché una persona specifica è il contatto giusto, non sei ancora pronto a scrivere. ## Passo 2: fai abbastanza ricerca da meritare una risposta La ricerca sui contatti non è "trovare un indirizzo email". È mettere insieme abbastanza contesto da far sì che il tuo messaggio possa essere stato scritto solo per quell'unica persona. È questo che merita una risposta in una casella che riceve cinquanta pitch a settimana. Prima di scrivere qualsiasi cosa, devi sapere: 1. **L'innesco (trigger)** — perché adesso? Un round di finanziamento, una nuova assunzione in un ruolo rilevante, il lancio di un prodotto, una lamentela pubblica, un annuncio di lavoro che rivela una lacuna. Un motivo per cui il tempismo ha senso per *loro*. 2. **Il dolore specifico** — non "le aziende come la vostra faticano con X", ma la prova che *questa* azienda lo fa. 3. **Il tessuto connettivo** — un contatto in comune, un cliente nel loro settore, qualcosa che hai notato e che un template non saprebbe inventare. Le fonti pubbliche ti danno la maggior parte di questo senza alcuno strumento speciale: il sito dell'azienda e la sua pagina lavora con noi, LinkedIn, le uscite recenti sulla stampa, le apparizioni nei podcast, le earnings call per le aziende quotate e le community dove il tuo compratore passa davvero il tempo. Se hai validato bene il mercato, hai già fatto parte di questo lavoro — vedi [Come validare un'idea di business prima di costruirla](/how-to-validate-a-business-idea/) per la ricerca su domanda e concorrenti che funge anche da intelligence di vendita. Il test per capire se hai fatto abbastanza: sapresti scrivere le prime due frasi del messaggio in un modo che *non avrebbe alcun senso* inviato a qualsiasi altra azienda? Se sì, sei pronto. Se la tua apertura funzionerebbe per cento aziende, continua a fare ricerca. ## Passo 3: metti in sequenza i canali — email, telefono, LinkedIn Non esiste un unico canale migliore. Esiste il canale migliore per ogni momento. L'errore è sceglierne uno e martellarlo. L'abilità sta nel metterli in sequenza così che ciascuno faccia il lavoro in cui è davvero bravo. | Canale | Uso migliore | Rischio se usato male | | --- | --- | --- | | Email | La richiesta principale, il follow-up dettagliato, tutto ciò che il compratore deve inoltrare internamente | Ignorata all'istante se sembra un template | | Telefono | Follow-up urgente, sollecitare una trattativa fissata ma alla deriva, una segnalazione a caldo che ti hanno detto di chiamare | Sembra invadente senza contesto o motivo pregresso | | LinkedIn | Primo contatto soft, riscaldare un contatto freddo, restare visibile tra un'email e l'altra | Affollato, lento, facile sembrare come ogni altro pitch | | Introduzione a caldo | Qualsiasi cosa, quando riesci a ottenerne una | La credibilità di chi ti presenta è in gioco — non sprecarla | Una sequenza che funziona nella pratica: apri con un'email breve e specifica, legata all'innesco che hai trovato. Se non arriva risposta, aggiungi valore su LinkedIn — un commento genuino, una risorsa utile, una richiesta di connessione con contesto — così che il tuo nome non sia una sorpresa a freddo. Passa alla telefonata solo quando c'è un motivo reale: una scadenza, una segnalazione, una trattativa che si è raffreddata dopo l'interesse. Una chiamata dal nulla, a qualcuno che non ha mai sentito il tuo nome, è il modo più rapido per finire archiviato come spam. E prediligi sempre l'introduzione a caldo quando riesci a guadagnartene una. Una singola introduzione da parte di qualcuno di cui il compratore si fida batte venti email a freddo scritte alla perfezione. Investi impegno vero nel mappare chi nella tua rete può aprirti quale porta, prima di partire a freddo. ## Passo 4: scrivi il messaggio che ottiene risposta Una volta guadagnato il diritto di scrivere, tieni il messaggio breve e rendi facile dire di sì. I pitch lunghi da sconosciuti non vengono letti; vengono archiviati. Una buona email a freddo fa quattro cose in meno di 90 parole: 1. **Nomina l'innesco** — dimostra che stai facendo attenzione e che non è un invio di massa. 2. **Enuncia il dolore rilevante** — una frase, inquadrata come loro, non tua. 3. **Fa una sola piccola richiesta** — una call di 15 minuti, non "esploriamo una partnership". 4. **Offre una via d'uscita facile** — "Se non sei tu la persona giusta, potresti indicarmi chi se ne occupa?". Ecco la forma: > "Ciao Priya — ho visto che avete appena aperto due posizioni nel team RevOps, il che di solito significa che la reportistica sta diventando dolorosa più in fretta di quanto l'organico riesca a rimediare. Aiutiamo i team in Serie B a tagliare di circa il 60% il tempo dedicato alla reportistica manuale senza smantellare il loro stack. Vale 15 minuti la prossima settimana per vedere se è rilevante? E se non è il tuo ambito, ti sarei grato per un'indicazione su chi se ne occupa." È specifica, rispettosa del loro tempo e banalmente facile da rispondere — persino il "no" è utile, perché ti indirizza alla persona giusta. La stessa disciplina vale su tutti i canali; se vuoi la meccanica più approfondita del contatto su scala senza farti segnalare o ignorare, l'ho scomposta in [Costruire una strategia di outreach di successo](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/). ## Passo 5: preparati come se quell'incontro fosse l'unico che avrai L'accesso ti dà l'apertura. La preparazione ti guadagna il passo successivo. I founder lottano regolarmente per settimane per ottenere un incontro, poi si presentano senza aver ragionato sul mondo del compratore — e la trattativa muore non per mancanza di interesse ma per mancanza di preparazione. Prima di ogni call, devi saper rispondere, a freddo: - Com'è la giornata di questa persona e dove si inserisce il mio prodotto? - Qual è l'unico risultato a cui tiene e su cui posso incidere? - Quali sono le due obiezioni che solleverà e qual è la mia risposta onesta? - Qual è il più piccolo passo successivo che posso chiedere se è interessato ma non ancora pronto? Il prodotto l'hai costruito tu, quindi la demo è facile. La parte difficile è tenere in testa le priorità del compratore invece delle tue. I founder che convertono il contatto in ricavi sono quelli che si presentano dando l'impressione di capire già l'azienda — perché hanno fatto il lavoro al Passo 2. ## Quando non scrivere Il contatto aggressivo brucia più pipeline di quanta ne costruisca. Salta il contatto a freddo — o rallenta — quando: - Non sai dire perché questa persona specifica è il contatto giusto. - Hai già fatto follow-up più di due volte senza risposta. (Vai avanti; il mercato è grande.) - La tua apertura funzionerebbe inviata ad altre cento aziende. - Staresti chiamando fuori dal normale orario di lavoro o senza alcun contesto pregresso. - L'unico motivo per cui hai scelto questa persona è che i suoi contatti erano facili da trovare. Un buon contatto sembra una nota rilevante e ben tempestata da parte di qualcuno che ha fatto i compiti. Un cattivo contatto sembra spam con un targeting migliore. La differenza sta interamente nella ricerca e nella misura. ## Lo stack della vendita guidata dal founder Gli strumenti e le abitudini su cui mi appoggio per questo, nessuno dei quali richiede un team commerciale: - **Ricerca:** il sito dell'azienda e la sua pagina lavora con noi, LinkedIn, le uscite recenti sulla stampa e le community dove i tuoi compratori parlano davvero - **CRM:** qualsiasi cosa che aggiornerai davvero — una semplice board di Notion o Airtable batte un CRM enterprise che ignori - **Sequenziamento:** un tracker leggero per sapere chi è a quale stadio e qual è il prossimo contatto, così nulla va alla deriva - **Email:** un indirizzo di invio reale e "riscaldato" e messaggi in testo semplice — niente immagini, niente pixel di tracciamento, niente che urli "campagna" - **Calendario:** un link di prenotazione così che un "sì" si trasformi in un incontro con un clic invece che con cinque email di risposta ## Il verdetto dell'operatore Non ti serve un team commerciale per iniziare a vendere. Ti serve sapere esattamente chi può dire di sì, fare abbastanza ricerca da far sì che il tuo messaggio possa essere stato scritto solo per quella persona e mettere in sequenza i canali così che ciascuno faccia il suo lavoro. L'email porta la richiesta, LinkedIn prepara il terreno, il telefono chiude una lacuna urgente e un'introduzione a caldo le batte tutte. Fai tu stesso le ripetizioni abbastanza a lungo da imparare cosa fa davvero centro — poi, e solo allora, passa quel manuale conquistato con fatica alla tua prima assunzione. --- **Correlati:** [Costruire una strategia di outreach di successo](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) · [Come validare un'idea di business](/how-to-validate-a-business-idea/) · [Guida alle strategie di growth marketing](/growth-marketing-strategies-guide/) --- ## Come costruire un'attività solopreneur: la guida 2026 Source: https://alejandrorioja.com/it/how-to-build-a-solopreneur-business/ Published: 2026-07-07 Tags: Entrepreneurship, Growth TL;DR: Scegli un modello di business (contenuti, servizi, SaaS o prodotti digitali), costruisci un pubblico attorno a una nicchia specifica, poi aggiungi flussi di reddito secondari una volta che il principale converte. La trappola è partire con tutti e quattro contemporaneamente — scegli il modello che si adatta a ciò che già sai fare, non quello che sembra il più passivo. ## Indice _Aggiornato luglio 2026._ **TL;DR:** Scegli un modello di business (contenuti, servizi, SaaS o prodotti digitali), costruisci un pubblico attorno a una nicchia specifica, poi aggiungi flussi di reddito secondari una volta che il principale converte. La trappola è partire con tutti e quattro contemporaneamente — scegli il modello che si adatta a ciò che già sai fare, non quello che sembra il più passivo. **[Punto di vista dell'operatore]** Ho gestito questo sito, venduto corsi e amministrato entrate da affiliazione per anni senza alcun dipendente a tempo pieno. Niente di tutto ciò è iniziato con un grande piano — è iniziato con una cosa che funzionava, poi con un'espansione deliberata da lì. Questa guida è ciò che avrei voluto leggere prima di cercare di fare tutto in una volta. ## Cos'è realmente un'attività solopreneur Un solopreneur gestisce un'attività da solo — nessun co-fondatore, nessun dipendente, forse collaboratori quando il volume lo richiede. L'obiettivo è un'attività che funziona grazie all'expertise e ai sistemi, non al numero di persone. Questo è diverso dal freelancing. Un freelancer vende tempo. Un solopreneur costruisce sistemi che generano entrate senza richiedere il suo tempo per ogni euro guadagnato. ## I 4 modelli di business solopreneur Ogni attività di una sola persona rientra approssimativamente in uno di questi: 1. **Attività di contenuto.** Pubblichi (blog, newsletter, YouTube, podcast) e monetizzi tramite pubblicità, entrate da affiliazione, sponsorizzazioni e prodotti propri. La barriera più bassa, la rampa più lunga. 2. **Attività di servizi.** Fornisci un risultato specifico ai clienti — consulenza, ruoli frazionali, servizi done-for-you. Il percorso più rapido verso i 10.000 €/mese, il meno scalabile. 3. **Prodotti digitali.** Corsi, template, ebook, strumenti. Alta leva una volta creati, difficile generare traffico senza un pubblico esistente. 4. **Micro-SaaS.** Un piccolo prodotto software che risolve un problema specifico. Il soffitto più alto, la barra tecnica più esigente. Il modello giusto dipende da ciò che hai già: competenze, un pubblico o capitale. ## Passo 1: Scegli la tua nicchia con vera profondità Le nicchie ampie (marketing, finanza, salute) hanno traffico ma una concorrenza brutale. Le nicchie strette (strumenti AI per fondatori di e-commerce, finanze personali per neolaureati in infermieristica) convertono meglio e si posizionano più rapidamente. Il test che uso: riesco a scrivere 50 contenuti davvero utili su questo argomento senza esaurire le idee? Se sì, la nicchia ha profondità. Se faccio fatica a nominarne 20, è troppo stretta o non la conosco abbastanza bene. La tua nicchia dovrebbe trovarsi all'intersezione di: - Qualcosa che conosci per esperienza, non solo per ricerca - Un pubblico con denaro o tempo da spendere - Un problema ricorrente, non una soluzione una tantum ## Passo 2: Costruisci il tuo pubblico prima di averne bisogno Il più grande errore che vedo: lanciare un prodotto per un pubblico pari a zero. Il pubblico prima del prodotto è la regola. Ecco cosa funziona davvero: 1. **Scegli un canale di distribuzione e approfondiscilo.** Blog + SEO è lento ma duraturo. Una newsletter è rapida da monetizzare. I video brevi hanno un soffitto alto ma dipendono dall'algoritmo. Non dividere l'attenzione su quattro piattaforme nel primo anno. 2. **Pubblica in modo costante prima di avere qualcosa da vendere.** Il pubblico che costruisci quando non hai nulla da vendere si fida di te quando finalmente lo fai. 3. **Costruisci una lista email dal primo giorno.** I follower sui social sono terreno in affitto. La tua lista email è tua. Uso [ConvertKit](/recommends/convertkit) — gestisce le sequenze e le trasmissioni senza ostacolare. Un punto di riferimento utile: 1.000 veri fan (iscritti alla newsletter che aprono ogni email) sono sufficienti per generare 100.000 €/anno con prodotti digitali. ## Passo 3: Ottimizza prima il tuo flusso di entrate principale Una volta che hai un pubblico (o un cliente da un servizio), punta tutto sul flusso di entrate principale prima di aggiungerne di secondari. **Per le attività di contenuto:** le entrate da affiliazione sono il primo euro più rapido. Scrivi degli strumenti che usi, colleghi tramite la tua pagina delle raccomandazioni e guadagni una percentuale. Nessun prodotto da creare, nessun supporto clienti. Il soffitto è reale — un sito ad alto traffico in una nicchia redditizia potrebbe guadagnare 5.000–30.000 €/mese — ma è il miglior meccanismo di bootstrap che abbia trovato. **Per le attività di servizi:** addebita più di quanto ti sembra confortevole. Il prezzo basso è l'errore più comune del solopreneur. Se hai un tasso di chiusura del 100%, sei troppo economico. **Per i prodotti digitali:** mantieni il perimetro stretto. Un corso focalizzato da 97 € supera uno esteso da 497 € in tasso di conversione e completamento. **Per il Micro-SaaS:** costruisci per un dolore che hai personalmente. Il vantaggio dell'empatia è reale quando sei il tuo stesso cliente target. ## Passo 4: Accumula flussi di entrate secondari Una volta che il tuo modello principale converte, aggiungi flussi di entrate che non richiedono tempo proporzionale: - **Entrate da affiliazione** — anche le attività di servizi e gli operatori SaaS possono guadagnare entrate da affiliazione dal loro contenuto - **Prodotti digitali** — anche se sei principalmente un'attività di servizi, un corso o un set di template può guadagnare mentre dormi - **Sponsorizzazioni** — una volta che il tuo pubblico supera i ~5.000 iscritti coinvolti - **Licensing** — se hai costruito un sistema o uno strumento, concedilo in licenza ad altri in nicchie adiacenti Lo stack è un risultato, non una strategia. Fai funzionare prima un flusso. ## Il tech stack del solopreneur Gestisco tutta questa operazione con sei strumenti: | Strumento | Cosa fa | |---|---| | [Claude](/recommends/claude) | Prime bozze di contenuti, email e codice | | [ConvertKit](/recommends/convertkit) | Lista email, automazioni e trasmissioni | | [Notion](/recommends/notion) | Calendario editoriale, documenti clienti e SOP | | [Canva](/recommends/canva) | Grafiche social e design delle miniature | | [Airtable](/recommends/airtable) | Tracciamento affiliati, CRM, database contenuti | | [SEMrush](/recommends/semrush) | Ricerca keyword e monitoraggio delle posizioni | Costo mensile totale: meno di 300 €. Un team che sostituisse questo stack costerebbe più di 15.000 € al mese in stipendi. ## I 3 errori che uccidono le attività solopreneur 1. **Scaling prematuro.** Assumere prima che il modello di business sia dimostrato brucia le risorse e aggiunge overhead gestionale prima di avere entrate ripetibili. 2. **Diversificare troppo presto.** Quattro flussi di entrate a metà rendimento guadagnano meno di uno completamente ottimizzato. Vai più in profondità, non più in ampiezza, nel primo anno. 3. **Costruire senza distribuzione.** Il miglior prodotto senza pubblico non batte un prodotto mediocre con una grande lista coinvolta. La distribuzione è il fossato. ## La conclusione dell'operatore Un'attività solopreneur è una scelta deliberata di scambiare la complessità del team con proprietà e margine. Le attività che ho visto funzionare in modo costante condividono lo stesso schema: un modello, una nicchia, un canale di distribuzione, mantenuto abbastanza a lungo da crescere in modo composto. Scegli il modello che corrisponde alle tue competenze esistenti. Costruisci il pubblico prima di averne bisogno. Aggiungi flussi di entrate solo dopo che il principale converte. Il resto è esecuzione. --- **Correlato:** [Come convalidare un'idea di business](/how-to-validate-a-business-idea/) · [Come monetizzare una newsletter](/how-to-monetize-a-newsletter/) · [Come costruire un personal brand](/how-to-build-a-personal-brand/) --- ## Come automatizzare la tua piccola impresa con agenti IA: guida pratica Source: https://alejandrorioja.com/it/how-to-automate-your-small-business-with-ai-agents/ Published: 2026-07-04 Tags: AI Agents, Entrepreneurship, Operations TL;DR: Automatizzare una piccola impresa con agenti IA non significa sostituire le persone — si tratta di delegare il lavoro ripetitivo basato su regole per poter dedicare il tuo tempo alle decisioni che solo tu puoi prendere. Inizia con un compito, registra tutto, tieni gli esseri umani nel loop per tutto ciò che riguarda direttamente soldi o clienti, e poi espandi. Lo stack che uso in due aziende costa meno di $100/mese in totale. ## Indice _Aggiornato luglio 2026._ **TL;DR:** Automatizzare una piccola impresa con agenti IA non significa sostituire le persone — si tratta di delegare il lavoro ripetitivo basato su regole per poter dedicare il tuo tempo alle decisioni che solo tu puoi prendere. Inizia con un compito, registra tutto, tieni gli esseri umani nel loop per tutto ciò che riguarda direttamente soldi o clienti, e poi espandi. Lo stack che uso in due aziende costa meno di $100/mese in totale. **Nota dell'operatore:** Gestisco due aziende — un impianto di pickleball indoor a nove campi a Pflugerville, TX (Pickleland) e un brand di consulenza. Tra le due, ho più di 30 agenti IA in produzione che gestiscono tutto, dalle risposte ai commenti sui social alla promozione di eventi, bozze di newsletter e follow-up sulle prenotazioni. Questa è la guida senza fronzoli su cosa funziona davvero, cosa fa perdere tempo e come iniziare senza assumere uno sviluppatore. Il quadro onesto: gli agenti IA per le piccole imprese non sono magia. Non sostituiscono il duro lavoro delle relazioni con i clienti, della qualità del prodotto o del giudizio strategico. Quello che fanno è eliminare il lavoro amministrativo che consuma due o tre ore al giorno di ogni operatore — la smistamento delle email, i report copia-incolla, le risposte sui social, la formattazione dei dati. Questo è sufficiente per fare la differenza. ## I 4 tipi di lavoro che si automatizzano bene Prima di costruire qualsiasi cosa, mappa il tuo carico di lavoro in quattro categorie. Solo una di esse è adatta agli agenti IA. ### 1. Basato su regole, ripetitivo, testo in ingresso / testo in uscita Questo è il punto ottimale. Classificare un'email di un cliente, redigere una risposta a un commento sui social media, riassumere una settimana di prenotazioni in un elenco puntato, riformattare un CSV in un report. L'input è testo; l'output è testo; le regole sono coerenti. Questi compiti si automatizzano con un prompt singolo e un wrapper leggero intorno all'API. **Esempi da Pickleland:** - Classificare le email di richiesta campo (domanda / reclamo / prenotazione / altro) - Redigere post per gruppi Facebook sugli eventi imminenti - Generare riepiloghi settimanali di occupazione dal sistema di prenotazione ### 2. Pipeline multi-fase con trasferimenti chiari Un compito che ha tre fasi — recuperare dati, trasformarli, inviare una notifica — dove ogni fase ha un input e un output chiari. Funziona bene con uno strato di orchestrazione leggero (uso Cloudflare Workers Queues). La chiave è che ogni fase può fallire in modo indipendente e essere ripetuta senza rifare tutto il lavoro. **Esempi da Pickleland:** - Nuova prenotazione → aggiornamento CRM → email di conferma → notifica Slack - Invio modulo → classificazione → bozza di risposta indirizzata → coda di revisione umana ### 3. Monitoraggio e avvisi Agenti che monitorano una condizione e ti avvisano quando si verifica. Queste sono tra le automazioni con il miglior ritorno sull'investimento perché sostituiscono il carico cognitivo del controllo manuale delle dashboard. Sono anche tra le più semplici: la logica è solo "X è sopra la soglia? Se sì, avvisa." **Esempi dal mio brand di consulenza:** - Avvisi di anomalie su Google Analytics (calo del traffico, picco) - Tasso di cancellazione prenotazioni sopra la media settimanale - Nuova recensione pubblicata — contrassegnare per risposta umana ### 4. Prime bozze di contenuto (non il prodotto finale) Gli agenti IA possono redigere post social, newsletter via email, schemi di blog e descrizioni di prodotti con qualità utile. Il problema: non possono sostituire il tuo giudizio editoriale. Ogni bozza passa attraverso una fase di revisione umana. Il ROI deriva dall'iniziare al 70% invece che da una pagina bianca. **Cosa NON si automatizza bene:** gestione delle relazioni con i clienti, decisioni sui prezzi, conversazioni di vendita, assunzioni e tutto ciò che ha un costo reale per una persona reale se va male. Mantieni gli esseri umani per queste attività. ## Lo stack che uso davvero Non hai bisogno di software enterprise per questo. Ecco cosa alimenta le mie automazioni: 1. **[Claude](/recommends/claude)** — lo strato modello per tutti i compiti IA. Uso l'API direttamente, non un'interfaccia grafica. Il rapporto qualità-prezzo è il migliore che abbia testato, e il [caching dei prompt](/prompt-caching-cut-your-claude-costs-without-switching-models/) riduce ulteriormente i costi quando i prompt di sistema si ripetono. 2. **Cloudflare Workers** — dove vivono gli agenti. Serverless, distribuito globalmente, e il livello gratuito copre la maggior parte dei carichi di lavoro delle piccole imprese. L'handler `scheduled` esegue compiti cron; l'handler `fetch` riceve webhook per flussi attivati da eventi. 3. **Airtable** — la spina dorsale dei dati. Ogni agente legge e scrive nelle tabelle Airtable. Qui vivono lo stato del lavoro, le code di revisione e i dati operativi. I non-sviluppatori possono modificare i dati senza toccare il codice. 4. **Kit (precedentemente ConvertKit)** — automazione email e newsletter. Il mio agente per la stesura di newsletter scrive in una bozza Kit; io rivedo e invio. Costo mensile totale per 30+ agenti in due aziende: meno di $100. La voce più grande è l'utilizzo dell'API Claude. Tutto il resto è livello gratuito o quasi. ## Esempi reali: automazioni Pickleland ### Il promotore di eventi Ogni domenica, un agente programmato controlla il sistema di prenotazione per gli eventi nei prossimi quattro giorni. Abbina ogni evento ai gruppi Facebook locali rilevanti e redige un post promozionale appropriato per ciascuno. Le bozze vanno in una tabella di revisione Airtable. Passo cinque minuti a rivedere e cliccare su "Approva" — l'agente fa i 40 minuti di stesura. Nulla viene pubblicato automaticamente senza la mia approvazione. Questo è il [modello di agente programmato](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — esegue secondo un calendario, fa lavoro in batch e presenta bozze per la revisione umana. ### Il classificatore di commenti social Quando arriva un nuovo commento su un post Facebook monitorato, si attiva un webhook e l'agente classifica l'intento: domanda, reclamo, complimento o spam. Per domande e reclami sopra una soglia di confidenza, redige una risposta e la contrassegna per la revisione. I complimenti vengono registrati. Lo spam viene soppresso. Un ciclo di 30 secondi dal commento alla bozza. Senza l'agente, ogni commento era un cambio di contesto manuale; ora la coda di risposte pre-redatte richiede cinque minuti invece di trenta. Questo è il [modello di agente attivato da eventi](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — si attiva tramite webhook, deve rispondere velocemente. ### Il riepilogo operativo settimanale Ogni lunedì mattina, un agente estrae i dati di prenotazione della settimana precedente, il tasso di cancellazione, l'occupazione per tipo di campo e qualsiasi anomalia segnalata. Formatta un riepilogo in cinque punti e lo deposita in una pagina Notion. Lo leggo con il caffè e ho il contesto operativo di cui ho bisogno per la settimana in due minuti invece di venti. ## Da dove iniziare: 4 passi ### Passo 1: Scegli il compito ripetitivo con più attrito che fai ogni settimana Non il più glamour, non il più strategico — quello per cui ti lamenti di più. Il report settimanale che copi e incolli da tre fonti. Le risposte social a cui dedichi un'ora. Le email di follow-up che invii una per una. Questo è il tuo primo agente. ### Passo 2: Mappa il compito in input e output Scrivi: - Cosa attiva il compito (un orologio, un evento, l'invio di un modulo) - Quali input necessita (fonti di dati, testo, contesto) - Qual è l'output (una bozza, una notifica, una riga del database) - Quale è la fase di revisione umana (ogni primo agente dovrebbe averne una) Se non riesci a mapparlo chiaramente, il compito non è abbastanza ben definito per essere automatizzato. Chiarisci prima il processo manualmente. ### Passo 3: Costruisci la versione più semplice possibile Non un sistema. Un prompt, una chiamata API, un output. Una funzione TypeScript che prende l'input, chiama Claude e restituisce la bozza. Nessun database, nessun webhook, nessuna coda — solo la logica centrale. Eseguila manualmente cinque volte. La qualità dell'output tiene? Se sì, hai un agente funzionante. Poi aggiungi l'infrastruttura. ```typescript // Il primo agente più semplice: bozza di promo evento async function draftEventPromo(event: PadklelandEvent, env: Env): Promise { const msg = await env.ANTHROPIC.messages.create({ model: "claude-opus-4-8", max_tokens: 400, system: `You write Facebook event promo posts for Pickleland, an indoor pickleball facility in Pflugerville, TX. Tone: friendly, local, community-focused. Max 150 words.`, messages: [ { role: "user", content: `Write a promo post for this event: ${JSON.stringify(event)}`, }, ], }); return (msg.content[0] as { text: string }).text; } ``` ### Passo 4: Aggiungi l'osservabilità prima di aggiungere altre funzionalità Registra ogni esecuzione con un ID di traccia. Registra l'input, l'output e il timestamp. Non hai bisogno di uno strumento sofisticato — JSON strutturato su stdout è sufficiente per iniziare. Il motivo: il tuo primo agente fallirà in modi che non avevi previsto. Quando succede, devi poter vedere cosa è successo senza ricreare lo stato dalla memoria. Questa è l'abitudine che separa gli operatori che scalano il loro stack di agenti da quelli che si arrendono dopo una brutta esperienza. Approfondisco questo in [come eseguire il debug di un agente IA in produzione](/how-to-debug-an-ai-agent-in-production/). ## Errori comuni (e come evitarli) **Automatizzare prima di capire il processo.** Se non riesci a eseguire tu stesso il compito in modo coerente, un agente IA lo farà semplicemente in modo incoerente su scala. Documenta prima il processo manualmente, poi automatizza. **Rimuovere la fase di revisione umana troppo presto.** Inizia ogni agente con un loop di revisione umana. Lascialo girare per due settimane, controlla ogni output e acquista fiducia prima di lasciare che qualsiasi cosa vada completamente automatizzata. L'eccezione sono le azioni a basso rischio e facilmente reversibili (come scrivere una bozza in una cartella). **Costruire l'intero sistema prima di validare il nucleo.** Costruisci prima la versione più semplice possibile. Se la qualità centrale non c'è con un prompt, più infrastruttura non la risolverà. **Ignorare i costi.** I costi dell'API IA scalano con l'utilizzo. Conosci il tuo costo per esecuzione prima di distribuire in volume. La [matematica dei costi Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet/) conta quando fai migliaia di esecuzioni a settimana. **Trattare i fallimenti come catastrofi.** Gli agenti falliscono. I prompt regrediscono. Le API vanno giù. Costruisci logica di retry, costruisci [framework di valutazione](/the-eval-harness-i-use-to-ship-ai-agents/) e tratta i fallimenti come dati, non come disastri. ## Il cambio di mentalità che cambia tutto Il collo di bottiglia in una piccola impresa non è quasi mai il denaro — è il tempo e l'attenzione del proprietario. Ogni ora che trascorri su compiti che un agente può gestire è un'ora che non hai dedicato ai clienti, al prodotto o alla strategia. Il framework che uso: se un compito può essere scritto come un processo ripetibile con input e output chiari, è candidato per un agente. Tutto ciò che richiede giudizio, relazione o creatività rimane con me. L'agente gestisce il primo così posso concentrarmi sul secondo. Iniziare con agenti IA non richiede un co-fondatore tecnico, un budget software a sei cifre o mesi di sviluppo. Richiede scegliere un compito ad alto attrito, costruire la versione più piccola che funziona e imparare dall'output. La maggior parte degli operatori trova il suo primo agente funzionante in un weekend. Da lì, il secondo richiede un pomeriggio. ## FAQ ### Quanto costa gestire agenti IA per una piccola impresa? Il mio stack esegue 30+ agenti per meno di $100/mese. Il costo maggiore è l'utilizzo dell'API IA (Claude). Cloudflare Workers è gratuito fino a 100.000 richieste/giorno e $5/mese dopo. Airtable ha un livello gratuito che copre la maggior parte delle esigenze di dati delle piccole imprese. I costi scalano con l'utilizzo — un singolo agente che gira poche volte a settimana è trascurabile. ### Ho bisogno di uno sviluppatore per costruire agenti IA? Per i pattern di base — un cron programmato, un handler webhook, un prompt semplice — puoi cavartela con un po' di JavaScript e la voglia di leggere la documentazione. Per pipeline più complesse, orchestrazione e osservabilità di livello produzione, uno sviluppatore velocizza il lavoro. Il mio corso ([Agenti IA per principianti](/ai-agents-for-beginners-cowork-codex-guide/)) insegna i percorsi no-code e low-code per gli operatori. ### Qual è il miglior primo agente IA per una piccola impresa? Il riepilogo operativo settimanale. Gira secondo un calendario, ha input chiari (le tue fonti di dati), produce un output coerente (un riepilogo formattato) e ha rischio zero al ribasso — se la bozza è sbagliata, semplicemente non la leggi. Costruisce la tua intuizione su cosa gli agenti possono e non possono fare senza rischi per i clienti o le operazioni. ### Quale modello IA usare per l'automazione aziendale? Uso Claude per quasi tutto il mio lavoro con gli agenti. La qualità dell'API, l'affidabilità e il pricing favorevole agli operatori (specialmente con il [caching dei prompt](/prompt-caching-cut-your-claude-costs-without-switching-models/)) lo rendono la scelta giusta per l'uso in produzione. Per compiti di classificazione economici e ad alto volume, Claude Haiku 4.5 è veloce ed economico. Per la stesura e i compiti sfumati, Claude Sonnet o Opus. ### Come evito che gli agenti IA facciano errori che danneggino la mia azienda? Tre pratiche: tieni gli esseri umani nel loop per tutto ciò che riguarda direttamente clienti o denaro; registra ogni esecuzione per poter tracciare cosa è andato storto; e costruisci un [framework di valutazione](/the-eval-harness-i-use-to-ship-ai-agents/) in modo che le modifiche ai tuoi prompt non rompano silenziosamente la produzione. Inizia con compiti interni a basso rischio ed espandi solo dopo aver fiducia nella qualità dell'output. --- ## Come costruire un personal brand online: Il manuale del praticante 2026 Source: https://alejandrorioja.com/it/how-to-build-a-personal-brand/ Published: 2026-07-02 Tags: Entrepreneurship, Growth TL;DR: Un personal brand si costruisce scegliendo un pubblico specifico, pubblicando contenuti utili in modo costante su un solo canale e avendo un punto di vista chiaro — non ottimizzando la tua bio LinkedIn. Restringi la tua nicchia, scrivi dall'esperienza reale, costruisci una lista email come unico canale di proprietà e ripeti finché le persone giuste non possono più ignorarti. ## Indice _Aggiornato luglio 2026._ **TL;DR:** Un personal brand si costruisce scegliendo un pubblico specifico, pubblicando contenuti utili in modo costante su un solo canale e avendo un punto di vista chiaro — non ottimizzando la tua bio LinkedIn. Restringi la tua nicchia, scrivi dall'esperienza reale, costruisci una lista email come unico canale di proprietà e ripeti finché le persone giuste non possono più ignorarti. **[Nota del praticante]** Ho costruito in pubblico attraverso più aziende — Pickleland, consulenza su agenti AI, questo sito — e il modello che continuo a vedere è sempre lo stesso: le persone che costruiscono personal brand riconoscibili non sono le più talentuose. Sono le più specifiche e le più costanti. Ecco il framework che uso e raccomando. ## Cos'è davvero un personal brand (e cosa non è) Un personal brand è la risposta a una domanda: *Cosa dicono le persone di te quando non sei nella stanza?* Non è il tuo logo. Non è la tua palette di colori. Non è quanti follower hai. Un personal brand è la scorciatoia mentale che le persone formano quando sentono il tuo nome — il problema specifico che pensano tu possa risolvere, la prospettiva che si aspettano tu abbia. L'errore che fanno la maggior parte delle persone: cercano di costruire un brand prima di aver sviluppato un punto di vista. Un brand è ciò che si accumula facendo cose reali ed essendo precisi su ciò che hai imparato — non qualcosa che si fabbrica in anticipo. Cosa puoi controllare fin dall'inizio: 1. Con chi parli 2. Quale problema risolvi per loro 3. Dove ti trovano 4. Quanto costantemente ti presenti Cosa si accumula nel tempo: - Una reputazione per un tipo specifico di competenza - Un pubblico che si fida del tuo giudizio - Opportunità in entrata che non hai dovuto inseguire ## Passo 1: Scegli la nicchia più ristretta con cui puoi vivere L'errore più comune nel personal branding è essere troppo ampio. "Esperto di marketing." "Consulente aziendale." "Imprenditore tech." Queste sono etichette prive di significato in un mondo dove tutti le hanno. Più vai stretto, più velocemente costruisci una reputazione. Testa la tua nicchia con questo filtro: - **Abbastanza specifica da essere ricercabile.** Qualcuno può cercare la tua nicchia su Google e trovare una vera community intorno a essa? - **Abbastanza specifica da essere raccomandabile.** Se qualcuno incontra una persona con esattamente il tuo problema, pensa prima a te? - **Abbastanza ampia da produrre contenuti per 2+ anni.** Usa uno strumento di parole chiave come [Semrush](/recommends/semrush) per verificare se la tua nicchia viene cercata. ## Passo 2: Scegli un canale primario Cercare di essere ovunque contemporaneamente è un modo garantito per essere mediocri ovunque. All'inizio, scegli un canale e vai in profondità. - **Contenuto scritto (blog/newsletter):** Ideale per pubblici analitici e praticanti. Si accumula nel tempo tramite SEO. - **LinkedIn:** Ideale per pubblici B2B e professionali. - **YouTube / video:** Ideale per argomenti che beneficiano della dimostrazione visiva. - **X / Twitter:** Ideale per idee che viaggiano. ## Passo 3: Trova il tuo punto di vista I contenuti senza punto di vista sono rumore. Ciò che distingue i personal brand citati, raccomandati e cercati è una prospettiva distinta — un'opinione su come funziona il mondo, informata dall'esperienza reale. Un POV forte ha queste proprietà: - È fondato su qualcosa che hai davvero fatto, non solo letto - Sfida almeno un'assunzione convenzionale del tuo pubblico - È abbastanza specifico da far sì che alcune persone non siano d'accordo ## Passo 4: Costruisci un pubblico di proprietà Ogni piattaforma su cui costruisci può cambiare il suo algoritmo, bannare il tuo account o chiudere. L'unico canale di distribuzione che possiedi davvero è la tua lista email. Inizia a costruirla dal primo giorno. Per l'email, uso [ConvertKit](/recommends/convertkit) — sviluppato appositamente per le newsletter dei creator. Il modo più rapido per far crescere una lista email: 1. **Crea un lead magnet genuinamente utile.** Una checklist, un modello o una guida breve che risolve un problema specifico. 2. **Aggiungi l'opt-in above the fold su ogni pagina di contenuto.** 3. **Scrivi una sequenza di benvenuto di 3 email.** 4. **Menziona la lista in ogni pezzo di contenuto.** ## Passo 5: Pubblica in modo costante — la matematica dell'interesse composto Se pubblichi un pezzo lungo a settimana: - **Settimane 1–8:** Quasi nessuno lo legge. È normale. - **Mesi 3–4:** Alcuni pezzi iniziano a ricevere traffico organico. - **Mesi 6–9:** Il traffico di ricerca si accumula. Le richieste in entrata iniziano ad apparire. - **Anno 2:** Hai 100 pezzi di contenuto. Il tuo nome appare nelle ricerche e nelle risposte AI. La mia regola: impegnati 6 mesi prima di valutare se funziona. ## Come penso al brand visivo Il brand visivo minimo vitale: - Una foto profilo professionale dove il tuo viso è chiaramente visibile - Una foto profilo coerente su tutte le piattaforme - Un sito web semplice con un tagline chiaro e opt-in email [Canva](/recommends/canva) va bene per grafiche social e design semplice. ## Errori comuni 1. **Cercare di piacere a tutti.** Se scrivi per "gli imprenditori," scrivi per nessuno. 2. **Pubblicare senza distribuzione.** Scrivere un post e aspettare traffico non è una strategia. 3. **Cambiare focus ogni trimestre.** Il più grande killer dello slancio del personal brand. 4. **Misurare metriche di vanità.** Misura la dimensione della tua lista e il tuo tasso di conversione, non i tuoi like. 5. **Aspettare di essere "abbastanza esperto."** Non devi essere l'autorità mondiale nel tuo settore. ## Lo stack del personal brand - **Piattaforma email:** [ConvertKit](/recommends/convertkit) - **Ricerca SEO:** [Semrush](/recommends/semrush) - **Creazione contenuti:** [Claude](/recommends/claude) - **Design:** [Canva](/recommends/canva) ## FAQ ### Quanto tempo ci vuole per costruire un personal brand? Realisticamente, 12–24 mesi di pubblicazione costante prima di avere un afflusso significativo di opportunità. ### Devo essere su tutte le piattaforme social? No. La profondità su una piattaforma supera la presenza superficiale su cinque. ### Cosa è più importante: la qualità del contenuto o la frequenza di pubblicazione? Entrambi, ma non allo stesso modo. La qualità stabilisce il pavimento. La frequenza determina se ottieni le ripetizioni necessarie per migliorare. ### Devo usare il mio nome reale o un nome di marca? Usa il tuo nome reale. I personal brand legati a una persona reale sopravvivono meglio ai cambiamenti degli algoritmi. ### Come si monetizza un personal brand? Le quattro vie affidabili: (1) corsi / prodotti digitali, (2) consulenza e advisory, (3) partnership di affiliazione, e (4) contenuto sponsorizzato. --- **Correlato:** [Come validare un'idea di business prima di costruirla](/how-to-validate-a-business-idea/) · [Come costruire una lista email da zero](/how-to-build-an-email-list/) · [Come monetizzare una newsletter](/how-to-monetize-a-newsletter/) --- ## Come aggiungere memoria a un agente IA: pattern di persistenza dello stato per la produzione Source: https://alejandrorioja.com/it/how-to-add-memory-to-an-ai-agent/ Published: 2026-06-30 Tags: AI Agents TL;DR: Gli agenti stateless — quelli che dimenticano tutto quando il Worker termina — vanno bene per compiti una tantum. Nel momento in cui un agente deve ricordare cosa è successo ieri, riconoscere un cliente abituale o costruire su output precedenti, hai bisogno di memoria. Esistono tre pattern: memoria di lavoro (contesto in volo, vive in KV per la durata di un'esecuzione), memoria episodica (cosa è successo e quando, un log interrogabile) e memoria semantica (cosa sai, recuperata tramite ricerca vettoriale o dati strutturati). Collega il pattern giusto al lavoro giusto. ## Indice _Aggiornato giugno 2026._ **TL;DR:** Gli agenti stateless — quelli che dimenticano tutto quando il Worker termina — vanno bene per compiti una tantum. Nel momento in cui un agente deve ricordare cosa è successo ieri, riconoscere un cliente abituale o costruire su output precedenti, hai bisogno di memoria. Esistono tre pattern: memoria di lavoro (contesto in volo, vive in KV per la durata di un'esecuzione), memoria episodica (cosa è successo e quando, un log interrogabile) e memoria semantica (cosa sai, recuperata tramite ricerca vettoriale o dati strutturati). Collega il pattern giusto al lavoro giusto. **[Lettura dell'operatore]** Ho sbattuto contro il muro dell'agente stateless più di una volta. L'agente di risposta social che continuava a presentarsi a clienti con cui aveva parlato 20 volte. L'agente di briefing giornaliero che segnalava lo stesso problema per quattro giorni di fila perché non aveva memoria di averlo segnalato ieri. Aggiungere il tipo giusto di memoria ha risolto entrambi. Ecco cosa uso. ## Perché gli agenti stateless continuano a fallire Un agente stateless inizia ogni esecuzione solo con ciò che gli passi esplicitamente: il prompt di sistema, il messaggio utente e i dati che recuperi al momento dell'invocazione. Non ha consapevolezza delle esecuzioni precedenti, degli utenti precedenti o delle decisioni precedenti. Per un compito di classificazione una tantum — leggere un commento, restituire una categoria — lo stateless è corretto. È veloce, economico e prevedibile. La superficie di fallimento appare nel momento in cui hai bisogno di continuità: - Un agente rivolto ai clienti che non riconosce la storia del cliente - Un agente di contenuti che raccomanda un articolo che aveva già raccomandato la settimana scorsa - Un agente di moderazione che continua a ri-escalare un caso risolto - Un briefing giornaliero che mostra lo stesso avviso obsoleto indefinitamente Tutti questi sono sintomi dello stesso problema: l'agente non ha modo di trasportare il contesto tra le esecuzioni. ## Tre tipi di memoria Il framework che trovo utile in produzione: 1. **Memoria di lavoro** — ciò che l'agente sa _adesso_, durante una singola esecuzione. Tenuta in KV o in memoria per la vita dell'invocazione. 2. **Memoria episodica** — cosa è successo e quando. Un log strutturato che l'agente legge all'inizio di ogni esecuzione per orientarsi. 3. **Memoria semantica** — cosa sa del mondo, dei clienti o di una base di conoscenza. Recuperata tramite query strutturate o ricerca vettoriale quando rilevante. Non hai sempre bisogno di tutte e tre. La maggior parte degli agenti che eseguo ha bisogno di working + episodica. La memoria semantica è la più difficile da costruire e guadagna il suo posto solo quando la base di conoscenza è troppo grande per entrare nella finestra di contesto. ## Memoria di lavoro: contesto in volo La memoria di lavoro è uno stato che vive per la durata di un'esecuzione dell'agente. La forma più semplice sono variabili nell'ambito della funzione. La forma più interessante è una chiave KV condivisa che le sotto-attività all'interno della stessa esecuzione leggono e scrivono. Il mio agente di risposta social usa la memoria di lavoro per accumulare contesto mentre elabora un batch di commenti in un messaggio di coda. Legge la cronologia delle conversazioni recenti di ogni cliente da KV all'inizio, aggiunge nuovo contesto durante l'elaborazione e riscrive alla fine. ```typescript // workers/social-reply.ts async function processComment( comment: SocialCommentEvent, env: Env ): Promise { // Caricare la cronologia recente di questo cliente da KV (memoria di lavoro) const historyKey = `customer:${comment.userId}:history`; const rawHistory = await env.AGENT_KV.get(historyKey); const history: ConversationTurn[] = rawHistory ? JSON.parse(rawHistory) : []; // Costruire un prompt di sistema contestuale dalla cronologia const systemPrompt = buildSystemPrompt(history); const response = await anthropic.messages.create({ model: "claude-opus-4-8", max_tokens: 512, system: systemPrompt, messages: [{ role: "user", content: comment.text }], }); const reply = response.content[0].type === "text" ? response.content[0].text : ""; // Aggiornare la cronologia — mantenere gli ultimi 10 turni, TTL 30 giorni const updatedHistory: ConversationTurn[] = [ ...history.slice(-9), { role: "assistant", content: reply, timestamp: comment.timestamp }, ]; await env.AGENT_KV.put(historyKey, JSON.stringify(updatedHistory), { expirationTtl: 60 * 60 * 24 * 30, }); await postReply(comment, reply, env); } ``` Due cose da notare. La cronologia è limitata a 10 turni — inietta una finestra scorrevole, non lasciarla crescere senza limiti. E il TTL è di 30 giorni: se un cliente rimane in silenzio per un mese, la cronologia scade e l'agente ricomincia da capo. Entrambe sono intenzionali. ## Memoria episodica: cosa è successo e quando La memoria episodica è il log dell'agente. Un registro strutturato delle esecuzioni passate che l'agente legge all'inizio di ogni nuova esecuzione per evitare di ripetersi. Il mio agente di briefing giornaliero mostrava gli stessi avvisi obsoleti ogni giorno perché ogni esecuzione non aveva consapevolezza di ciò che era già stato segnalato. La soluzione: un log strutturato di avvisi passati che l'agente legge prima di generare il briefing. ```typescript // workers/daily-brief.ts interface AlertLogEntry { id: string; surfacedAt: string; // timestamp ISO resolvedAt?: string; summary: string; } async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); // Caricare la memoria episodica: cosa è già stato segnalato const rawLog = await env.AGENT_KV.get("brief:alert-log"); const alertLog: AlertLogEntry[] = rawLog ? JSON.parse(rawLog) : []; // Filtrare solo gli avvisi recenti e non risolti const sevenDaysAgo = new Date( Date.now() - 7 * 24 * 60 * 60 * 1000 ).toISOString(); const recentAlerts = alertLog.filter( (e) => e.surfacedAt > sevenDaysAgo && !e.resolvedAt ); const brief = await synthesizeBrief( { emails, calendar, tasks, recentAlerts }, env ); // Aggiornare il log con i nuovi avvisi segnalati in questa esecuzione const newAlerts: AlertLogEntry[] = brief.newAlerts.map((a) => ({ id: crypto.randomUUID(), surfacedAt: new Date().toISOString(), summary: a, })); const updatedLog = [...alertLog, ...newAlerts].slice(-100); // mantenere gli ultimi 100 await env.AGENT_KV.put("brief:alert-log", JSON.stringify(updatedLog)); await writeToWorkspace(brief.content, env); } ``` L'agente ora sa cosa ha già detto. Gli avvisi duplicati rimangono fuori dal briefing finché il problema sottostante non cambia. Quando contrassegno un avviso come risolto, scompare dalla lista attiva. Questo pattern si generalizza: qualsiasi agente che produce decisioni, segnalazioni o raccomandazioni beneficia di un log. Il log è economico (pochi KB in KV), il guadagno è alto (niente più output ridondanti). ## Memoria semantica: cosa sai La memoria semantica è la base di conoscenza. Risponde a "cosa sai su X?" al momento della query, invece di stipare tutto nel prompt di sistema in anticipo. La forma più semplice è una ricerca strutturata in KV o in un database. Il mio agente di prenotazione di Pickleland consulta i profili dei clienti e le preferenze dei campi prima di redigere le conferme: ```typescript // workers/booking-agent.ts interface CustomerProfile { userId: string; preferredCourts: string[]; experienceLevel: "beginner" | "intermediate" | "advanced"; specialNotes: string; } async function draftConfirmation( booking: BookingEvent, env: Env ): Promise { // Recuperare il profilo del cliente da KV (memoria semantica — conoscenza fattuale) const profileKey = `customer:${booking.userId}:profile`; const rawProfile = await env.AGENT_KV.get(profileKey); const profile: CustomerProfile | null = rawProfile ? JSON.parse(rawProfile) : null; const systemPrompt = profile ? `Redigi conferme di prenotazione personalizzate. Questo cliente preferisce ${profile.preferredCourts.join(", ")}, è un giocatore ${profile.experienceLevel}. ${profile.specialNotes}` : "Redigi conferme di prenotazione per un impianto di pickleball."; const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 256, system: systemPrompt, messages: [ { role: "user", content: `Redigi una conferma per: ${JSON.stringify(booking)}`, }, ], }); return response.content[0].type === "text" ? response.content[0].text : ""; } ``` Per basi di conoscenza più grandi — documentazione di prodotto, una knowledge base di supporto, qualsiasi cosa troppo grande per entrare in una finestra di contesto — hai bisogno di un archivio vettoriale. Il flusso di lavoro è: incorporare la query, recuperare i k chunk più rilevanti, iniettarli nel contesto. Cloudflare Vectorize gestisce questo nativamente se sei già su Workers. Per indici più grandi ho usato Upstash Vector. La scelta dipende dalla scala, non dal principio. La nota onesta sulla memoria semantica: è la più difficile delle tre da costruire e mantenere. L'indice deve rimanere aggiornato. La qualità del recupero varia. Inizia con ricerche strutturate — KV, una tabella in D1 — e passa alla ricerca vettoriale solo quando l'approccio strutturato non riesce a coprire la superficie di conoscenza di cui hai bisogno. ## Il framework decisionale per la memoria Prima di aggiungere qualsiasi memoria a un agente, rispondi a tre domande: 1. **L'agente deve ricordare tra le esecuzioni?** Se ogni invocazione è genuinamente indipendente — una traduzione, una classificazione, una generazione una tantum — salta la memoria. Stateless è più semplice e più economico. 2. **L'agente si sta ripetendo o sta agendo cieco alla propria storia?** Se sì, aggiungi prima la memoria episodica. È la correzione con il minor sforzo e copre la maggior parte dei reclami "l'agente continua a fare X". 3. **L'agente tratta ogni utente o entità in modo identico quando non dovrebbe?** Se sì, aggiungi memoria di lavoro (cronologia del cliente, profilo utente) o memoria semantica (un sistema di ricerca o recupero). L'errore che vedo più spesso: qualcuno aggiunge un'enorme base di conoscenza (memoria semantica) a un agente che in realtà stava fallendo perché non aveva memoria episodica — nessun log di ciò che aveva già fatto. La complessità non corrisponde al problema. ## Cosa uso davvero in produzione Su 30+ agenti: - **Tutti** hanno almeno la memoria di lavoro — qualche forma di stato all'interno di un'esecuzione, anche se è solo la finestra di contesto stessa. - **Circa la metà** ha memoria episodica — un log delle esecuzioni passate, decisioni o segnalazioni. Questo vale quasi sempre la pena aggiungere. - **Tre o quattro** hanno vera memoria semantica supportata da un archivio vettoriale. Questi sono gli agenti che rispondono a domande su una grande base di conoscenza dinamica. Cloudflare KV è il mio archivio predefinito per la memoria di lavoro ed episodica. È veloce, economico e integrato nativamente in Workers — nessun client extra, nessuna credenziale separata. Il limite: KV è eventualmente coerente e non ottimo per scritture ad alta frequenza. Per gli agenti che scrivono stato molte volte al secondo, uso Durable Objects o un database D1 invece. Per la memoria semantica supportata da vettori, uso Cloudflare Vectorize per indici da piccoli a medi (meno di ~100K vettori) e Upstash Vector per tutto ciò che è più grande. Entrambi hanno client JavaScript di prima classe. ## La conclusione dell'operatore Aggiungi memoria a un agente solo quando il comportamento stateless sta causando problemi reali — output ripetuti, punti ciechi sulla storia del cliente, ignoranza delle decisioni passate. Poi scegli il livello giusto: memoria di lavoro per il contesto in esecuzione, episodica per ciò che è successo storicamente, semantica per ciò che sai. Inizia con l'episodica se non sei sicuro — corregge il modo di fallimento più comune con la minore complessità. Non ricorrere a un database vettoriale finché non hai esaurito le ricerche strutturate. Il miglior sistema di memoria è il più semplice che fa comportare correttamente l'agente. --- **Correlato:** [Lo stack di agenti che uso per gestire 30+ agenti in produzione](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Agenti basati su eventi vs. pianificati](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [Come misuro se un agente IA sta davvero funzionando](/how-i-measure-whether-an-ai-agent-is-actually-working/) **Hai bisogno di aiuto per progettare la memoria degli agenti per il tuo caso d'uso?** [Contattami](/contact/) — progetto sistemi di agenti in produzione per team operativi. --- ## Come costruire una lista email da zero: Il manuale 2026 Source: https://alejandrorioja.com/it/how-to-build-an-email-list/ Published: 2026-06-27 Tags: Entrepreneurship, Growth TL;DR: Una lista email è l'unico canale di distribuzione che possiedi davvero. Inizia con un lead magnet che risolve un problema specifico, posiziona il tuo opt-in sopra la piega e invia una sequenza di benvenuto di 3 email nel momento in cui qualcuno si iscrive. La qualità batte sempre la quantità — 1.000 iscritti coinvolti superano 10.000 freddi in qualsiasi momento. ## Indice _Aggiornato a giugno 2026._ **TL;DR:** Una lista email è l'unico canale di distribuzione che possiedi davvero. Inizia con un lead magnet che risolve un problema specifico, posiziona il tuo opt-in sopra la piega e invia una sequenza di benvenuto di 3 email nel momento in cui qualcuno si iscrive. La qualità batte sempre la quantità — 1.000 iscritti coinvolti superano 10.000 freddi in qualsiasi momento. **[Punto di vista dell'operatore]** Ogni attività in cui sono stato coinvolto e che ha costruito un motore di entrate duraturo aveva una cosa in comune: una lista. Non follower. Non impressioni. Una lista di persone che hanno chiesto di sentirti. Ecco esattamente come costruirne una da zero. ## L'unico asset che possiedi davvero Ogni altro canale di distribuzione può scomparire. Un aggiornamento dell'algoritmo di Google cancella i ranking di ricerca. Un cambiamento di policy della piattaforma uccide la tua portata su Facebook. Un account pubblicitario viene sospeso senza preavviso. La tua lista email è l'eccezione. Quando possiedi una lista email, controlli la consegna. Nessun algoritmo decide chi vede i tuoi contenuti. Nessuna commissione di piattaforma viene riscossa ogni volta che vuoi raggiungere il tuo pubblico. È per questo che costruire una lista email è la prima cosa che dico a ogni fondatore — prima del SEO, prima delle pubblicità a pagamento, prima dei social media. ## Passo 1: Scegli una piattaforma email Prima di raccogliere un solo indirizzo, hai bisogno di una piattaforma per archiviare e inviare. Non usare Gmail. Non usare la tua email aziendale. Usa uno strumento dedicato con un'infrastruttura adeguata per la conformità e la consegnabilità. Le mie due scelte per il 2026: **[ConvertKit](/recommends/convertkit)** — La migliore per creator e operatori in solitaria. Il sistema di tagging e segmentazione degli iscritti è genuinamente eccellente. Gratuito fino a 1.000 iscritti. **[Moosend](/recommends/moosend)** — La migliore per le piccole imprese che vogliono l'automazione senza il prezzo di ConvertKit. Builder drag-and-drop solido e consegnabilità costantemente buona. Se parti da zero, entrambi hanno livelli gratuiti che coprono i tuoi primi centinaia di iscritti. Configura l'autenticazione DKIM, SPF e DMARC sul tuo dominio prima di inviare qualsiasi cosa — è richiesto da Gmail e Yahoo dal 2024 per i mittenti ad alto volume, e protegge la tua reputazione di mittente dal primo giorno. ## Passo 2: Crea un lead magnet che valga la pena scaricare Un lead magnet è quello che offri in cambio dell'indirizzo email di qualcuno. L'errore che commette la maggior parte delle persone: offrire qualcosa di generico. "Iscriviti alla nostra newsletter" non è un lead magnet. È una richiesta di fiducia senza nulla in cambio. Il tuo lead magnet deve risolvere un problema specifico per una persona specifica. Più è specifico, meglio converte. **Formati che funzionano nel 2026:** 1. **Cheat sheet e template** — Una risorsa di una pagina che qualcuno può usare immediatamente. Più è plug-and-play, meglio è. 2. **Mini-corsi (3–5 email)** — Una breve sequenza che insegna una competenza, consegnata automaticamente. Costruisce la lista e il rapporto simultaneamente. 3. **Calcolatrice o foglio di calcolo** — Alto valore percepito. Uno strumento di dimensionamento del mercato, un modello di prezzo, un modello di budget. Questi convertono perché risparmiano lavoro reale. 4. **Dati o ricerche esclusive** — Risultati di sondaggi originali o un report di benchmark. Difficile da replicare, alta credibilità. 5. **Swipe file** — Raccolte di esempi reali (testi pubblicitari, righe oggetto, titoli di landing page). I professionisti pagano per questi. 6. **Webinar o replay di formazione** — Riutilizza una registrazione esistente come opt-in. Richiede 20 minuti di configurazione. Un requisito non negoziabile: il lead magnet deve essere direttamente correlato a ciò di cui scriverai via email. Un template di annuncio Facebook che cattura iscritti per una newsletter B2B SaaS è un disastro di qualità della lista in attesa di accadere. ## Passo 3: Posiziona i moduli di opt-in dove funzionano Il posizionamento del modulo guida la conversione più del testo. Metti i moduli di opt-in dove l'attenzione esiste già: 1. **Sopra la piega nella tua homepage** — Non nel footer. Non nella barra laterale. Sopra la piega, con una descrizione chiara di cosa riceveranno. 2. **Alla fine di ogni post del blog** — Chi ha letto tutto il tuo post è pre-qualificato. Catturalo mentre è ancora coinvolto. 3. **Popup exit-intent** — Si attiva quando un visitatore sta per chiudere il tab. Controverso, ma funziona. 4. **Landing page dedicata** — Una pagina autonoma senza navigazione. Qui invii il traffico a pagamento. 5. **Content upgrade** — Una risorsa che migliora un post specifico. Un foglio di calcolo di dimensionamento del mercato all'interno di una guida TAM/SAM/SOM converte 3–5 volte di più rispetto a un'offerta generica sulla stessa pagina. Consiglio per il testo: inizia con il risultato, non con il formato. "Scarica la guida di 5 pagine" è più debole di "Conosci le dimensioni del tuo mercato come farebbe un VC." ## Passo 4: Scrivi una sequenza di benvenuto Nel momento in cui qualcuno si iscrive, hai la sua massima attenzione. Non sprecarla con il silenzio. Invia almeno 3 email: **Email 1 (immediata):** Consegna il lead magnet. Conferma per cosa si sono iscritti. Stabilisci aspettative per quello che verrà. **Email 2 (giorno 2):** Il tuo miglior pezzo di contenuto — un post, uno studio di caso, un framework. Nessun pitch. Solo prova che iscriversi valeva la pena. **Email 3 (giorni 4–5):** La tua storia d'origine e punto di vista. Perché tieni a questo argomento? Cosa credi che la maggior parte delle persone nel tuo settore non crede? È qui che si costruisce la fiducia. Da lì, mantieni una cadenza regolare. Settimanale è lo standard. Bisettimanale funziona se non riesci a mantenere la qualità settimanalmente. Il peggior errore è inviare una volta al lancio, poi sparire per tre mesi. ## Passo 5: Porta traffico al tuo opt-in Un modulo senza traffico non converte nessuno. I canali di crescita più affidabili: **Ricerca organica** — Post del blog che si classificano per i problemi che risolve il tuo lead magnet. Chi cerca il tuo argomento e trova il tuo post è pre-qualificato per la tua offerta. Questo è il canale meno costoso con il tasso di fidelizzazione più alto. **Social media (organico)** — Post LinkedIn, thread Twitter/X o video brevi che portano le persone alla tua pagina di opt-in. Ogni post dovrebbe essere un teaser, non la storia completa. **Scambi di newsletter e co-promozioni** — Trova newsletter in spazi adiacenti e scambia menzioni. Tu promuovi la loro lista; loro promuovono la tua. Questo è uno dei modi più veloci per crescere da 500 a 5.000 iscritti. **Ospitate in podcast** — Sottovalutato. Un episodio di 30 minuti inviato a 2.000 ascoltatori di nicchia può aggiungere 50–100 iscritti profondamente interessati che hanno più probabilità di aprire ogni email che invii. **Pubblicità a pagamento** — Non fare pubblicità per un'offerta non validata. Fai prima convertire organicamente la tua pagina di opt-in, poi scala con traffico a pagamento. ## Passo 6: Mantieni la lista pulita Una lista email si deteriora. Le persone cambiano lavoro, cambiano email, cambiano interessi. Se non pulisci la tua lista, la tua consegnabilità ne risente — il che significa che anche gli iscritti coinvolti smettono di vedere le tue email. Best practice: - **Campagna di re-engagement ogni 6 mesi** — Invia un'email a chiunque non abbia aperto in 90+ giorni. Dagli un motivo per restare. Se non si coinvolgono, rimuovili. - **Rimuovi immediatamente i hard bounce** — Un alto tasso di rimbalzo segnala ai provider di posta che la tua lista è sporca. - **Segmenta per coinvolgimento** — Tagga separatamente gli iscritti attivi e freddi. Invia campagne sensibili al tempo solo al tuo segmento attivo. Eliminare iscritti sembra perdere qualcosa. In pratica, protegge gli iscritti che vuoi tenere. ## Avvertenze oneste **Costruire richiede tempo.** Partendo da zero con soli metodi organici, aspettati 3–6 mesi per raggiungere 1.000 iscritti. Chiunque prometta migliaia in settimane sta vendendo metriche di vanità o contatti freddi e non coinvolti che non vuoi. **La nicchia conta.** Il pubblico B2B risponde a dati e studi di caso. Il pubblico consumer risponde a sconti e intrattenimento. Il lead magnet e la cadenza dei contenuti devono corrispondere al pubblico. **I lead magnet invecchiano.** Ciò che converte bene oggi potrebbe essere obsoleto in 18 mesi quando i concorrenti copiano il formato. Pianifica di aggiornare il tuo lead magnet annualmente. ## Benchmark realistici | Metrica | Media del settore | Buono | |--------|-----------------|------| | Tasso opt-in popup | 2–4% | 5–8% | | Tasso opt-in landing page | 20–30% | 40–60% | | Tasso apertura email di benvenuto | 50–60% | 70%+ | | Tasso apertura continuativo | 20–25% | 35–45% | | Tasso di clic | 2–3% | 5–10% | Non ottimizzare questi numeri nei primi 90 giorni. Costruisci l'infrastruttura, avvia il lead magnet, invia regolarmente. Poi itera. ## Aggiornato per giugno 2026 **Lead magnet generati dall'IA** — Strumenti come Claude possono redigere una guida PDF di 10 pagine, uno swipe file o un template in pochi minuti. La barriera per creare un lead magnet di alta qualità è quasi nulla. Il differenziatore ora è la specificità della promessa e la rilevanza per il tuo pubblico. **Autenticazione Gmail e Yahoo** — Dal 2024, DKIM, SPF e DMARC sono richiesti per i mittenti che inviano email a più di 1.000 indirizzi al giorno. Sia [ConvertKit](/recommends/convertkit) che [Moosend](/recommends/moosend) ti guidano attraverso la configurazione durante l'onboarding. Fallo prima di averne bisogno. **Traffico da ricerca IA** — Una pagina di opt-in ben strutturata con un TL;DR chiaro e una risposta diretta a una query di ricerca può apparire in ChatGPT, Perplexity e Google AI Overviews. Ho visto pagine di atterrissaggio opt-in generare traffico costante dalla ricerca IA senza alcun lavoro SEO — perché la pagina risponde direttamente a una domanda specifica. ## FAQ **Quanti iscritti mi servono per monetizzare?** Non esiste un numero universale. Ho visto newsletter con 500 iscritti profondamente coinvolti in una nicchia ad alta intenzione superare liste di 20.000 contatti generici. La domanda è se i tuoi iscritti hanno un problema e se si fidano di te per risolverlo. **Dovrei comprare una lista email?** No. Le liste acquistate hanno un coinvolgimento terribile, ti faranno segnalare come spam e possono sospendere il tuo account. Non esiste una scorciatoia. **Con quale frequenza dovrei inviare email?** Più spesso possibile mantenendo la qualità. Settimanale ti mantiene in mente. Il più grande errore è stare in silenzio per mesi e riapparire con un pitch. **Double opt-in o single opt-in?** Double opt-in nella maggior parte dei casi. La conferma riduce la dimensione della lista ma migliora drasticamente il coinvolgimento e la consegnabilità. L'eccezione è quando stai portando traffico ad alta intenzione e verificato da una fonte specifica. **Qual è la migliore piattaforma email per i principianti?** [ConvertKit](/recommends/convertkit) per i creator che costruiscono un marchio personale o un'attività di contenuti. [Moosend](/recommends/moosend) per le piccole imprese che vogliono accessibilità e automazione. Entrambe sono molto migliori che cercare di usare Gmail. ## Dove porterei questo dopo La lista email non vive in isolamento. I tuoi post con le migliori performance dovrebbero avere un content upgrade. Le tue email dovrebbero collegarsi a guide approfondite. Il tuo lead magnet dovrebbe risolvere esattamente il problema che affrontano le tue pagine con più traffico. Quel ciclo — traffico → opt-in → nurturing → fiducia → offerta — è il fondamento di ogni attività online duratura in cui sono stato coinvolto. Se vuoi discutere come implementare tutto questo per la tua situazione specifica, la [pagina dei contatti](/contact) è il posto giusto per iniziare. --- ## Come monetizzare una newsletter: 5 modelli di revenue che funzionano davvero Source: https://alejandrorioja.com/it/how-to-monetize-a-newsletter/ Published: 2026-06-25 Tags: Entrepreneurship, Growth TL;DR: La maggior parte delle newsletter fallisce nella monetizzazione perché insegue il modello sbagliato per le dimensioni della propria lista. I cinque modelli che funzionano: abbonamenti a pagamento (migliore per l'autorità di nicchia), sponsorizzazioni (migliore dopo 5.000+ iscritti), raccomandazioni di affiliazione (minore attrito a qualsiasi dimensione), funnel di corsi e prodotti (massimo potenziale di guadagno) e upsell di servizi (percorso più rapido verso guadagni reali). Inizia con uno. Aggiungi il secondo solo quando il primo funziona. ## Table of contents _Aggiornato a giugno 2026._ **TL;DR:** La maggior parte delle newsletter fallisce nella monetizzazione perché insegue il modello sbagliato per le dimensioni della propria lista. I cinque modelli che funzionano: abbonamenti a pagamento (migliore per l'autorità di nicchia), sponsorizzazioni (migliore dopo 5.000+ iscritti), raccomandazioni di affiliazione (minore attrito a qualsiasi dimensione), funnel di corsi e prodotti (massimo potenziale di guadagno) e upsell di servizi (percorso più rapido verso guadagni reali). Inizia con uno. Aggiungi il secondo solo quando il primo funziona. **[Punto di vista dell'operatore]** Gestisco una newsletter da prima che fosse di moda chiamarla "business di newsletter". La versione onesta del percorso: ho provato a fare tutto in una volta, ho guadagnato quasi nulla, ho ridotto a un modello e ho iniziato a guadagnare. Ecco cosa ho imparato e cosa vedo funzionare in modo coerente tra gli operatori con cui lavoro. ## Perché la maggior parte delle newsletter non guadagna mai un euro Il problema di monetizzazione è generalmente un problema di sequenziamento. Le persone lanciano una newsletter, la fanno crescere lentamente e poi cercano di aggiungere tutti i flussi di entrate in una volta — un livello a pagamento qui, uno slot sponsor lì, un link di affiliazione in ogni numero. Il risultato è una newsletter che sembra un centro commerciale: tutto è in vendita, nulla sembra genuino e i lettori si disengagono. Le newsletter che guadagnano in modo coerente fanno prima una cosa bene. Provano che un modello funziona per il loro pubblico specifico. Poi — e solo allora — ne aggiungono un secondo. Le dimensioni della tua lista determinano anche quali modelli sono praticabili. Una lista da 500 iscritti è lo strumento sbagliato per cercare sponsor. Una lista da 50.000 iscritti sta lasciando denaro significativo sul tavolo se usa solo link di affiliazione. Il modello deve corrispondere alla lista. ## Modello 1: Abbonamenti a pagamento **Migliore per:** Newsletter di autorità di nicchia con un pubblico professionale definito o ad alto interesse. Gli abbonamenti a pagamento sono la forma più pura di monetizzazione della newsletter: i lettori pagano direttamente per il contenuto. Piattaforme come Beehiiv e Substack rendono facile aggiungere questo a una lista gratuita. Cosa lo fa funzionare: - Una nicchia specifica e ad alto valore dove le informazioni sono scarse o risparmiano tempo (analisi finanziaria, intelligence di settore, tattiche a livello operativo) - Una risposta chiara a "cosa ottiene un iscritto pagando che non ottiene gratuitamente?" - Un livello gratuito genuinamente prezioso — non una versione diluita, ma un assaggio dell'approccio del livello a pagamento Cosa lo uccide: - Argomenti generali con bassa urgenza ("consigli di marketing", "sviluppo personale") - Lanciare il pagamento prima di avere la prova che gli iscritti gratuiti leggano il tuo contenuto in modo coerente Entrate realistiche: 5–20 €/mese per iscritto. Con il 5% di conversione da una lista di 2.000 persone, sono 100 iscritti paganti a 10 €/mese = 1.000 € MRR. Piccolo, ma reale, e si accumula. ## Modello 2: Sponsorizzazioni e pubblicità nativa **Migliore per:** Newsletter con 5.000+ iscritti e una demografia del pubblico definita. Le sponsorizzazioni sono il modello più visibile — uno slot di numero venduto a un brand rilevante per il tuo pubblico. Quando funziona, funziona bene: 100–500+ € CPM (costo per mille iscritti) è tipico per un pubblico B2B di nicchia o ad alto reddito. Il vincolo onesto: gli sponsor vogliono scala e specificità. "Ho 1.000 iscritti interessati al marketing" non chiude accordi. "Ho 6.000 iscritti che sono manager di marketing in aziende con 10–500 dipendenti, con un tasso di apertura del 52%" sì. Come arrivarci: 1. **Definisci il tuo pubblico** in termini demografici, non in termini di interessi 2. **Raggiungi 5.000 iscritti** come soglia minima di credibilità prima di approcciare gli sponsor 3. **Dimostra l'engagement** — i tassi di apertura sopra il 40% sono il vero differenziatore 4. **Costruisci un media kit** — un PDF di una pagina con il conteggio degli iscritti, il tasso di apertura, il profilo del pubblico e i pacchetti di sponsorizzazione 5. **Inizia con l'inbound** — elencati nei marketplace di sponsorizzazione prima di costruire un processo di vendita outbound Verifica del CPM: se la tua lista converte al 45% di tasso di apertura e vendi uno slot sponsor per numero a 200 € CPM, una lista da 5.000 iscritti genera 1.000 € per numero sponsorizzato. A quattro numeri al mese, sono 4.000 €/mese da uno slot sponsor. Con due slot, 8.000 €/mese. La matematica funziona — in scala. ## Modello 3: Raccomandazioni di affiliazione **Migliore per:** Qualsiasi dimensione di lista, qualsiasi nicchia dove usi genuinamente strumenti e servizi. Il marketing di affiliazione è il modello con meno attrito per iniziare: raccomandi prodotti che usi davvero, i lettori cliccano e guadagni una commissione sugli acquisti. Nessuna relazione con sponsor da gestire, nessun prodotto da costruire, nessun livello a pagamento da mantenere. Il vincolo chiave è la fiducia. Le raccomandazioni di affiliazione convertono solo quando la raccomandazione è genuinamente utile e credibilmente fondata. Una sezione "scelte migliori" piena di prodotti che non hai mai usato avrà performance inferiori — o peggio, danneggerà la lista. Cosa funziona: - Raccomandare strumenti che usi nel tuo stack personale (per me: [ConvertKit](/recommends/convertkit) per la gestione delle email, [Semrush](/recommends/semrush) per SEO e ricerca dei contenuti) - Posizionamento contestuale — menzionare lo strumento dove è rilevante per il contenuto, non in un blocco fisso "sponsor di questo numero" che i lettori imparano a saltare - Dare un'opinione reale: cosa ti piace, cosa non ti piace e per chi non è adatto Tetto delle entrate: le commissioni di affiliazione variano — gli strumenti SaaS tipicamente pagano il 20–40% in modo ricorrente sugli iscritti convertiti, il che si accumula bene. Una lista da 1.000 iscritti dove il 2% dei lettori converte su un SaaS da 50 €/mese al 30% di commissione = 300 €/mese ricorrenti, crescendo con ogni nuova iscrizione che rimane. ## Modello 4: Funnel di corso e prodotto digitale **Migliore per:** Operatori con autorità di insegnamento in un dominio specifico. La newsletter è la parte superiore del funnel; il corso o prodotto digitale è l'evento di conversione. I lettori che si fidano abbastanza di te da aprire ogni numero sono i lead più qualificati per un prodotto a pagamento che insegna loro qualcosa che sai. Questo è il modello con il massimo potenziale di guadagno quando abbinato anche a una lista modesta. Un corso da 497 € venduto al 2% di una lista da 5.000 persone sono 49.700 € per lancio. A tre lanci all'anno con la crescita della lista, questo si accumula in modo aggressivo. Cosa richiede: - Vera autorità di insegnamento in un dominio specifico — non solo "conosco il marketing" ma "ho fatto crescere tre aziende B2B usando questo specifico playbook di crescita" - Contenuto che dimostra l'autorità settimana dopo settimana (non solo link curati — i tuoi framework originali e casi studio) - Una sequenza di lancio per cui la lista è stata preparata — non un'email fredda "compra il mio corso" da una lista che riceve solo contenuto Questo è il modello su cui mi baso di più nel mio lavoro. La newsletter costruisce la fiducia; il corso la converte. ## Modello 5: Upsell di servizi **Migliore per:** Newsletter in fase iniziale dove l'operatore offre consulenza, coaching o servizi done-for-you. Questo modello è il percorso più rapido verso entrate reali con piccole dimensioni di lista, ed è il più sottoutilizzato. La newsletter ti posiziona come esperto; il servizio è l'esperto al lavoro. Se 500 persone leggono la tua newsletter sul growth marketing e pubblichi un numero al mese che dimostra il tuo pensiero, 1–2 di quei 500 lettori alzeranno periodicamente la mano e chiederanno se fai consulenza. Se non lo offri, hai lasciato entrate sul tavolo. Come renderlo esplicito: - Aggiungi una riga al piè della tua newsletter: "Lavoro con un piccolo numero di clienti per trimestre su [risultato specifico]. Rispondi a questa email se vorresti esplorare questo." - Menziona i risultati dei clienti (anonimizzati) nei numeri rilevanti — non come vanto, ma come prova che i framework funzionano in pratica - Mantieni la capacità intenzionalmente limitata — la scarsità non è artificiale qui, è reale; hai solo una certa quantità di tempo Realtà delle entrate: un cliente di consulenza a 5.000 €/mese e una newsletter da 200 persone ha un'economia migliore di 50.000 iscritti che guadagnano 0,01 €/iscritto in entrate di affiliazione sparse. Non aspettare la scala per iniziare qui. ## Come scegliere il modello giusto Il framework decisionale: | Dimensioni lista | Migliore modello iniziale | Secondo modello da aggiungere | |-----------------|--------------------------|------------------------------| | 0–1.000 | Upsell di servizi | Raccomandazioni di affiliazione | | 1.000–5.000 | Affiliazione + lista d'attesa corso | Abbonamenti a pagamento | | 5.000–20.000 | Sponsorizzazioni | Lancio del corso | | 20.000+ | Sponsorizzazioni + corso | Livello a pagamento | Un vincolo che non cambia a nessuna dimensione: scegli uno per primo. La dispersione dei modelli uccide la conversione su tutti i modelli simultaneamente. ## Lo stack dell'operatore newsletter Strumenti che uso e consiglio per costruire un business di newsletter: - **Piattaforma email:** [ConvertKit](/recommends/convertkit) — tagging degli iscritti, segmentazione e sequenze di automazione che separano gli acquirenti dai lettori - **Ricerca SEO e di argomenti:** [Semrush](/recommends/semrush) — identifica cosa cerca il tuo pubblico target prima di scriverne - **Design:** [Canva](/recommends/canva) — media kit, asset di copertina del corso e contenuto social senza un designer - **Pagamenti:** Stripe — per livelli di abbonamento a pagamento o checkout dei corsi ## La conclusione dell'operatore Una newsletter è l'asset di contenuto con il maggiore leva che puoi costruire nel 2026: l'attenzione nella casella email è scarsa e preziosa in un modo che i feed social non lo sono. Ma l'asset si converte in entrate solo quando scegli un modello che si adatta alle dimensioni della tua lista, lo esegui con raccomandazioni genuinamente e vera autorità, e resisti all'impulso di disperderti su ogni metodo di monetizzazione contemporaneamente. Inizia con il modello che si adatta a dove sei oggi. Quando funziona — in modo coerente, con risultati cumulativi — aggiungi il prossimo. --- **Correlato:** [Come validare un'idea di business prima di realizzarla](/how-to-validate-a-business-idea/) · [Guida alle strategie di growth marketing](/growth-marketing-strategies-guide/) · [6 migliori servizi di email marketing per le piccole imprese](/6-best-email-marketing-services-for-small-business/) --- ## Come Costruire il Tuo Primo Server MCP: Guida Pratica Source: https://alejandrorioja.com/it/how-to-build-your-first-mcp-server/ Published: 2026-06-23 Tags: AI Agents TL;DR: MCP (Model Context Protocol) è come dare a Claude accesso strutturato a strumenti e dati esterni — database, file, API — senza sovraccaricare la finestra di contesto. Il server è più semplice di quanto sembri: installa l'SDK, definisci i tuoi strumenti come JSON schema, implementa i handler, connetti via stdio. In meno di 30 minuti Claude può chiamare i tuoi strumenti personalizzati. ## Indice _Aggiornato giugno 2026._ **TL;DR:** MCP (Model Context Protocol) è come dare a [Claude](/recommends/claude) accesso strutturato a strumenti e dati esterni — database, file, API — senza sovraccaricare la finestra di contesto. Il server è più semplice di quanto sembri: installa l'SDK, definisci i tuoi strumenti come JSON schema, implementa i handler, connetti via stdio. In meno di 30 minuti Claude può chiamare i tuoi strumenti personalizzati. **[Prospettiva dell'operatore]** Collego regolarmente nuovi strumenti ai miei agenti, e MCP è ora la via standard per farlo in modo pulito. Una volta costruito il server, ogni client compatibile — Claude Desktop, Claude Code, qualsiasi app che usa l'SDK Anthropic — può usarlo senza modifiche al codice chiamante. Questo è il valore: costruire una volta, riutilizzare ovunque. ## Cos'è davvero MCP Il **Model Context Protocol** è un protocollo aperto che standardizza come i modelli AI si connettono al contesto esterno e agli strumenti. Pensalo come uno standard USB-C per le integrazioni AI: prima di esso, ogni app che voleva che Claude leggesse un database o chiamasse un'API doveva inventare la propria soluzione. Dopo di esso, costruisci un server MCP e qualsiasi host conforme può usarlo. MCP definisce tre cose che un server può offrire: - **Strumenti** — funzioni che Claude può chiamare (leggere un file, interrogare un DB, inviare un messaggio Slack) - **Risorse** — dati che Claude può leggere (documenti, righe di database, alberi di file) - **Prompt** — template di prompt riutilizzabili che l'host può iniettare Per la maggior parte dei casi d'uso degli operatori, si costruiscono **server di strumenti**. Risorse e prompt vengono dopo, una volta che le basi funzionano. L'architettura è client-server, con il client (Claude Desktop, Claude Code, la tua app personalizzata) che controlla tutto. Il server è passivo — ascolta semplicemente le richieste di chiamata strumenti e restituisce risultati. ## I tre componenti di ogni server MCP Ogni server MCP che costruisci ha la stessa struttura: 1. **L'oggetto server** — dichiara il nome, la versione e le capacità del tuo server (strumenti, risorse, prompt) 2. **Definizioni degli strumenti** — un elenco di strumenti con nomi, descrizioni e JSON schema per i loro input 3. **Handler delle richieste** — le funzioni che vengono eseguite quando Claude chiama uno strumento Tutto qui. Nessun database, nessuno stack HTTP, nessun layer di autenticazione richiesto per iniziare. Il server minimale ha meno di 30 righe di TypeScript. ## Prerequisiti (2 minuti) - **Node.js 18+** — verifica con `node --version` - **TypeScript 5+** (incluso come dipendenza di sviluppo) - Un client MCP per testare — Claude Desktop è gratuito ed è il modo più semplice per vedere il tuo server funzionare Non è necessaria una chiave API Anthropic per eseguire un server MCP. La chiave API vive nel client (Claude Desktop), non nel tuo server. ## Passo 1: Configurare il progetto (3 minuti) ```bash mkdir my-mcp-server && cd my-mcp-server npm init -y npm install @modelcontextprotocol/sdk npm install -D typescript tsx @types/node ``` Aggiungi a `package.json`: ```json { "type": "module", "scripts": { "build": "tsc", "dev": "tsx src/index.ts" } } ``` Crea `tsconfig.json`: ```json { "compilerOptions": { "target": "ES2022", "module": "Node16", "moduleResolution": "Node16", "outDir": "./build", "strict": true }, "include": ["src/**/*"] } ``` ## Passo 2: Scrivere il server minimale (5 minuti) Crea `src/index.ts`: ```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { CallToolRequestSchema, ListToolsRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; const server = new Server( { name: "my-mcp-server", version: "1.0.0" }, { capabilities: { tools: {} } } ); // Dichiara quali strumenti offre questo server server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [ { name: "get_word_count", description: "Conta le parole in un blocco di testo.", inputSchema: { type: "object", properties: { text: { type: "string", description: "Il testo in cui contare le parole", }, }, required: ["text"], }, }, ], })); // Gestisce le chiamate agli strumenti dal client server.setRequestHandler(CallToolRequestSchema, async (request) => { const { name, arguments: args } = request.params; if (name === "get_word_count") { const { text } = args as { text: string }; const count = text.trim().split(/\s+/).filter(Boolean).length; return { content: [{ type: "text", text: `Conteggio parole: ${count}` }], }; } throw new Error(`Strumento sconosciuto: ${name}`); }); // Connetti via stdio — così Claude Desktop parla con il server const transport = new StdioServerTransport(); await server.connect(transport); ``` Questo è il server completo. Registra uno strumento (`get_word_count`) e lo implementa. La struttura è ciò che conta. ## Passo 3: Compilare e registrare in Claude Desktop (5 minuti) Compila TypeScript: ```bash npm run build ``` Ora registralo nel file di configurazione di Claude Desktop. Su **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json` Su **Windows**: `%APPDATA%\Claude\claude_desktop_config.json` Se il file non esiste, crealo: ```json { "mcpServers": { "my-mcp-server": { "command": "node", "args": ["/percorso/assoluto/a/my-mcp-server/build/index.js"] } } } ``` Usa il percorso assoluto. Riavvia Claude Desktop dopo il salvataggio. Vedrai un'icona a martello (🔨) nell'input del messaggio — significa che Claude ha scoperto i tuoi strumenti. ## Passo 4: Costruire uno strumento utile Il conteggio delle parole è illustrativo. Ecco uno strumento più utile: leggere file da una directory di progetto, che uso per agenti di iniezione di contesto che riassumono codebase, changelog o file di configurazione. ```typescript import { readFileSync, readdirSync } from "fs"; import { join, extname } from "path"; const ALLOWED_EXTENSIONS = [".md", ".txt", ".ts", ".json", ".yaml"]; const PROJECT_DIR = process.env.PROJECT_DIR ?? process.cwd(); ``` La logica è la stessa: definisci gli strumenti con JSON schema precisi, implementa gli handler, valida gli input per prevenire il path traversal e restituisci testo al client. ## Gli errori che ho fatto (perché tu non li faccia) **Il percorso deve essere assoluto.** I percorsi relativi nella config di Claude Desktop non si risolvono come ci si aspetta. Usa sempre il percorso completo `/home/utente/...`. **Stdio significa nessun `console.log` nel tuo server.** Claude Desktop comunica con il tuo server via stdin/stdout. Un `console.log` di debug corrompe lo stream JSON-RPC. Logga su stderr: ```typescript process.stderr.write(`Debug: ${message}\n`); ``` **Riavvia Claude Desktop dopo ogni modifica alla config.** I server MCP vengono caricati all'avvio. Un file di config modificato non fa nulla finché non chiudi e riapri l'app. **Le descrizioni degli strumenti sono il prodotto.** Claude decide se chiamare il tuo strumento in base al campo `description`. Una descrizione vaga significa che Claude non saprà quando usarlo. Una precisa significa che Claude la usa al momento giusto. Investi più tempo nelle descrizioni che nell'implementazione. ## Come uso i server MCP in produzione Il pattern stdio funziona benissimo per Claude Desktop e Claude Code (locale). Per gli agenti in produzione — i [30+ che eseguo su Cloudflare Workers](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — uso direttamente l'API tool-use dell'SDK Anthropic, perché ho bisogno della flessibilità di instradare verso [Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet) per ogni passo. I pattern che uso davvero in produzione: 1. **Tooling di sviluppo locale** — server MCP per Claude Code che espongono strumenti specifici del progetto 2. **Iniezione di contesto** — server MCP che precaricano doc rilevanti senza copiare manualmente 3. **Bridge prototipo-to-API** — costruisco prima MCP (più veloce da iterare), poi migro la logica all'SDK tool-use per la produzione ## Cosa costruire dopo Una volta compresa la struttura del server, gli strumenti utili sono quelli che accedono al contesto esterno di Claude: - **Lettore di database** — esegue una query SQL in sola lettura e restituisce risultati come JSON - **Lettore Slack** — recupera gli ultimi N messaggi da un canale - **Lettore GitHub** — elenca le PR aperte, legge un file a un commit specifico - **Wrapper API interna** — chiama la tua API REST con gli header di autenticazione integrati ## FAQ ### Ho bisogno di una chiave API Anthropic per costruire un server MCP? No. Il tuo server MCP non chiama l'API Anthropic. Risponde semplicemente alle richieste di chiamata degli strumenti dal client. La chiave API vive nel client, non nel server. ### Il mio server MCP può chiamare API esterne? Sì — l'handler è solo codice TypeScript asincrono. Recupera un'API meteo, interroga un database, scrivi su un file. Al server non importa cosa fa l'handler internamente. ### Qual è la differenza tra i trasporti stdio e HTTP? Stdio è per server locali — stessa macchina di Claude Desktop o Claude Code. HTTP con SSE è per server remoti che puoi distribuire come servizio web. Inizia con stdio; è più semplice da debuggare. ### Come fa Claude a sapere quando chiamare il mio strumento? Claude decide in base al campo `description` dello strumento e al contesto della conversazione. Se Claude continua a ignorare il tuo strumento, raffina la descrizione. --- ## Come validare un'idea di business prima di realizzarla Source: https://alejandrorioja.com/it/how-to-validate-a-business-idea/ Published: 2026-06-20 Tags: Entrepreneurship, Growth TL;DR: La maggior parte delle idee di business fallisce non per una cattiva esecuzione, ma perché si salta la validazione. Il percorso più rapido: conferma che il problema esiste tramite la domanda di ricerca e le prove nei forum, analizza i concorrenti per dimostrare che qualcuno sta già guadagnando, costruisci il più piccolo test possibile e ottieni un impegno — un deposito, un'iscrizione alla lista d'attesa, una lettera di intenti — prima di costruire qualsiasi cosa. Se non riesci a ottenere che una sola persona si impegni, l'idea non è pronta. ## Table of contents _Aggiornato a giugno 2026._ **TL;DR:** La maggior parte delle idee di business fallisce non per una cattiva esecuzione, ma perché si salta la validazione. Il percorso più rapido: conferma che il problema esiste tramite la domanda di ricerca e le prove nei forum, analizza i concorrenti per dimostrare che qualcuno sta già guadagnando, costruisci il più piccolo test possibile e ottieni un impegno — un deposito, un'iscrizione alla lista d'attesa, una lettera di intenti — prima di costruire qualsiasi cosa. Se non riesci a ottenere che una sola persona si impegni, l'idea non è pronta. **[Prospettiva dell'operatore]** Ho visto questo schema decine di volte nei fondatori con cui ho lavorato e nei miei stessi progetti: l'idea sembra convincente, il fondatore è appassionato, l'esecuzione è solida — e poi lanciano nel silenzio. Non perché hanno costruito la cosa sbagliata, ma perché hanno saltato l'unico passaggio che gliel'avrebbe detto prima di passarci sei mesi. Ecco il framework di validazione che uso e raccomando. ## Perché la maggior parte degli sforzi di validazione fallisce Il modo ovvio di fallire è nessuna validazione — costruire prima, fare domande dopo. Ma la trappola più sottile è il teatro della validazione: condurre sondaggi, parlare con gli amici, raccogliere risposte vaghe del tipo "ottima idea!" e chiamarle un segnale. I sondaggi mentono. Le persone sono educate. Alla domanda "Pagheresti 50 $ per questo?" in un contesto ipotetico, la risposta è quasi sempre sì. L'unico segnale che conta è l'impegno: qualcuno che ti dà effettivamente denaro, tempo o una lettera di intenti scritta. Tutto il resto è riduzione del rumore, non validazione. ## Passo 1: Conferma che il problema esiste davvero su larga scala Prima di validare la tua soluzione, valida che il problema sia reale e ricercato. **La domanda di ricerca è il proxy più rapido.** Digita il tuo problema su Google. Guarda i suggerimenti di completamento automatico, la sezione "Le persone chiedono anche" e le pagine meglio posizionate. Se non ci sono risultati, nessuno sta cercando — e un business che risolve un problema che nessuno cerca spenderà tutta la sua energia nell'educazione piuttosto che nella conversione. Usa uno strumento per le parole chiave come [Semrush](/recommends/semrush) per verificare il volume mensile effettivo di ricerche. Un problema con 1.000–10.000 ricerche mensili nel tuo mercato di riferimento è praticabile. Un problema con 20 ricerche al mese è un prodotto di nicchia con un problema di distribuzione. **Le prove nei forum sono uno strato qualitativo aggiuntivo.** Cerca su Reddit, Quora, gruppi Facebook di nicchia e comunità Discord il tuo problema. Le persone si lamentano attivamente? Cercano soluzioni? Alternative? La vera frustrazione è oro — significa che il dolore è abbastanza forte da motivare le persone a cercare aiuto pubblicamente. Se non riesci a trovare 20 thread nei forum di persone reali che descrivono il problema, sii scettico. ## Passo 2: Analizza i concorrenti — prova che il denaro esiste già Un istinto comune dei fondatori: "non c'è concorrenza, quindi dominerò il mercato." Questo è quasi sempre sbagliato. Nessuna concorrenza di solito significa nessun mercato. La concorrenza è la prova che i clienti esistono e pagheranno. Cerca su Google la tua categoria di soluzioni. Chi sta posizionando? Cosa promettono le loro landing page? Quanto fanno pagare? Leggi le loro testimonianze e recensioni — specialmente quelle negative. Le recensioni negative sono una roadmap del prodotto: ti mostrano esattamente cosa vuole il mercato ma non sta ottenendo. Se trovi 3–5 concorrenti affermati con prodotti reali e clienti reali, è un segnale positivo. Se ne trovi zero, scava più a fondo prima di concludere che il mercato non esiste — o trattalo come un segnale d'allarme. **Domande chiave a cui rispondere:** 1. Chi sono i 3–5 principali attori? 2. Quanto fanno pagare? 3. Cosa stanno criticando i recensori? 4. C'è un gap di posizionamento che posso occupare? ## Passo 3: Costruisci il più piccolo test possibile Una volta che sai che il problema esiste e c'è denaro nel mercato, costruisci l'artefatto minimo necessario per testare se *la tua* versione guadagna trazione. Questo non è un prodotto completo. È un meccanismo di cattura del segnale. **Opzione A: Landing page con acquisizione email.** Un sito di una pagina che descrive il problema e la soluzione, con un CTA "Unisciti alla lista d'attesa" o "Ottieni accesso anticipato". Il tasso di conversione ti dice se il tuo posizionamento risuona. Strumenti come Webflow, Carrd o persino una pagina pubblica di Notion vanno bene — non complicare troppo. **Opzione B: Pre-vendita.** Un vero flusso di pagamento con denaro reale. Questo è il segnale di qualità più elevata. Se qualcuno ti dà denaro per qualcosa che non esiste ancora, crede nella soluzione. Funziona anche un deposito rimborsabile. **Opzione C: MVP concierge.** Fai la cosa manualmente prima di automatizzarla. Consulenza invece di un SaaS. Un foglio di calcolo personalizzato invece di uno strumento software. Una newsletter curata manualmente invece di una generata dall'IA. Servi una manciata di clienti con la forza bruta, impari esattamente cosa valorizzano, poi costruisci il prodotto attorno a ciò. ## Passo 4: Ottieni un impegno prima di costruire Questo è il portello che separa la vera validazione dal pensiero magico. Definisci cosa significa "impegno" per la tua idea prima di eseguire il test: - **SaaS / software:** Una pre-vendita a prezzo scontato, o una lettera di intenti firmata - **Contenuto / media:** Iscritti email che hanno cliccato per unirsi (non solo follower) - **Servizi / consulenza:** Una chiamata di scoperta a pagamento o una proposta firmata - **Prodotto fisico:** Un deposito o un pre-ordine su Kickstarter Se non riesci a ottenere che almeno una persona si impegni — anche con uno sconto, anche con una garanzia di rimborso — l'idea non è pronta. Non è un fallimento; è il sistema che funziona. Ti ha risparmiato mesi di tempo di sviluppo. ## Passo 5: Stabilisci una soglia di successo/fallimento prima di iniziare La trappola è questa: esegui il tuo test, ottieni risultati tiepidi e ti convinci di procedere comunque. "Il testo della landing page non era buono." "Non l'ho promosso abbastanza." "Ha solo bisogno di più tempo." Fermati. Prima di eseguire il test, scrivi la soglia: > "Se ottengo 50 iscrizioni alla lista d'attesa in 14 giorni con 0 € in annunci a pagamento, costruisco. Se non raggiungo 50, non costruisco — o cambio il posizionamento o chiudo l'idea." Scrivila. Dillo a un amico. Rendila pubblica se puoi. Poi rispettala. Il numero è arbitrario; ciò che conta è che decidi in anticipo e non sposti i paletti quando i dati arrivano freddi. ## Errori comuni di validazione 1. **Chiedere alle persone se comprerebbero.** Quasi sempre dicono sì per cortesia. L'unica domanda che conta è: "Lo compri adesso?" 2. **Validare con amici e famiglia.** Ti stanno supportando. Non sono i tuoi clienti. 3. **Risolvere il proprio problema senza verificare se altri ce l'hanno.** Il tuo problema potrebbe essere unico per te. Controlla i forum. 4. **Chiamare le risposte ai sondaggi una validazione.** Un sondaggio può generare idee. Non può validare la domanda. Solo il denaro o un impegno genuino possono farlo. 5. **Aspettare informazioni perfette.** La validazione consiste nell'ottenere abbastanza segnale per fare il passo successivo, non nell'eliminare completamente l'incertezza. ## Cosa significano i segnali "vai" Stai cercando una combinazione di: 1. Volume di ricerca superiore a 1.000 ricerche mensili per la parola chiave principale del problema 2. Attività della concorrenza — 3+ attori reali che fanno pagare denaro reale 3. Almeno 20 thread nei forum o comunità che mostrano frustrazione attiva per il problema 4. Un tasso di conversione del test superiore al 5% sul traffico mirato 5. Almeno una persona si impegna — paga, firma o deposita — senza che tu debba supplicare Raggiungi tutti e cinque e hai una direzione praticabile. Raggiungi due o tre e hai un segnale che vale la pena affinare. Raggiungi zero e hai bisogno di un'idea o pubblico fondamentalmente diverso. ## Lo stack di validazione Gli strumenti che uso e raccomando per questo processo: - **Domanda di ricerca:** [Semrush](/recommends/semrush) — volume di parole chiave, analisi della concorrenza e lacune di contenuto in un unico posto - **Ricerca nei forum:** Reddit, Quora, gruppi Facebook di nicchia, comunità Discord - **Landing page:** Carrd (gratuito, veloce) o Webflow per più controllo del design - **Acquisizione email / lista d'attesa:** Kit (ConvertKit) per iniziare a costruire la lista mentre si valida - **Pagamenti:** Stripe — collega direttamente a un checkout prima di costruire il prodotto - **Analytics:** Google Analytics sulla tua pagina di test per tracciare il comportamento reale ## La conclusione dell'operatore La cosa più costosa che puoi costruire è un prodotto che nessuno vuole. La validazione non riguarda l'eliminazione del rischio — riguarda il fallire velocemente su carta piuttosto che fallire lentamente in produzione. Esegui il test, ottieni un impegno, stabilisci la soglia prima di iniziare e rispetta il risultato. Se il segnale c'è, lo saprai. Se non c'è, lo saprai anche quello. --- **Correlato:** [Come costruire un business redditizio](/how-to-build-profitable-business/) · [Guida alle strategie di growth marketing](/growth-marketing-strategies-guide/) · [Come diventare un imprenditore](/how-to-become-an-entrepreneur/) --- ## Prompt caching con la Claude API: riduci i costi di input senza cambiare modello Source: https://alejandrorioja.com/it/prompt-caching-cut-your-claude-costs-without-switching-models/ Published: 2026-06-18 Updated: 2026-06-18 Tags: AI Agents, Operations TL;DR: Il prompt caching riduce il costo degli input grandi e stabili — il tuo system prompt, le definizioni dei tool, gli esempi few-shot — a circa il 10% del prezzo normale di input sulle richieste ripetute. Il meccanismo è un prefix match: metti un marcatore cache_control alla fine del contenuto stabile e tieni tutto ciò che è volatile dopo di esso. L'errore che azzera il tasso di cache hit è lasciare che un timestamp o un UUID fluttuino nel prefisso. ## Table of contents _Aggiornato a giugno 2026._ **TL;DR:** Il prompt caching riduce il costo degli input grandi e stabili — il tuo system prompt, le definizioni dei tool, gli esempi few-shot — a circa il 10% del prezzo normale di input sulle richieste ripetute. Il meccanismo è un prefix match: metti un marcatore `cache_control` alla fine del contenuto stabile e tieni tutto ciò che è volatile dopo di esso. L'errore che azzera il tasso di cache hit è lasciare che un timestamp o un UUID fluttuino nel prefisso. **[Il punto di vista dell'operatore]** Gestisco oltre 100 agenti tra il mio brand di consulenza e Pickleland. La voce di costo più pesante non è il tier del modello: è quanto spesso re-invio lo stesso system prompt da 4.000 token a ogni richiesta. Il prompt caching ha ridotto quel costo quasi a zero sugli agenti ad alta frequenza, senza toccare il modello né la qualità dell'output. Ecco esattamente come funziona e dove si nascondono le trappole. ## Cosa fa davvero il prompt caching Ogni chiamata alla [Claude](/recommends/claude) API invia dei token. Senza caching, ogni token nella tua richiesta — system prompt, definizioni dei tool, esempi few-shot e il messaggio dell'utente — viene tariffato alla normale tariffa di input. Con il caching, un prefisso di quei token viene memorizzato sui server di Anthropic dopo la prima richiesta. Sulle richieste successive che condividono quell'esatto prefisso, paghi un prezzo di *lettura* dalla cache invece di rielaborarli da zero. La differenza di costo è concreta: - **Cache write:** ~1,25× il prezzo base di input (TTL di 5 minuti) oppure ~2× (TTL di 1 ora) - **Cache read:** ~0,1× il prezzo base di input - **Punto di pareggio:** 2 richieste con TTL di 5 minuti, 3 richieste con TTL di 1 ora Una volta superato il punto di pareggio — cosa che avviene in fretta su qualsiasi agente eseguito più di poche volte al giorno — ogni cache hit aggiuntivo è uno sconto del ~90% su quei token. ## L'invariante del prefix-match È l'unica regola da cui discende tutto il resto: **la chiave di cache è un prefix match del tuo prompt renderizzato**. I server di Anthropic memorizzano il contenuto renderizzato dall'inizio del prompt fino al marcatore `cache_control`. Perché alla richiesta successiva si verifichi un cache hit, ogni token dall'inizio del prompt fino a quel marcatore deve essere identico — byte per byte. L'ordine di rendering per il prefix matching è: tools → system → messages. Quindi prima viene calcolato l'hash dell'array dei tool, poi del blocco system, poi dei messaggi in ordine. Cosa significa in pratica: il contenuto stabile deve venire per primo. Se il tuo system prompt fa riferimento a qualcosa di dinamico — la data corrente, un ID utente, un trace ID della richiesta — e questo appare *prima* del marcatore `cache_control`, la cache farà miss a ogni richiesta perché il prefisso continua a cambiare. ## Su cosa mettere un marcatore di cache I bersagli a maggior leva sono: **1. Il tuo system prompt** I system prompt sono di solito il blocco stabile più grande. Una persona dettagliata per l'agente, un elenco di regole comportamentali, un insieme di istruzioni sul formato dell'output — tutto questo è identico a ogni invocazione dello stesso agente. Marcalo: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, system: [ { type: "text", text: `You are a content operations agent for alejandrorioja.com. Your job is to draft blog posts in Alejandro's voice: direct, practitioner, first-person, numbered lists, honest caveats. No hedging. No filler. Every section must earn its place. [... 2000 more tokens of stable instructions ...]`, cache_control: { type: "ephemeral" }, }, ], messages: [ { role: "user", content: "Draft a post about prompt caching.", }, ], }); ``` Il `cache_control: { type: "ephemeral" }` sul blocco system dice a Claude di mettere in cache tutto fino a quel blocco incluso. L'array `messages` è volatile — diverso a ogni richiesta — e resta fuori dal confine della cache. **2. Le definizioni dei tool** Se il tuo agente usa dei tool, quelle definizioni possono essere consistenti. Uno schema di tool ben documentato, con descrizione, nomi dei parametri e valori enum, può arrivare a 500–1.000 token per tool. Con 5 tool, sono fino a 5.000 token che paghi per rielaborare a ogni chiamata: ```typescript const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, tools: [ { name: "search_airtable", description: "Search the Airtable content queue...", input_schema: { type: "object", properties: { query: { type: "string" } } }, }, // ... more tools ... { name: "post_to_kit", description: "Schedule a broadcast via the Kit API...", input_schema: { /* ... */ }, // Mark the last tool to cache the entire tools array } as Anthropic.Tool & { cache_control: { type: "ephemeral" } }, ], system: "...", messages: [...], }); ``` Marca l'*ultimo* tool nell'array. Il prefix match coprirà l'intero array dei tool a partire da quel punto. **3. Gli esempi few-shot nei messaggi** Se passi esempi few-shot statici come messaggi iniziali nell'array `messages`, anche quelli possono essere messi in cache. Strutturali come i primi N messaggi e marca l'ultimo turno di esempio: ```typescript const messages: Anthropic.MessageParam[] = [ { role: "user", content: [ { type: "text", text: "Here are examples of posts in my voice:\n\n[Example 1...]\n\n[Example 2...]", cache_control: { type: "ephemeral" }, } as Anthropic.TextBlockParam & { cache_control: { type: "ephemeral" } }, ], }, { role: "assistant", content: "Understood. I'll follow that voice.", }, // The actual user turn follows — this is volatile, no cache marker { role: "user", content: actualUserRequest, }, ]; ``` ## Cosa NON mettere in cache (gli invalidatori silenziosi) Sono le cose che sembrano stabili ma non lo sono — e azzerano il tuo hit rate in silenzio. La API non ti avvisa. Vedrai semplicemente `cache_creation_input_tokens` a ogni richiesta e ti chiederai perché. **I timestamp nel system prompt.** L'errore più comune in assoluto: ```typescript // This invalidates the cache on every request const system = `You are an agent. Current time: ${new Date().toISOString()}`; ``` Sposta i timestamp nel messaggio dell'utente, dove è giusto che stiano: ```typescript // Stable system prompt — cacheable const system = `You are an agent. Use the current time provided by the user.`; // Volatile user message — not cached const userMessage = `Current time: ${new Date().toISOString()}. Run the daily brief.`; ``` **UUID casuali e trace ID.** Stesso problema. Se inietti un trace ID nel blocco system per il logging, ogni richiesta ottiene un prefisso nuovo. **Serializzazione JSON non deterministica.** Se serializzi un oggetto dentro il system prompt e l'ordine delle chiavi non è garantito, la stringa renderizzata può differire anche quando i dati sottostanti sono gli stessi. Serializza con un ordine delle chiavi stabile oppure usa una template string. **Selezione dinamica dei few-shot.** Se scegli gli esempi few-shot in base alla query corrente e li metti nel prefisso in cache, hai reso il prefisso "stabile" dipendente dalla query. O ti impegni a usare esempi fissi per il layer di cache, oppure sposti gli esempi dinamici nel turno di messaggio non messo in cache. ## Verificare il tuo tasso di cache hit Ogni risposta include i metadati di utilizzo. Controllali: ```typescript const response = await client.messages.create({ /* ... */ }); console.log({ inputTokens: response.usage.input_tokens, cacheRead: response.usage.cache_read_input_tokens, cacheWrite: response.usage.cache_creation_input_tokens, outputTokens: response.usage.output_tokens, }); ``` Alla prima richiesta: `cache_creation_input_tokens` sarà diverso da zero, `cache_read_input_tokens` sarà 0. Questa è la scrittura. In caso di cache hit: `cache_read_input_tokens` sarà diverso da zero, `cache_creation_input_tokens` sarà 0. Questa è la lettura. Se vedi `cache_creation_input_tokens` a ogni richiesta, il tuo prefisso sta cambiando. Aggiungi un'istruzione di log che stampi i primi 200 caratteri del tuo system prompt renderizzato prima di ogni chiamata: un timestamp che fluttua salterà fuori immediatamente. ## Il TTL di 1 ora: quando vale il costo di scrittura extra Il TTL predefinito è di 5 minuti. Se il tuo agente gira a bassa frequenza — meno di una volta ogni 5 minuti — pagherai costi di cache write sulla maggior parte delle richieste senza ottenere letture. ```typescript // Opt into a 1-hour TTL cache_control: { type: "ephemeral", ttl: "1h" } ``` La scrittura a 1 ora costa ~2× il prezzo base di input invece di 1,25×. La matematica: se colpisci la cache 3 o più volte all'ora, il TTL di 1 ora ti fa risparmiare. Se il tuo agente gira una volta al giorno (come il mio daily brief), nemmeno il TTL di 1 ora aiuta — paghi costi di scrittura ogni volta. In quel caso il vantaggio del caching è modesto, a meno che il system prompt non sia enorme. Il mio agente di daily brief ha un system prompt da 3.000 token ma gira una volta al giorno. Il caching non aiuta. Il mio agente per la newsletter gira decine di volte per sessione mentre redige le bozze — il caching fa risparmiare parecchio. ## Pre-warming: rendere economica la prima richiesta Se sai che è in arrivo un picco di traffico — un batch job, il lancio di una API — puoi pre-riscaldare la cache con una richiesta fittizia a basso costo: ```typescript // Pre-warm: write the cache at near-zero output cost await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1, // minimal output system: [{ type: "text", text: stableSystemPrompt, cache_control: { type: "ephemeral" } }], messages: [{ role: "user", content: "ping" }], }); // Now the real requests read from cache ``` Questo è utile soprattutto per l'elaborazione batch, quando avvii molte richieste parallele e vuoi che ognuna colpisca una cache calda invece di gareggiare per scriverla. ## Il prompt caching nei loop agentici In un loop agentico multi-turno, la cronologia della conversazione cresce a ogni turno. La cache è abbastanza intelligente da gestirlo: usa una finestra di lookback di 20 blocchi, trovando il prefisso corrispondente più lungo tra gli ultimi 20 content block. L'implicazione pratica: tieni il tuo contenuto stabile (system prompt, definizioni dei tool) ancorato all'inizio. La cronologia della conversazione che cresce in coda all'array dei messaggi non spezzerà il prefix match dei blocchi stabili — sono prima del contenuto volatile, e il prefix match parte dall'alto. In pratica, i miei agenti strutturano i turni così: ``` System (cached) → Tools (cached) → Few-shot (cached) → Turn 1 → Turn 2 → ... → Current turn ``` La cache copre tutto fino al marcatore dei few-shot. La cronologia dei turni che cresce dopo di esso viene rielaborata ogni volta, ma va bene così — quei token sono specifici della sessione e piccoli rispetto al prefisso stabile. ## Come si vede sulla fattura Prendi un agente ad alta frequenza: 100 chiamate al giorno, system prompt da 4.000 token, pricing di Sonnet. Senza caching: - 100 × 4.000 token × 3 $/1M = **1,20 $/giorno** Con caching (TTL di 5 minuti, ipotizzando 50 chiamate/ora nei picchi): - 1 scrittura ogni 5 minuti × 3,75 $/1M × 4.000 token = ~0,02 $/giorno in scritture - ~98 letture/giorno × 0,30 $/1M × 4.000 token = **0,12 $/giorno in letture** È circa una riduzione del 90% su quei token di input. Su scala — 1.000 chiamate al giorno — la differenza si moltiplica ulteriormente. E questo si aggiunge a qualsiasi risparmio dal routing dei modelli derivante dalla [matematica Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet): il caching funziona a ogni tier. ## La conclusione dell'operatore Il prompt caching è l'ottimizzazione di costo più facile nella Claude API: un campo aggiuntivo sui content block che stai già scrivendo. Il vincolo è la disciplina attorno alla stabilità del prefisso — niente di dinamico prima del marcatore di cache. Se riesci a tenere il tuo system prompt, i tool e qualsiasi esempio statico liberi da contenuto volatile, pagherai il ~10% del normale costo di input su ogni cache hit. Per gli agenti ad alta frequenza con prompt grandi e stabili, questa è una leva più grande del cambiare tier di modello. --- **Correlati:** [La matematica dei costi degli AI agent: quando Haiku batte Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Agenti event-triggered vs schedulati](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [I 5 strumenti AI che uso davvero per gestire la mia attività](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) --- ## 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](/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](/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, oppure usa uno strumento di verifica dedicato come [mentioned.at](https://mentioned.at) se non vuoi costruirti l'agente da solo. 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-24 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-18 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-19 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-18 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-18 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-22 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: