Rapporto di ricerca interno datato **12 agosto 2026** (in formato *What? — So What? — Now What?*, indagine condotta tra l'11 e il 12 agosto) su una domanda semplice: le applicazioni **desktop** di ChatGPT e Claude sono migliori delle rispettive versioni **web**? La risposta si articola in due parti. **(A) Esiste un consenso qualitativo solido e ben documentato.** Il punto di partenza è indiscutibile: desktop e web richiamano esattamente gli stessi modelli cloud, l'applicazione essendo solo un'interfaccia verso il servizio — il guadagno risiede quindi interamente nell'involucro applicativo (latenza d'accesso, stabilità nelle sessioni lunghe, impronta di memoria, integrazioni di sistema, fluidità del workflow). Ciò che distingue realmente il desktop, confermato: sul versante OpenAI, una scorciatoia globale (Option/Alt + Spazio), una *companion window* che resta sempre in primo piano, screenshot nativi e, da luglio 2026, la capacità agentica **Codex/Work** integrata nell'app; sul versante Anthropic, **Quick Entry** (macOS), **Desktop Extensions** (installare un server **MCP** locale diventa *"semplice quanto cliccare un pulsante"*), accesso ai file locali, **Cowork** e **Computer Use** (permessi di Accessibilità e registrazione dello schermo). Il web conserva due punti di forza confermati: schede/thread multipli e universalità senza client da installare. **(B) Quasi tutte le cifre in circolazione a sostegno di questo consenso non reggono alla verifica.** L'audit critico del rapporto (§1.5) classifica come **non confermate** sette affermazioni numeriche ampiamente ripetute: il *cold start* "2-3 s contro 8-12 s" (l'unica traccia essendo un aneddotico *"si carica in circa 3 secondi"* su Substack); l'uso di RAM "200-700 MB contro 1,2-2 GB", attribuito a un "Alibaba Product Insights" le cui pagine restituiscono **404**; una percentuale di malfunzionamenti e un dato di retention delle sessioni non rintracciabili; un "Claude +10-20% end-to-end" attribuito a **Skywork**, che in realtà aveva confrontato il proprio agente Windows piuttosto che Claude rispetto al web; una fonte "Cosmo Edge" non rintracciabile; citazioni Zenken AI non confermate; e due post X non autenticati e privi di URL. Il controsegnale è documentato con lo stesso rigore: Yuri Dvoinos descrive un'app Claude Desktop che *"mi fa venire voglia di buttare il portatile dalla finestra"* — utilizzo CPU al 68%, input lag su un MacBook Pro — e il rapporto rileva che entrambe le app sono build **Electron** con livelli nativi. Da qui la formulazione: *il vantaggio del desktop è una promessa di implementazione, non una legge di natura.* **Il "So What"**: poiché il modello è diventato il comune denominatore, l'interfaccia diventa il terreno di scontro — la fusione **Codex + ChatGPT** del 9 luglio 2026 e il tandem Cowork/Computer Use raccontano la stessa storia, *"l'app desktop non è più un client di chat, è un runtime agentico con accesso alla macchina."* Tre conseguenze: il guadagno è un guadagno di **attrito**, non di potenza; per un CIO, il desktop **sposta il confine di fiducia** — Computer Use richiede permessi di sistema sensibili e la fusione Codex colloca esecuzione del codice, browser e connettori all'interno di *"un unico confine di fiducia esteso,"* mentre il browser resta governabile tramite SSO, DLP e CASB; e per chi pubblica, la fragilità delle cifre è essa stessa la notizia. **Il "Now What"** fornisce criteri di scelta individuali, una checklist per il CIO (censire i permessi, disattivare Computer Use e Cowork per impostazione predefinita, delimitare quali estensioni MCP sono autorizzate, organizzare distribuzione e aggiornamenti — su Linux, al di fuori del repository apt, Claude Desktop non si aggiorna da solo) e una direttiva editoriale: citare solo verbatim e date confermati.
#ChatGPT Desktop#Claude Desktop#versione web
**Deep Research Veille Interne** — rapport non signé · produit par une enquête sourcée menée les **11-12 août 2026** et rendu le 12.
Annuncio di **Google** del **6 agosto 2026**: Google aderisce come **Core Maintainer** alla specifica **Agent Plugins 1.0.0**, un formato di packaging aperto e *vendor-neutral* per distribuire insieme **Agent Skills** e **MCP servers**. La specifica è stata pubblicata da un **TSC** i cui Core Maintainer provengono da **Amazon, Cursor, Microsoft, OpenAI e Vercel**; Google li raggiunge, rappresentata da **Kevin Hou** (Senior Staff Engineer, Google DeepMind). I due mattoni impacchettati — Agent Skills e MCP — provengono da **Anthropic**, che non compare in questo elenco di maintainer. **La diagnosi** sta in una frase: *"The core problem isn't the components. It's the manifest."* Una skill è portabile, un server MCP è portabile; il contenitore che li racchiude non lo è, e ogni client ha dovuto inventarlo da sé — da cui i fork, le copie di componenti identici e la loro deriva. **Il formato** sta in un vincolo: *"A plugin is a directory. That's the whole idea, and the restraint is the point."* Un `plugin.json` con due righe utili (`$schema` e `name`), le skill in `skills/` nel formato Agent Skills, i server dichiarati in `mcp.json` con un **`type` esplicito su ogni voce** (stdio, Streamable HTTP, o il legacy HTTP+SSE) — niente più trasporto dedotto dalla forma dell'oggetto di configurazione. La forza del design sta in ciò che il manifest **non può** fare: né rilocare i componenti né dichiararli inline, quindi non esiste un percorso di discovery da configurare né un ordine di precedenza da imparare. Corollario operativo: i componenti **falliscono in modo indipendente** — un server `mcp.json` che non riesce ad avviarsi non trascina con sé le skill del plugin, il client salta la voce, prosegue e segnala il fallimento. La via di fuga accettata è la directory **reverse-domain** (`com.example.client/`), uno spazio di estensione posseduto interamente da un client (hook, agenti, comandi) che gli altri client ignorano: *"the portable core stays small because the non-portable parts have somewhere legitimate to go."* Una sezione è dedicata ai casi in cui il formato non è giustificato — *"Not every skill should be a Plugin"*: un singolo server MCP per un singolo client, `mcp.json` basta; una singola skill non necessita di alcun plugin. Ciò che v1 esclude esplicitamente, sotto *future considerations*: **nessun meccanismo di installazione, nessun protocollo di distribuzione, nessun modello di permessi, nessun requisito di sandboxing, nessuna verifica di fiducia o provenienza, nessuna UX**. Tutto questo rientra in uno stack a quattro livelli adottabile in modo indipendente — **trovare** (Agentic Resource Discovery), **descrivere** (AI Catalog, che dovrebbe registrare il tipo `application/agent-plugins+json`), **impacchettare** (Agent Plugins), **eseguire** (MCP + Agent Skills). Due prodotti Google sono già disponibili: **Agents CLI** e **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).
Landing page della **specifica ufficiale** dell'**Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), consultata il **2 agosto 2026**. Non si tratta di un articolo datato ma di un **artefatto vivo**: la scheda è datata in base alla sua osservazione, non a una data di pubblicazione. **Dichiarazione di missione in una frase**: *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **Il problema enunciato** sta in tre righe: gli agenti di codifica e gli editor sono **strettamente accoppiati** e *« interoperability isn't the default »* — ogni editor deve costruire un'integrazione personalizzata per ogni agente, ogni agente deve implementare API specifiche dell'editor. Tre conseguenze nominate: **onere di integrazione** (ogni coppia agente-editor richiede lavoro personalizzato), **compatibilità limitata** (un agente raggiunge solo un sottoinsieme di editor), **dipendenza dal fornitore per lo sviluppatore** (*« choosing an agent often means accepting their available interfaces »*). **La soluzione è esplicitamente modellata su LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — con un beneficio reciproco: un agente che parla ACP funziona con **qualsiasi** editor compatibile, un editor che supporta ACP accede all'**intero** ecosistema di agenti ACP. **Due modalità di distribuzione, ed è il punto più sottovalutato**: gli agenti **locali** girano come sottoprocesso dell'editor via **JSON-RPC su stdio**, ma gli agenti **remoti** sono previsti su **HTTP o WebSocket** — supporto dichiarato *« work in progress »*, con collaborazione in corso con piattaforme agentiche. **Filiazione tecnica con MCP, più forte di una semplice complementarità**: ACP *« re-uses the JSON representations used in MCP where possible »*, aggiungendo tipi specifici alle esigenze UX della codifica agentica (la visualizzazione dei **diff** è l'esempio riportato); il formato predefinito per il testo leggibile è **Markdown**, scelto affinché l'editor non sia tenuto a renderizzare HTML. **Due osservazioni su governance e versioning** tratte dalla pagina stessa, non dal discorso circostante: la navigazione espone **v1 (Latest)** e **v2 (Draft)** — e **non un "ACP 1.2"** —, e la barra di navigazione collega **Zed Industries *e* JetBrains** allo stesso livello, accanto a un **ACP Registry**, alle **RFD**, a una sezione **Community**, a **Publications**, **Updates** e una pagina **Brand**. Librerie ufficiali annunciate: **Kotlin, Java, Python, Rust, TypeScript**, più un percorso community.
#Agent Client Protocol#ACP#protocollo aperto
**Projet Agent Client Protocol** — spécification collective · sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*) · d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.
Nota di veglia tecnologica di **Didier Girard** datata **2 agosto 2026**, nata dalla domanda di un collega ("cos'è ACP?") per affrontare un problema che non è terminologico ma **documentario**. **Tre protocolli si contendono l'acronimo**, senza alcuna sovrapposizione tecnica: **Agent Client Protocol** (client ↔ agente — Zed, agosto 2025, JSON-RPC 2.0 su stdio, Apache-2.0, "ciò che LSP ha fatto per i linguaggi"), **Agentic Commerce Protocol** (agente ↔ commerciante — OpenAI + Stripe, 29 settembre 2025, in concorrenza con l'**UCP** di Google dell'11 gennaio 2026 sostenuto da **AP2**), e **Agent Communication Protocol** (agente ↔ agente — IBM Research / BeeAI, marginale ma che inquina le ricerche). **Il cuore della nota non è lo scioglimento dell'ambiguità ma il suo fallimento osservato**: l'autore cerca "ACP" nella propria base di conoscenza di veglia tecnologica e ottiene **dodici risultati, tutti relativi al protocollo di commercio, zero su quello di Zed** — *"i nostri agenti di veglia avevano indicizzato l'acronimo senza disambiguarlo"*. Da qui una regola di ingegneria della conoscenza: ***"un acronimo nudo non viene mai indicizzato"*** — l'entità è "Agent Client Protocol", "ACP" è **solo un alias**, portato da tre entità distinte. Segue una precisazione strutturante (**MCP collega un agente ai suoi strumenti, ACP collega un client a un agente; i due si sovrappongono**), poi il caso di scuola: **Buzz**, pubblicato da **Block** il 21 luglio 2026 sotto Apache-2.0 — uno spazio di lavoro auto-ospitabile costruito su **Nostr**, dove ogni partecipante umano o agente è una **coppia di chiavi** e ogni messaggio, passo di workflow o git push è un **evento firmato** in un log append-only. Un'architettura interamente basata su protocolli (`buzz-acp` un harness ACP su stdio, `buzz-agent` un agente ACP che chiama un LLM, `buzz-dev-mcp` un server shell + editing MCP), da cui l'agnosticismo verso gli agenti: **Goose, Claude Code e Codex** si collegano tramite lo stesso harness, e **Hermes** (Nous Research) vi si è collegato senza che Block scrivesse una sola riga — *"N+M invece di N×M, in produzione"*. La nota si chiude sulla questione dell'**abbonamento Claude** rispetto agli agenti terzi, con una cronologia in cinque tappe per il 2026 e una **regola di design** che vale oltre questo caso: la linea di demarcazione non è legale ma **architetturale** — ***"chi consuma, e per conto di chi"*** (un agente `owner-only` consuma il tuo abbonamento per tuo conto; un agente `anyone` in un canale condiviso instrada le richieste dei tuoi colleghi attraverso il tuo account). **Verifica effettuata su questo corpus**: la tesi regge, e in modo più netto di quanto affermi la nota — non solo "Agent Client Protocol" è **completamente assente**, ma l'acronimo nudo `ACP` **è già tipizzato come entità** in due schede, e la pagina della KB `Agentic-Commerce-Protocol` **attribuisce già il protocollo a Google** quando invece appartiene a OpenAI + Stripe. La collisione descritta non è un rischio futuro: ha **già prodotto un errore di attribuzione** nel grafo.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
Analisi di Janakiram MSV (The New Stack, 20 luglio 2026) sulla **convergenza architetturale** delle piattaforme agent enterprise dei tre hyperscaler: in nove mesi, **Amazon Bedrock AgentCore**, **Microsoft Foundry** e **Gemini Enterprise Agent Platform** sono convergenti sugli **stessi sei primitivi** — runtime, memoria, tool gateway, identità, osservabilità, governance — sotto nomi commerciali diversi. Ciò che 18 mesi fa era una collezione frammentata di librerie sta diventando un **livello di piattaforma** a sé stante. La tesi: questa convergenza ripercorre l'**inflessione PaaS 2011-2016**, in cui **Cloud Foundry** ed **Heroku** hanno unificato VM, load balancer, code e secret store attorno a un **contratto applicativo** portabile — salvo che qui **non esiste ancora un contratto equivalente**, e **nessun progetto open source lo ha rivendicato**. Conseguenza: un'impresa non può **spostare un agente da un cloud all'altro** (stato di sessione, tracce e identità finiscono tutti presso un unico fornitore; migrare significa ricostruire tutto). L'autore propone una **mappatura riga per riga** del contratto Cloud Foundry sugli agenti, definisce tre principi di design (impacchettare l'agente come **una singola unità distribuibile**, **collegare** le capacità invece di incorporare i fornitori, integrare il livello **operativo** nell'astrazione), indica ciò che i protocolli aperti (MCP, A2A, OpenTelemetry) lasciano fuori campo — il **ciclo di vita** — e formula tre domande di due diligence: **governance** (fondazione neutrale vs. fornitore), **packaging** (lo stesso artefatto su due cloud senza riscriverlo), **stato** (memoria esportabile). Verdetto: chi finirà per possedere il **control plane degli agenti** definirà *cos'è un agente*.
Articolo di blog di **Pasquale Pillitteri** (software engineer, Palermo) pubblicato il **29 maggio 2026** (versione FR), lettura di 18 minuti, sezione *Claude Code & Anthropic*. **Tesi centrale**: *« Claude Opus 4.8 è il modello SEO più potente del 2026, ma quasi tutti lo usano male »* — non un problema di modello ma un problema di **sistema**. La regola d'oro: ***« la strategia è una lavagna, la produzione è una catena di montaggio »*** — la SEO deve essere **suddivisa in due fasi distinte**, e mescolarle è *« il modo più rapido per sprecare un modello che costa cinque dollari per milione di token in input e venticinque in output »*. **Contesto del modello**: Opus 4.8 rilasciato il **28 maggio 2026** (41 giorni dopo Opus 4.7), contesto di **1M di token**, **GraphWalks Long-Context F1 a 1M: 40,3% → 68,1%**, **SWE-bench Verified 88,6%**, **USAMO 2026 96,7%** (+27,4 punti), **HLE con tool 57,9%**, prezzo invariato **5$/25$** per milione di token, **Fast Mode 2,5× a 10$/50$**, quattro **livelli di effort** (Low, High, Extra, Max). **L'anti-pattern centrale** = *« la conversazione gigante »* / **context drift**: mescolare strategia, ricerca di parole chiave, analisi competitiva e scrittura in un'unica chat produce un *« miscuglio di intenzioni contraddittorie »* → il modello scivola verso **best practice generiche** ("ottimizzazione olistica", "approccio strategico") invece di contenuti ancorati ai dati. **Fase 1 — Strategia (lavagna, UI visiva, una tantum)**: dashboard / Google Sheet / canvas Claude.ai per decidere guardando insieme i dati. **3 mosse**: (a) **ricerca di parole chiave classificata** (tabella di volume / difficoltà 0-100 / intento / potenziale business / priorità = volume÷difficoltà×peso business); (b) **analisi competitiva visiva** (matrice di copertura degli argomenti, gap); (c) **roadmap a fasi** (quick win M1-2 / medio termine M3-6 / pagine pilastro M7-12). La modalità **Extra/Max** è giustificata qui (*« una decisione strategica corretta vale mille pagine ben scritte sulle parole chiave sbagliate »*). 3 artefatti chiusi salvati su Notion/Drive. **Fase 2 — Produzione (catena di montaggio, Opus 4.8 + MCP)**: il modello passa da stratega a **macchina di esecuzione**; ogni decisione **ancorata a dati live** tramite il **Model Context Protocol**. **Stack MCP minimo**: **GSC MCP** (AminForou/mcp-gsc, 500+ stelle), **Ahrefs MCP ufficiale** (98 stelle), **GA4 MCP**; il repo `modelcontextprotocol/servers` = **86.440 stelle**, **10.000+ server attivi**, 97M download SDK/mese. Setup ~35 min, refresh mensile ~20 min. **Loop settimanale**: un singolo prompt estrae dati live, costruisce il brief (top 10 SERP + GSC + Ahrefs), deriva H2/H3, scrive, verifica la densità, suggerisce i titoli → **+45% di produttività**, bozza in **6-12 min** (riferimento esplicito a **Ryan Law / Ahrefs content engineering**, 23 skill). Cita i **Dynamic Workflows** di Anthropic (fino a 1.000 subagent). **4 errori comuni**: (1) non verificare i numeri (spot-check obbligatorio, *trust & verify*); (2) sostituire integralmente Semrush/Ahrefs (MCP è un **layer** sopra, non un sostituto); (3) ignorare il **paid-organic content gap** (caso cliente education: **2.742 termini sprecati / 351 opportunità** identificati in 90 s); (4) usare Opus 4.8 dove basta **Haiku 4.5** (meta description, alt text). **Costo**: 1-3$ per articolo di 2.500 parole. **Sonnet 4.6** basta per la produzione ricorrente, Opus 4.8 riservato alla strategia. Articolo SEO-ottimizzato e autoreferenziale (l'autore scrive di SEO in un contenuto esso stesso pensato per posizionarsi su "Opus 4.8 SEO"). Convergenza diretta con **Ryan Law/Ahrefs** (citato), **sistemi attorno al modello** (Dropbox/Okumura), **skill-over-prompt** (Lattice), model routing Haiku/Sonnet/Opus (Gupta token-to-outcome).
#Claude Opus 4.8#SEO IA#workflow a due fasi
**Pasquale Pillitteri** — Ingénieur informatique / développeur logiciel basé à **Palerme** (Italie) · certifié Innovation Manager UNI 11814:2021. Auteur d'un blog tech actif (rubrique *Claude Code & Anthropic*) · avec une newsletter hebdomadaire (~3,4k lecteurs). Article publié en version **FR** le **29 mai 2026** (lendemain de la sortie d'Opus 4.8).
Post del **blog di Ahrefs** pubblicato il **28 aprile 2026** da **Ryan Law** (Director of Content Marketing, Ahrefs) che descrive un sistema interno di **content engineering** costruito attorno a **Claude Code**: una pipeline editoriale che produce **bozze pronte per la pubblicazione in 6-12 minuti**. **Tesi centrale**: ***« AI content is not, by default, good. This process works well because it mirrors our existing human editorial process »*** — la qualità non deriva dal modello ma dalla **riproduzione fedele di un processo editoriale umano** collaudato da decenni. Architettura: **~23 skill files**, ciascuno corrispondente a una fase editoriale (keyword research, analisi dei gap tematici, struttura dell'outline, compilazione della ricerca, generazione della bozza, formattazione), **orchestrati da uno skill master `blog-pipeline`** che li concatena per produrre un articolo completo. **Sette principi di design**: (1) **imitare i flussi di lavoro umani** concatenando skill adattati dalla documentazione editoriale esistente di Ahrefs; (2) **restituire l'output di ogni fase separatamente** per il troubleshooting (*« if you get an article at the end of a ten minute run, and it's bad, it's hard to diagnose precisely where and why the process went wrong »* → salvare gli output intermedi); (3) **creare casi di test** tramite lo skill `skill-creator` di Anthropic per valutare e migliorare le istruzioni; (4) **collegare fonti dati di qualità** — l'**Ahrefs MCP** (metriche delle keyword, parent topic, temi long-tail, panoramiche SERP, analisi competitiva), analisi competitiva e documentazione di prodotto; (5) **anticipare l'indicazione umana** tramite parametri di contesto che abilitano indicazioni editoriali; (6) **costruire anteprime interattive** in formato HTML per la revisione prima della pubblicazione; (7) **consentire la personalizzazione** (ogni membro del team può fare il fork e modificare il sistema). **Volume**: ~**15 articoli pubblicati** e ~**30 articoli aggiornati** tramite questo workflow; lo sviluppo è iniziato a **febbraio 2026** (il processo precedente, di **agosto 2025**, richiedeva diversi giorni e intervento manuale). **Avvertenze esplicite** (anti-sopravvalutazione): *« experience matters »* — il processo riflette decenni di competenza editoriale; la selezione degli argomenti si concentra su **contenuti SEO informativi** ben conosciuti dall'autore; Ahrefs **non ha alcun piano per "scalare" massicciamente i contenuti** ma mantiene una **libreria evergreen**. Filosofia: automatizzare *« the formulaic parts of work »* per eliminare le mansioni ripetitive e liberare tempo per ricerca, thought leadership, webinar e ottimizzazione del sistema — **non** sostituire lo sforzo umano. Riferimento canonico citato da Pasquale Pillitteri (*Opus 4.8 SEO workflow*) come prova sul campo del guadagno « 6-12 min/bozza ». Convergenza diretta con la dottrina **skills-over-prompts** (Lattice, PROJ-AI), i **systems around the model** (Dropbox/Okumura) e l'uso dell'**HTML come artefatto di revisione** (Shihipar).
**Ryan Law** — Director of Content Marketing chez **Ahrefs**. Praticien senior du content marketing SEO ; le billet est un retour d'expérience personnel (*« How I do… »*) publié sur le **blog Ahrefs** (ahrefs.com/blog) le **28 avril 2026**.
Lancio della Agentic AI Foundation - Linux Foundation - OpenAI Anthropic Block - Standard Aperti per gli Agenti AI - AGENTS.md MCP goose - Interoperabilità
Block/Goose — MCP-UI and the Future of Agentic Interfaces: componenti web interattivi nelle conversazioni degli agenti IA tramite Model Context Protocol (block.github.io)
Ripresa da Legal.io dello studio MIT NANDA "The GenAI Divide: State of AI in Business 2025": il 95% dei pilot di IA aziendale non genera un ROI misurabile nonostante 30-40 miliardi di dollari investiti. Concetto di "GenAI Divide", "shadow AI economy", quattro fattori strutturali di fallimento, raccomandazione back-office e build-vs-buy. Giustificazione empirica per lo shift HR-organizzativo.
#MIT NANDA#GenAI Divide#fallimento del 95% dei pilot
Legal.io (relais et synthèse) — étude MIT NANDA "The GenAI Divide: State of AI in Business 2025"