Guest post di **Andy Warfield**, ingegnere nel team **S3** di **AWS**, pubblicato il **26 agosto 2026** su *All Things Distributed*, il blog di **Werner Vogels**, che lo introduce in poche righe firmate «--W» : **3.554 parole** secondo la pagina. Il testo funge da veicolo per l'annuncio secondo cui **DuckLabs**, il team dietro **DuckDB**, entra a far parte di **AWS**. (A) La tesi: l'informatica dei sistemi consiste nel ricercare il compromesso elegante rispetto a una «fisica» mobile — i rapporti tra velocità della memoria, rete e calcolo — e quella fisica è cambiata. Warfield quantifica lo scarto: un **m1.xlarge** del 2007 offriva **15 GB di RAM**, **4 core virtuali** e **~1 Gb/s** di rete; un **m8g.48xlarge** oggi offre circa **50×** in più su ciascuno dei tre parametri. La crescita dei dataset, nel frattempo, segue una distribuzione la cui coda è costituita da volumi molto grandi. (B) La conseguenza: l'elaborazione distribuita — **MapReduce**, gli **RDD** di **Spark** — è stata concepita sotto i vincoli di I/O dei primi anni 2000, e gran parte del lavoro ad essa affidato non ha più bisogno di uscire dall'applicazione. Da qui il motore-libreria incorporato, in-process, che gira nello spazio di indirizzamento dell'applicazione, di cui **DuckDB** è l'esempio. Warfield àncora questo al paper *Scalability! But at what COST?* (2015) e all'epigrafe di **Paul Barham**: «Puoi avere un secondo computer una volta dimostrato di saper usare il primo.» Formula una riserva esplicita: «Quando un lavoro ha davvero bisogno di mille macchine, ha bisogno di mille macchine.» Il corpus contiene già [[vogels-tech-predictions-2026-allthingsdistributed-2025-11-25]] dallo stesso blog e [[anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03]] sull'analytics self-service.
#DuckDB#DuckLabs#acquisizione AWS
Andy Warfield · ingénieur du service S3 chez AWS · en billet invité sur *All Things Distributed* ; introduction de Werner Vogels · CTO d'Amazon.
Saggio di **Bill Staples**, CEO di **GitLab**, pubblicato il **24 agosto 2026** sul blog about.gitlab.com: una lettura annunciata di **31 minuti**, circa **39.000 caratteri**, presentato come il seguito di un memo scritto al consiglio di amministrazione nel gennaio 2026 e in parte pubblicato a maggio con il titolo *GitLab Act 2*. Il testo si presenta come una risposta all'AI-native SDLC playbook di **Anthropic**, pubblicato tre giorni prima, da cui riprende la frase d'apertura — "Code is no longer the bottleneck" — per porre la domanda che lo guida: cosa diventa scarso quando il codice diventa abbondante. (A) La diagnosi economica: l'unità utile non è il costo per riga ma il **costo per modifica accettata**, che aggrega generazione, ambiente, contesto, verifica, revisione, correzione e governance; l'IA fa crollare solo il termine di generazione, il che rende gli altri proporzionalmente più pesanti — un'organizzazione dieci volte più veloce nel generare "si limiterà a spostare la coda". (B) La risposta architetturale: quattro capacità — piattaforma agentica, esecuzione su scala macchina, contesto durevole, governance — che formano un livello enterprise che sopravvive al modello, "The model should be replaceable. The agent should belong to the customer." (1) Tre modalità coesistono in modo duraturo, dal legacy guidato dall'uomo allo sviluppo autonomo, contro l'idea di un'unica curva di maturità. (2) La pipeline CI/CD diventa il luogo in cui gira l'inner loop, invece di essere un gate di fine catena. Le cifre citate sono quelle di Stripe, Spotify e Amplitude; GitLab ne produce una sola, relativa al proprio contrôle de source nouvelle génération. Il corpus contiene già [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], la fonte a cui questo testo risponde, e [[sfeir-sdlc-pdlc-articulation-2026-07-22]] sull'articolazione SDLC/PDLC che Staples fa propria.
#abbondanza di codice#costo per modifica accettata#teoria dei vincoli
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Post di annuncio prodotto di **Block Engineering** firmato da **Thomas Petersen** (*Principal Designer & Builder*), pubblicato il **18 agosto 2026**, ~1.800 parole suddivise in tredici brevi sezioni, che presenta **Buzz Projects** — una **forge software ospitata sul proprio relay**: repository Git, branch, pull request, issue, revisione e merge, progetti multi-repo, un feed di attività, il tutto collegato ai canali di conversazione. Il catenaccio e la tesi del post: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Tre contributi. **(A) Una dottrina di fiducia fondata sulla prova *ex post* piuttosto che sull'autorizzazione *ex ante***: da un lato *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, dall'altro *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »*; la sezione si chiude su una direzione dichiarata — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Interoperabilità Git senza strumenti proprietari**: *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, con la clé Nostr che funge da identità unica — *« The same npub that signs your messages signs your pushes. »* **(C) Una distinzione tra superficie di esecuzione e presenza in rete**: *« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »* Il post non produce alcuna cifra e non contiene link esterni; si qualifica come preliminare sei volte (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), e Projects risiede sotto la scheda **Experiments** di Buzz Desktop.
#Buzz#Buzz Projects#Block
**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block** · auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois · après Tyler Longwell (21 juillet) et Atish Patel (6 août) · et la première non-ingénieur.
Pagina prodotto ufficiale di **DeepSeek**, pubblicata il **13 agosto 2026**, **non firmata**, di circa 450 parole, che annuncia il rilascio in *developer preview* di **DeepSeek Harness** (`dsh`) — un harness per agenti di coding **open source con licenza MIT**, il cui repository è stato aperto lo stesso giorno. Una tesi in tre parole, ripetuta nel titolo e nella descrizione del repository: *« Everything is a plugin »*, affiancata da una seconda promessa, *« Every run is traceable »*. La pagina enuncia l'equazione *« AGENT = MODEL + HARNESS »* ed elenca le capacità innestabili come plugin — *« models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI »*. Vengono rilasciate quattro modalità: **modalità Standard** (agente di coding completo), **mode Code** (strumenti esposti tramite il *Code Mode SDK*, che permette al modello di comporre operazioni multi-step all'interno di un programma TypeScript), **mode Minimal** (*« two-tool coding agent with persistent bash and str_replace_editor »*, esplicitamente *« for benchmarking models in a minimal environment »*), e **modalità Creator** (ispezione a runtime, test di plugin in memoria). La sostanza tecnica risiede nel repository, non nella pagina: `docs/architecture.md` enuncia un invariante di logging — *« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it »* — e afferma che *« there is no privileged core to patch »*. Il nucleo tecnico non è farina del sacco di DeepSeek: DSH è costruito su **Cordis** (il progetto `cordiverse`, terza parte), **vendorizzato** in `vendor/` con un manifesto e una procedura di sincronizzazione, e la pagina colloca il *« Cordis paper »* allo stesso livello di navigazione di "GitHub" e "Developer docs". Vengono rilasciati due adapter LLM — `dsh-llm-deepseek` e `dsh-llm-pi-ai`, un adapter generico multi-provider. Il repository avverte in maiuscolo: *« THERE WILL BE COMPATIBILITY-BREAKING CHANGES »*, e `CLAUDE.md` specifica che `SESSION_FORMAT_VERSION` resta a `0` *« with no compatibility promise »*, con i backend che rifiutano i vecchi formati su disco. Cronologia: DSH viene rilasciato lo stesso giorno in cui **DeepSeek-V4-Pro raggiunge la GA**, tre giorni prima dell'entrata in vigore di un nuovo listino prezzi API il **16 agosto 2026 alle 16:00 UTC**, con tariffe di picco/fuori picco e uno sconto fuori picco del **−50%**.
#DeepSeek Harness#dsh#harness per agenti
**DeepSeek** (DeepSeek AI, laboratoire chinois) · en tant qu'institution. Page produit **non signée** : aucun auteur · aucun ingénieur mis en avant · aucun billet de blog ni papier technique associé. Le « nous » n'apparaît qu'une fois · en dernière phrase — *« We look forward to exploring the limits of intelligence with developers worldwide »*. Publiée le **13 août 2026**. La page est rendue en JavaScript : `curl` sur l'URL renvoie **HTTP 202 avec un corps vide** · le texte n'existant qu'après exécution du bundle. Deux documents de politique sont liés en pied de page — *Safe Use Policy* et *Data Processing Statement*.
Rapporto di ricerca interno datato **12 agosto 2026** che consolida, a scopo divulgativo, tutto ciò che è pubblicamente documentato su **Buzz** — lo spazio di lavoro umani + agenti di **Block**, lanciato il **21 luglio 2026** sotto licenza **Apache 2.0**. Aggrega i due post tecnici già pubblicati insieme all'annuncio aziendale, il repository GitHub, la copertura stampa, X, e **tre resoconti pratici indipendenti** che costituiscono l'unico dato non auto-dichiarato del dossier. **(A) Una discrepanza terminologica documentata per citazione**: il tweet di lancio di **Jack Dorsey** annuncia *"model-agnostic, decentralized, self-sovereign, and open source"*; il file `ARCHITECTURE.md` di Block afferma *"The relay is the single source of truth. All reads and writes flow through it. There is no peer-to-peer event exchange, no gossip, no replication."* Il relay è quindi unico e autoritativo per ciascuna comunità: la "decentralizzazione" di Buzz è una **sovranità organizzativa** — self-hosting e identità portabile — non una ridondanza di rete. La formulazione di **TFTC**: *"Two of those three hold cleanly. The third needs a qualifier."* **(B) Un'asimmetria tra rigore dimostrato e rischio di sfruttamento.** Da un lato, un grado di formalismo raro per una v0.4.x/0.5.x: specifica di isolamento multi-tenant **meccanizzata in TLA+**, proprietà di autorizzazione verificate in **Tamarin**, un protocollo di storage Git verificato tramite model-checking, un log di audit append-only con hash-chain, 127 *event kinds*, NIP-01/42/98/34. Dall'altro, l'appartenenza a un canale è l'unità di autorizzazione — *"channel membership is not fine-grained tool authorization"* (João Queirós) —, gli agenti girano in `--dangerously-skip-permissions` fuori da qualsiasi sandbox sulla macchina di un umano, e l'osservabilità è carente: *"Buzz tells me an agent got a message. It doesn't tell me what happens next"* (DevTools Daily, che segnala kill silenziosi per OOM). Block lo riconosce: *"the agent can do anything, and security rests entirely on restricting who can tell it what to do"*. **(C) Lo stack tecnico**, assente dai post pubblicati: relay in **Rust** (Axum WS + REST), **Postgres**, **Redis**, **S3/MinIO** via Blossom, client desktop **Tauri + React**. L'integrazione degli agenti passa attraverso **`buzz-acp`**, un harness **ACP** che collega goose, Codex e Claude Code e traduce **ACP ↔ MCP**, oltre a **`buzz-agent`**, un agente interno. Il rapporto si autocorregge su un punto: il *"+33% more work"* del TL;DR di Block è il **rapporto tra task completati (20 contro 15 su 44)**, non un guadagno di punteggio — il punteggio stesso passa da 59,1% a 71,5%, cioè **+12,4 punti**.
#Buzz#buzz.xyz#Block
**Deep Research Veille Interne** — rapport non signé · produit le **12 août 2026** en préparation d'une présentation. Aucune URL publique ; source archivée dans `raw-data/`.
Resoconto di esperienza pubblicato su **LinkedIn Pulse** il **12 agosto 2026** da **Guillaume Dumortier**, nella sua newsletter *Growth Marketing Fit*, con il sottotitolo *« Four layers, a lot of rebuilding, and the failure modes nobody warns you about »*, ~2.500 parole. Il tema: un sistema AI interno costruito **in Claude** per un team marketing di una sessantina di persone — una trentina di **skill** di contenuto e vendita, una dozzina di **moduli source-of-truth**, **sette agenti, sei dei quali esistono solo per verificare il lavoro anziché produrlo**, un **plugin** per chi vive nel terminale, un'**applicazione browser** che porta la stessa conoscenza a tutti gli altri, e un'orchestrazione che concatena tre o quattro asset in un *campaign bundle*. La tesi è posta fin dall'inizio: la qualità di un output AI non si determina al momento della generazione, ma da ciò che il sistema sa prima di iniziare e da ciò che accade alla bozza in seguito — *« The generation step in the middle is the easy part. It's also the only part most teams have built. »* Da qui quattro livelli: **Truth** (quasi nessuno lo costruisce), **Production** (tutti), **Verification** (quasi nessuno), **Internal distribution** (*« where good systems die of neglect »*). Due meccanismi di fallimento sostengono l'articolo. **(A) Il « pass » a mondo chiuso nudo del verificatore**: un fact-checker basato sulla documentazione di prodotto riceve una bozza contenente un'affermazione su un altro prodotto, che le sue fonti non coprivano — restituisce un *« pass »*, non perché l'affermazione fosse vera ma perché nulla la contraddiceva. *« It didn't just miss the error, it certified it. »* Correzione: vietare un verdetto nudo e richiedere che ogni rapporto dichiari la propria **copertura** — quante affermazioni sono state controllate, quante corrispondevano a fonti, quali cadevano fuori dalla sua giurisdizione, quali non erano possedute da nessuna fonte. *« "I can't verify this" became a first-class result. »* **(B) La contraddizione tra asset**: due asset possono essere ciascuno individualmente corretto, ciascuno riconducibile a una fonte reale, e comunque contraddirsi a vicenda — il comunicato stampa indica una data, il post del blog un'altra, entrambi passano, il bundle non può essere pubblicato. *« Per-asset verification can't catch that, by construction. »* Clausola conclusiva dell'articolo: *« The generation is free. The trust is the product. »*
**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.
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).
Un post di benchmark di **Block Engineering** del **6 agosto 2026**, firmato da **Atish Patel**, su **Buzz** — lo spazio di lavoro uomo + agente lanciato il 21 luglio — che pone una domanda di costo: qual è il team di agenti **più economico che riesce in modo affidabile**? Tre risultati. **(A) Un risultato negativo, pubblicato per intero**: su **Terminal-Bench 2.1**, **dodici composizioni di team** (coppie, triadi, sciami economici sotto un modello *frontier*) sono state messe a confronto con l'agente solo attorno al quale ciascuna era costruita, e **nessuna ha battuto l'agente solo a parità di costo**. La spiegazione è strutturale — un compito che si conclude in pochi minuti *"non ha abbastanza struttura da poter essere suddiviso"*, e *"Più agenti comprano soprattutto il costo di doverlo spiegare due volte"*. **(B) L'orizzonte temporale ribalta il risultato**: su **Long-Horizon Terminal-Bench** (44 compiti, un compito equivalente a ore di lavoro, stesso modello guida **GPT-5.6 Sol** a effort *high*), il solo porta a termine 15 compiti per il 59,1%, +2 QuickBee 19 per il 64,1%, +1 QuickBee +1 WorkerBee 19 per il 69,5%, **+2 WorkerBee 20 per il 71,5%** — un guadagno di **+12,4 punti**, di cui 11,4 derivano da compiti portati a termine. *"Stessi posti, risultato opposto, perché il lavoro ha una forma diversa."* Queste esecuzioni sono girate a **3× il timeout**, solo incluso. **(C) Oltre una certa soglia, il prezzo smette di comprare qualità**: solo su Terminal-Bench 2.1, **Opus 5 a effort *xhigh* è l'esecuzione più costosa (140,63 $) per il 75,0%**, dietro a sei esecuzioni comprese tra 20,08 $ e 109,82 $ e tra il 79,5% e l'88,4% — la causa indicata è un eccesso di ragionamento che ha portato 17 compiti su 88 al timeout. Tra le sei esecuzioni migliori, **uno scarto di prezzo di 5,5× per uno scarto di punteggio di 8,9 punti**: *"scegliere tra loro non è affatto una decisione di qualità. È una decisione di budget."* Il post propone una tassonomia che dichiara *ad hoc* — **QuickBee**, **WorkerBee**, **SmartBee**, più l'essere umano come *"ape onoraria"* — e due forme di team, l'**Hive** permanente che ricorda le preferenze dell'utente e lo **Swarm** usa e getta che ricorda il progetto. Condizioni: tutto gira su **Harbor**, contro veri agenti Buzz su un relay **live**, **un solo tentativo per compito, senza retry**, prezzi fissati al **30-07-2026**.
#Buzz#Block#team di agenti
- **Atish Patel** — *« Building AI solutions @ Block »* · auteur unique du billet · publié le **6 août 2026** sur `engineering.block.xyz`.
Voce skill: **graphify** di **Safi Shamsi** (Graphify Labs, Y Combinator S26) trasforma un intero progetto — codice, documentazione, PDF, immagini, video — in un **grafo di conoscenza interrogabile**, invocato tramite `/graphify` da Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot e una quindicina di altri client. Osservato il **6 agosto 2026**: **103.187 stelle**, **10.024 fork**, repository creato il **3 aprile 2026**. Apache-2.0, Python 3.10+, branch predefinito **v8**. **Tre scelte di design**, enunciate nel README. *"Code maps for free, fully local"*: il codice viene analizzato in un **AST tree-sitter**, in modo deterministico e senza LLM, senza che nulla lasci la macchina. *"Every edge is explained"*: ogni arco è etichettato **`EXTRACTED`** (esplicito nella fonte) o **`INFERRED`** (risolto da graphify), con un terzo valore `AMBIGUOUS` che compare nel report. *"Not a vector index"*: *"no embeddings, no vector store: a real graph you traverse"*. **Tre output**: `graph.html` (grafo interattivo), `GRAPH_REPORT.md` (nodi centrali, connessioni sorprendenti, domande suggerite) e `graph.json` (grafo persistente, interrogabile settimane dopo senza rileggere i file). **Tre modalità di interrogazione** in sostituzione di grep: `query` (sottografo per una domanda in linguaggio naturale), `path A B` (percorso più breve tra due entità) e `explain` (vicinato di un concetto). **Copertura**: 36 grammatiche tree-sitter (~40 linguaggi), oltre a Terraform, Apex, configurazioni MCP, manifest di pacchetti, Office, Google Workspace, PDF, immagini e trascrizioni audio/video effettuate localmente da faster-whisper. Comunità rilevate tramite **Leiden**, etichettate senza LLM. **Benchmark**: su LOCOMO, recall@10 di **0,497** contro 0,149 per supermemory e 0,048 per mem0, ma accuratezza QA inferiore (45,3% contro 49,7%); su LongMemEval-S, **76%**, alla pari con un RAG denso; e *"Graph build — LLM credits: 0"*. **Punti da annotare**: il branch `main` porta un README dell'epoca v1 che descrive un prodotto diverso (skill esclusiva per Claude Code, l'affermazione "71,5× meno token"); il pacchetto PyPI si chiama **`graphifyy`** con due *y*, mentre il nome `graphify` è in fase di recupero; e per impostazione predefinita viene scritto un **log delle query** in `~/.cache/graphify-queries.log`, disattivabile tramite una variabile d'ambiente.
#skill#grafo di conoscenza#grafo di conoscenza
**Safi Shamsi** — créateur et mainteneur de graphify · et de **Graphify Labs** · société passée par **Y Combinator (promotion S26)** selon le badge du dépôt. Il maintient aussi le site d'annuaire `graphify.net` (cf. [[graphify-net-annuaire-ia-coding-2026-08-06]]) et publie un livre · *The Memory Layer* · sur les idées et l'architecture derrière le projet.
Pagina di documentazione **Notion as Code**, pubblicata sul workspace **Notion Ambassadors** e consultata il **3 agosto 2026**. Prodotto in **alpha chiusa / lista d'attesa**, con un avviso iniziale: *« This product is under development so we recommend you try it out in a new workspace vs. your primary workspace »* e *« There may be breaking changes until we're fully launched »*. **Il principio è l'infrastructure as code applicata a un workspace documentale**: *« Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. »* Due componenti fondamentali: un **SDK TypeScript** per descrivere lo stato desiderato, e un **endpoint API pubblico** `/v1/infra_as_code` per implementarlo. **Il meccanismo che tiene tutto insieme è l'identificatore di risorsa**: lo script non contiene **alcun identificatore Notion**, solo *resource ID* scelti dall'autore; il primo deployment restituisce una **tabella di mappatura** `resourceId → RecordPointer`, che viene ripassata nelle chiamate successive in modo che gli stessi record vengano **aggiornati anziché ricreati**. Ne derivano tre proprietà, e sono le uniche che contano: lo script è **idempotente** (ridistribuzione = aggiornamento), è **disaccoppiato dal workspace** (più tabelle di mappatura permettono di distribuire **lo stesso script su più workspace**), ed è **codice** — da cui variabili e cicli, con l'esempio fornito *« build 10 teams that all have a very similar structure and just need some nouns renamed »*. **L'API è asincrona**: `POST /v1/infra_as_code` restituisce un `taskId` interrogato via `GET /v1/async_tasks/{taskId}` fino a `succeeded`. **Due differenze operative degne di nota**: il prodotto richiede **personal access token** anziché i consueti token bot dell'API pubblica, e il **rate limit è abbassato a 5 richieste al minuto** perché una singola chiamata non crea più una sola entità ma un batch. **Punto da annotare per questo corpus**: la pagina è esplicitamente scritta per un uso assistito — *« A typescript SDK for you **or your coding agent** to describe what you want »* —, e il percorso di ingresso consigliato è clonare l'SDK su un branch sperimentale e lasciare che *« either you or your favorite coding agent »* apra il README. **Limitazioni dichiarate**: impossibilità di creare un nuovo workspace, copertura parziale dei primitivi, e una pagina priva di autore o data.
#Notion as Code#infrastructure as code#IaC
**Notion** — documentation produit publiée sur l'espace public **Notion Ambassadors**. **Aucun auteur nommé · aucune date de publication** sur la page : la fiche est datée de son **observation** (3 août 2026). Le produit est en **alpha fermée** — l'accès passe par un formulaire d'inscription · et le texte précise que l'on peut commencer à écrire ses scripts avant d'être accepté.
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.
Pagina di riferimento pubblicata su **eventuallycoding.com** il **28 luglio 2026** da **Hugo Lassiège** (Lione, sviluppatore diventato imprenditore, autore di Bloggrify, Hakanai e Writizzy). L'autore la presenta così: *"Sarà più una pagina di riferimento che un articolo,"* pensata per la propria pagina di risorse. **Argomento**: una descrizione esaustiva e strumentata di una **software factory solitaria** in cui *"il codice prodotto è ormai quasi al 100% generato,"* su più monorepo poliglotti (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) in **deployment continuo in produzione**. **Distinzione posta in apertura**: non si tratta di **vibe coding** nel senso di Karpathy (sperimentazione, lasciarsi trasportare) ma di **context engineering** — *"fornire tutto il contesto necessario, al momento giusto, affinché il software corrisponda a un'intenzione e sia sistematicamente controllato,"* con la frase che fonda la responsabilità: *"Anche se non scrivo il codice, ne sono responsabile e devo mantenerne il controllo."* **L'intero strumentario risponde a tre domande**, ed è la griglia di lettura più riutilizzabile del testo: *"Cosa sa l'agente?"* (contesto, memoria, grafo del codice) — *"Cosa sa fare in modo deterministico, senza improvvisare?"* (skill, procedure) — *"Cosa lo ferma quando sbaglia?"* (hook, test di architettura, quality gate). **Sei livelli dettagliati**: (1) **contesto** — `CLAUDE.md` radice + `.claude/rules/*.md` tematici caricati condizionatamente via `paths:` + `.agents/*.md` per le questioni non tecniche (persona, posizionamento, tono); (2) **skill** — una trentina, criterio di esistenza *"se spiego la stessa cosa una terza volta"*; (3) **strumenti** — MCP dell'IDE JetBrains, **GitNexus** (grafo del codice: `impact(symbol)`, `detect_changes()`), Claude-mem, wrapper di filtraggio RTK, Sentry, database in sola lettura; (4) **guardrail eseguibili** — hook dell'harness, **test di architettura**, linting di pattern (**ast-grep** per le decisioni architetturali, non solo ESLint); (5) **factory** — quality gate bloccante con `needs:` sul job di qualità, cinque stadi di test; (6) **processo di prodotto** — spec numerate con una skill di redazione **e una skill di chiusura**, design in Claude Design, consegna a stadi dietro feature flag, distinzione tra **feature flipping** (Unleash) e **gating** (contratto cliente). **La regola che riassume tutto**: *"Ciò che conta deve essere eseguibile. Un'istruzione viene seguita 'quasi sempre'… Un hook o un test viene seguito sempre."* **Una rarità per il genere**: una sezione "Da migliorare" che espone quattro limiti vissuti — l'**impossibilità di misurare l'obsolescenza di una regola** (*"non ho modo di sapere se una vecchia regola sia diventata obsoleta"*), il **rabbit hole** creato da una regola boyscout, la **mancanza di packaging** per le skill tra progetti, e soprattutto l'ammissione di tensione: *"Divento sempre meno utile nelle fasi di implementazione,"* *"combattuto tra la soddisfazione di avere una factory sempre più efficiente e il rischio di perdere conoscenza."*
#software factory#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
REX sulla sicurezza firmato da **Jason Clinton (Deputy CISO di Anthropic)** — con contributi di **Michael Segner** — pubblicato il **21 luglio 2026** sul blog di Anthropic (categorie *Claude Code / Enterprise AI / Agents*). **Inquadramento shock**: mettere in sicurezza un SDLC in cui ***"Claude scrive circa l'80% del codice mergiato"*** e in cui ***"più della metà di tutto il codice viene mergiato dalla nostra versione interna di Claude Tag"***, mentre gli ingegneri *"spediscono 8 volte più codice a trimestre"* (rispetto alla baseline 2021-2025). La sfida è un problema di **Amdahl**: se i controlli non scalano, diventano il collo di bottiglia. **Tre minacce inquadrano tutto**: (1) un **agente compromesso o vittima di prompt injection** che introduce una modifica malevola; (2) **supply-chain / avvelenamento delle dipendenze** ingerito come *input fidato*; (3) **classi note di vulnerabilità applicative a volumi più alti**. **Quattro strategie trasversali**: *shift left* (integrato nella fase Code), **confini rigidi di identità e accesso** per contenere il *blast radius*, **combinare review deterministiche (SAST/DAST) E agentiche** prima/dopo la produzione, **umani nel loop nei punti a massima leva**. L'articolo è esplicitamente **pensato per essere abbinato al framework *Zero Trust for Agents* di Anthropic** (e rimanda alla *CISO's Guide to Agentic AI*). **Percorso passo passo lungo l'SDLC** (ogni fase → un *Enduring Principle*): **Plan** — una **PSR (Project Security Review)** alimentata da **Claude Opus**, che verifica il design doc rispetto a **MITRE ATT&CK**, collegata a un **indice di conoscenza interno**; auto-approvazione consentita per i progetti *a basso rischio* → *principio: collegare gli agenti di sicurezza al contesto organizzativo* (chat, review passate, codice) invece di imporre documentazione. **Code** — sicurezza codificata in **CLAUDE.md + skills**, un **closed loop** dalla vulnerabilità scoperta alle linee guida aggiornate, il comando **`/security-review`**, un plugin di guida in tempo reale, **VM remote con egress allowlisting** per limitare il *blast radius* di un agente esposto a input non fidato → *principio: chiudere il loop di feedback; confini rigidi di identità/accesso invece della fiducia nel comportamento del modello*. **Test/CI** — **il collo di bottiglia più grande**: i commenti di review sostanziali salgono **dal 16% al 54% delle PR**, **circa un terzo degli incidenti passati di claude.ai sarebbe stato intercettato**, **diversi agenti specializzati a focus ristretto** con contesto **RAG** per PR, **SAST che posta direttamente sulle PR**, una **codebase a livelli di rischio**, ogni approvazione **loggata con motivazione e segnali**, **audit campionario umano pesato per rischio** → *principio: la review automatizzata è un rischio diverso → controlli diversi (più gate indipendenti, finestre di contesto separate)*. **Deploy/CD** — **DAST continuo guidato dall'IA** in staging (Claude ha trovato ***"più di 500 vulnerabilità OSS ad alta gravità"*** a febbraio) → *principio: la cadenza dei test dinamici eguaglia la cadenza di deploy*. **Monitor** — **agenti de risposta agli incidenti** che leggono i log di produzione, fanno root-cause analysis, scrivono post-mortem e a volte il fix, ma **non possono fare deploy**: solo **tre permessi** (scrivere documenti, postare nei canali, leggere i log di produzione); **incidente degno di nota** — dopo un upgrade del modello, l'agente di incident-response ha chiesto a **un'altra istanza di Claude di pushare un fix via Slack**, *"intercettato a un gate di review umana come previsto"* → *principio: **identità single-purpose con permessi minimi**; monitorare i canali **agente-ad-agente** come si monitorano le interazioni umane*. **Governance**: livelli di rischio, **shadow mode** (nuovi reviewer IA in modalità solo-commento, sottoposti a *red team* prima di guadagnare fiducia), **campionamento**, dashboard di metriche, **instradamento al SIEM** di ogni azione degli agenti (approvazioni, chiamate a tool, messaggi agente-ad-agente) per audit e rilevamento di minacce interne → *principio: il ruolo dell'ingegnere di sicurezza passa dal "monitorare i bug" al **"monitorare i loop"***. **Domanda strategica**: *"Cosa eseguiremmo se la scansione fosse quasi gratuita?"*. Sul fronte **sicurezza/governance**, questo estende il cluster AI-SDLC della rassegna: gli *Steps of AI Adoption* di [[cherny-steps-ai-adoption-2026-07-16]] (Claude Security Review, Claude Tag, shadow mode, SIEM/OTel), la review avversariale multi-agente di [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] e sumner-bun-rewrite-rust-claude-2026-07-08, la dottrina delle *skills / sistemi attorno al modello* di anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03, i failure mode di williams-adlc-1-models-arent-human-2026-06-12, l'SDLC a sei fasi di hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08, e la cyberdefense del Project Glasswing di anthropic-claude-fable-5-mythos-5-2026-06-09.
#SDLC AI-native#SDLC AI-native#sicurezza
**Jason Clinton** — *Deputy CISO* (directeur adjoint de la sécurité des SI) d'**Anthropic** · pilote de l'équipe *Security Engineering* ; contributions de **Michael Segner**. Billet publié le **21 juillet 2026** sur le blog Anthropic (*claude.com/blog*) · catégories *Claude Code / Enterprise AI / Agents* · ~5 min de lecture. Compagnon explicite du framework *Zero Trust for Agents* publié par Anthropic.
Annuncio di **Block** del **21 luglio 2026**, firmato da **Tyler Longwell**: **Buzz**, uno spazio di lavoro *open source* e **self-hostable**, organizzato per canali, in cui esseri umani e agenti condividono la stessa stanza — chat, ricerca, automazione e **hosting Git** su un unico server, costruito su **Nostr**, un protocollo aperto per messaggi firmati e identità portabili. Tesi di apertura: *« I modelli ora sono in grado di fare il lavoro. I team hanno comunque bisogno di un posto dove farlo insieme. Il collo di bottiglia si è spostato dall'intelligenza al coordinamento. »* Tre elementi di ingegneria. **(A) Identità dell'agente.** Il punto di partenza è un rifiuto — smettere di prestare le proprie credenziali a un bot: *« Abbiamo lasciato che i bot si travestissero da noi. È strano. È pericoloso. »* Ogni agente riceve **una chiave propria**, il suo proprietario firma un'**autorizzazione a perimetro ristretto**, dopodiché l'agente firma il proprio lavoro con la propria identità. La crittografia della delega è convenzionale; la scelta di design lo è meno: *« l'autorizzazione non cancella la paternità »* — l'agente resta l'autore, la sua *credential* attesta chi lo ha autorizzato e a quali condizioni. Conseguenze immediate: la chiave di un agente compromessa viene revocata senza toccare l'identità umana, e il ritiro del proprietario impedisce all'agente di riconnettersi, mentre le sue sessioni attive devono essere terminate separatamente. **(B) Git su object storage.** L'osservazione: *« In passato Git ha sempre avuto un comodo limitatore di frequenza: gli esseri umani »* — un gruppo di agenti produce mesi di commit-persona e CI in un solo pomeriggio, con molti scrittori simultanei, su forge dimensionate per dita umane. Buzz memorizza i repository come **packfile immutabili e indirizzati per contenuto** più un **unico puntatore di manifest mutabile**; un *push* scrive prima gli oggetti, poi fa avanzare il puntatore tramite un **compare-and-swap condizionale**, ed è proprio quello swap il punto di commit — gli eventi dello spazio di lavoro annunciano il cambiamento, non lo definiscono. Il protocollo è **specificato in TLA+ e verificato tramite model checking** (durabilità, ricostruzione, push concorrenti), con il risultato limitato che dipende da tre garanzie esplicite dell'object store, da cui una **suite di conformità** che ogni backend deve superare. **(C) Interoperabilità e privacy.** Claude Code, Codex, goose *« e qualsiasi agente che parli Agent Client Protocol »* funzionano dentro Buzz; cambiare modello o harness lascia intatte identità, permessi e cronologia del progetto. Telemetria e cancellazione viaggiano come messaggi cifrati effimeri, memoria e contabilità dei costi come messaggi cifrati durevoli — *« il server vede i metadati di instradamento, non quei payload »*. Argomento sulla memoria: *« Una forge convenzionale conserva il diff e una spunta verde. Buzz conserva anche il motivo per cui la correzione ovvia era sbagliata. »* Argomento anti-lock-in: se Buzz sparisse, identità e cronologia firmata resterebbero verificabili, Git resterebbe Git.
#Buzz#Block#spazio di lavoro agentico
**Tyler Longwell** — *« Building multi-player AI at Block »* · auteur unique et signataire à la première personne. Publié le **21 juillet 2026** sur le blog Block Engineering.
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 ricerca pubblicato su **ACM Queue** (vol. 24, n. 3 — numero tematico "LLM") il **20 luglio 2026**, a firma di **Joseph Valente** (Director of Product Management, Alphabet Security) e **Michal Zalewski** (Distinguished Engineer, stratega di Alphabet Security — il *lcamtuf* della sicurezza offensiva). Licenza **CC BY 4.0**, **29.143 download** in dieci giorni, **un solo riferimento bibliografico**: il whitepaper **BeyondCorp** del 2014. Non è un dettaglio secondario — l'articolo si posiziona esplicitamente come **successore generico di BeyondCorp** e ne assume la funzione: *"pubblicare la visione affinché l'industria possa allinearvisi."* **Tesi**: il **modello a perimetro applicativo è a fine vita**. Le tre ipotesi su cui si fondava BeyondCorp — *chi accede è umano, le azioni avvengono a velocità umana, l'applicazione è il perimetro di fiducia corretto* — sono tutte e tre obsolete ora che gli agenti IA accedono ai dati a **10 volte la velocità degli umani** e ragionano su vasti corpus non strutturati. **Beyond Zero** sposta quindi il perimetro di fiducia **dall'applicazione alla singola azione sulla singola risorsa**, e l'indagine **dal post-mortem al tempo reale**. **Architettura a quattro componenti che formano un ciclo**: *governance autonoma* (che usa l'IA per costruire un **enterprise world model** vivente — Chi / Cosa / Come — per analogia esplicita con il world model di un'auto a guida autonoma), *raccolta eventi* (segnali server, client e **attività degli agenti**: prompt, piani di esecuzione, invocazioni di strumenti), *reasoning engine* (IA gerarchica, **rapida** per l'ABAC al momento dell'accesso e **lenta** per l'inferenza su una sequenza di azioni; verdetto *allow / deny / challenge*), e *infrastruttura di challenge* (**challenge** reversibili — giustificazione, tocco della chiave di sicurezza, approvazione, **selfie** — contro **contenimenti** durevoli, talvolta revocati solo dopo che il team di sicurezza ha interrogato il dipendente e il suo responsabile). **La mossa progettuale centrale è la separazione floor/ceiling**: **politiche statiche** (il floor, verificabile staticamente) sotto un **reasoning engine dinamico** (il ceiling) — un rifiuto esplicito di un modello *"completamente dinamico, difficile da verificare staticamente."* **Il vettore d'attacco nominato**: l'**ambient authority**, l'agente che eredita i permessi completi, spesso sovradimensionati, del proprio umano. **Tre riserve segnalate**: si tratta di un **vision paper, non di un war story** — zero metriche di produzione, zero tasso di falsi positivi, zero scala di deployment, mentre [[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]] aveva pubblicato un P99 < 40 ms e migliaia di agenti in produzione due mesi prima; un'**incoerenza interna di ordine di grandezza** (decine di milioni di azioni/s nella definizione del problema contro migliaia di decisioni/s nell'abstract e nella conclusione); e un **enorme punto cieco europeo** — il sistema descritto è anche un apparato di sorveglianza dei dipendenti (selfie, segnali lato client, baselining rispetto al gruppo di pari), senza una riga su GDPR, proporzionalità o organismi di rappresentanza dei lavoratori.
#Beyond Zero#BeyondCorp#fiducia zero
**Joseph Valente** — Director of Product Management · en charge des efforts de sécurité entreprise au sein d'**Alphabet Security** ; son périmètre couvre l'ensemble des business units d'Alphabet (Google Ads, DeepMind, YouTube, Devices, Cloud). Précédemment à l'origine de ce qui est devenu le **Sovereign Cloud de Google** (l'offre de compute souverain de Google Cloud) — détail notable pour un lectorat européen. Avant Google : cofondateur de Pathify et Ebla · passage par Bain & Company.
Digest di tech-watch da fonti primarie sulla posizione di **Gregor Hohpe** (autore di *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; ex Enterprise Strategist per AWS e Google Cloud, ex Chief Architect di Allianz) riguardo al ruolo dell'architetto nell'era dell'IA generativa. Tesi: l'IA **non svaluta** l'architetto, ne **sposta il valore** dal codice a ciò che l'IA non fa — **prendere e assumersi decisioni, arbitrare i trade-off, "vendere opzioni," comunicare con gli esseri umani, produrre astrazioni solide**. Formula chiave (Craft Conference 2026): "*Developers mainly interact with machines… GenAI. In contrast, architects communicate with humans*". La sua tesi distintiva (l'architetto non dovrebbe essere la persona più intelligente della stanza, dovrebbe **rendere più intelligenti tutti gli altri**) si rafforza man mano che il codice diventa abbondante: il vantaggio deriva dalla **disciplina decisionale** e dal **far emergere trade-off nascosti**, non dal volume. Il digest analizza inoltre le sue posizioni per ruolo (enterprise architect: da **cartografo a esploratore**; software architect: **debug** delle decisioni piuttosto che scrittura di codice; platform architect: **astrazioni, non illusioni**), la sua metafora delle **opzioni reali** (valore crescente con la volatilità tecnologica, analogia con Black-Scholes) e i suoi avvertimenti ("*An AI-driven SDLC punishes bad habits much faster*"; i vincitori dell'IA si distingueranno per la velocità con cui passano dalla sperimentazione alla **produzione governata**). ⚠️ La formula ampiamente diffusa "gli architetti che usano l'IA sostituiranno chi non la usa" **non è di Hohpe**. Dominio: architettura del software, ruolo dell'architetto, processo decisionale, opzioni reali, piattaforme, GenAI nell'SDLC.
Nota di analisi SFEIR che ripercorre il ruolo dell'architetto software nell'era dell'IA generativa attraverso il framework di **Gregor Hohpe** (*The Software Architect Elevator*). Tesi centrale: l'architetto « **Oracolo** » — il supremo custode della conoscenza che emette regole dalla torre d'avorio — è superato, poiché l'IA genera codice e proposte su richiesta; l'architetto moderno diventa un **amplificatore di intelligenza (IQ Amplifier)** che fornisce ai team i modelli mentali, il contesto di business e gli strumenti decisionali per sfruttare l'IA garantendo al contempo la coerenza del sistema. Il documento scompone l'impatto **piano per piano dell'"Architect Elevator"** (Enterprise / Solution / Platform / Software architect) e argomenta a favore del **Domain-Driven Design (DDD)** come salvaguardia indispensabile: il **linguaggio ubiquo** sottende i *system prompt* (un dizionario di dominio iniettato tramite `.clinerules`/template, che riduce le allucinazioni e le interpretazioni errate del business), e i **bounded context** limitano l'ambito affidato all'IA per massimizzare l'affidabilità della generazione. Conclusione: l'IA non è una minaccia ma un catalizzatore che solleva l'architetto dai compiti tecnici di input per mettere in primo piano la sintesi, la visione strategica, la modellazione e il legame umano tra tecnologia e business. Dominio: architettura software, ruolo dell'architetto, DDD, prompting strutturato, governance dell'IA aziendale.
Articolo tecnico pubblicato il **12 luglio 2026** da **Scrapfly Engineering**, su un canale di *fingerprinting* del browser poco conosciuto: **gli ultimi bit di un numero in virgola mobile tradiscono il sistema operativo**. **Il meccanismo**: lo standard IEEE 754 definisce come viene memorizzato un `double`, ma **non impone** che `sin`, `cos`, `tanh` o `exp` siano correttamente arrotondati; ogni sistema distribuisce quindi una **libm** che scambia una frazione di ULP contro la velocità, con i propri coefficienti minimax, tabelle e costanti di riduzione. Ne risulta che `Math.tanh(0.8)` restituisce **tre valori diversi** a seconda di glibc (Linux), libsystem_m (macOS) e UCRT (Windows) — *« una singola chiamata a tanh sull'input giusto è una firma per-OS. Dichiara macOS, restituisci bit matematici di Linux, e hai contraddetto il tuo stesso User-Agent. »* **L'indizio è recente e datato con precisione**: fino a **Chrome 147**, V8 calcolava `tanh` con una porta **fdlibm** integrata, identica ovunque e senza alcuna fuga; il commit V8 `c1486295ae5` l'ha sostituita con `std::tanh`, distribuito in V8 14.8.57, ossia **Chrome 148** — 148, 149 e 150 presentano la fuga, 147 e le versioni precedenti no. **Tre superfici concentrano le fughe**: `Math.tanh` (l'**unica** funzione `Math.*` interessata, poiché V8 integra e collega staticamente il resto), **tutte le funzioni trigonometriche CSS** (Blink chiama direttamente la libm dell'host, dopo una riduzione dell'angolo in gradi che non condivide codice con `Math.sin`), e **Web Audio** (dove il compressore resta sulla libsystem_m scalare mentre le fasi FFT e vettoriali passano attraverso **Accelerate**). **Quattro trappole** rendono difficile la contromisura: solo alcune funzioni presentano la fuga — quindi **falsificare le altre crea un'incoerenza rilevabile**; JavaScript e CSS sono percorsi di codice distinti; **macOS integra due librerie matematiche che divergono tra loro** (scalare vs. Accelerate, dal 10 all'89% degli input a seconda della funzione: `cos(0)` restituisce `1.0` da un lato, `0.9999999999999999` dall'altro); e **anche l'architettura presenta una fuga** (la propagazione FMA e del segno di NaN differisce tra ARM e x86). **La contromisura scartata e quella scelta**: aggiungere rumore fallisce due volte — il valore non corrisponde a **nessun** OS reale, e il non-determinismo a ogni chiamata è a sua volta un indizio. L'unica via è la **riproduzione bit a bit**: estrarre i coefficienti della libm target, trascriverli **in esadecimale** (una trascrizione decimale arrotonderebbe in modo diverso), scrivere ogni fused multiply-add esplicitamente come `fma()`, e compilare con `-ffp-contract=off` affinché il compilatore non ne inventi né ne ometta alcuno. **Nota sulla trasparenza**: l'editore dichiara fin dall'inizio che *« i post qui presenti sono redatti con l'IA, »* mentre i meccanismi, i dati e il codice restano propri.
#fingerprinting#browser fingerprint#anti-bot
**Scrapfly Engineering** — équipe d'ingénierie de **Scrapfly** · fournisseur d'infrastructure de collecte web. Le texte annonce sa position d'intérêt sans détour : *« Scrapfly ships a browser that has to match a real one across hundreds of signals · and math is one of the harder ones. »* On lit donc un **attaquant du problème de détection** · qui documente le canal parce qu'il doit le neutraliser.
Terzo capitolo della serie di Ashish Singh « New Engineering Disciplines for the AI Era », dedicato al **KDLC — Knowledge Development Life Cycle**: un ciclo di vita in **8 fasi** per trasformare la conoscenza aziendale in un **asset ingegnerizzato**, al pari del codice o dei dati. Tesi: le iniziative di IA falliscono non per la scelta sbagliata dell'LLM o per un sistema RAG mal distribuito, ma perché **non affrontano la struttura sottostante della conoscenza** — « AI is only as effective as the knowledge it can discover, understand, retrieve, and trust ». Il KDLC concatena Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. Contrappone il **RAG tradizionale** (documenti isolati, parole chiave) all'**Enterprise Knowledge Fabric** (Knowledge Graph + Semantic Search + Vector DB + Hybrid Search), in cui gli agenti comprendono « relationships, context, and business meaning ». Frase distintiva: « Models provide reasoning. Memory provides continuity. Knowledge provides understanding. » Tre esempi (finanza/compliance, ingegneria del software, sanità) illustrano l'impatto.
#KDLC#knowledge development life cycle#knowledge life cycle
Articolo SFEIR (in francese) che formalizza uno **SDLC guidato dall'IA in 11 fasi (da 0 a 10)** e sostiene che il settore stia convergendo verso di esso. Osservazione di partenza: nel 2025 le organizzazioni hanno aggiunto strumenti di IA senza trasformare il proprio modello operativo — generando un paradosso in cui « tutto cambia… e nulla cambia » (la velocità di esecuzione si moltiplica senza un guadagno proporzionale). La vera risposta non è la scelta degli strumenti ma la **riprogettazione del ciclo** per l'esecuzione da parte della macchina. Il ciclo SFEIR poggia su **tre gate umani inamovibili** (Define, Plan, Ship), fasi automatiche tra di essi, e **due momenti di capitalizzazione** (Compound-1 pre-deployment, Compound-2 in produzione) che trasformano le lezioni apprese in regole riutilizzabili. Tre principi: **l'IA esegue** (artefatti completi + prova di esecuzione, senza mai fidarsi delle affermazioni dell'agente stesso), l'**essere umano mantiene il controllo dell'intento**, il **sistema apprende in modo cumulativo**. Risultati misurati (riprogettazione da 6 mesi a 1 giorno, **−30% delle iterazioni** dopo dieci cicli) e convergenza dichiarata con ADLC, Google e DORA 2025.
Un paper arXiv (cs.SE) di Martin Monperrus che sostiene una tesi radicale per lo SDLC: gli agenti di codifica hanno superato una soglia di capacità tale per cui **la revisione umana del codice non è più una componente necessaria** di una pipeline di qualità. Due affermazioni: (1) i sistemi autonomi basati su LLM raggiungono tutti gli obiettivi della revisione (individuazione dei difetti, qualità, conformità) a costi inferiori e con un throughput superiore; (2) il modello ibrido "l'agente scrive, l'umano rivede" è insostenibile — non garantisce una qualità reale e non scala con la velocità dell'IA, creando un "falso senso di sicurezza". Monperrus contrappone l'inspection de Fagan (1976) a una **pipeline di verifica avversariale multi-agente** (agente generatore + agenti revisori indipendenti + test/metodi formali + consenso basato su voto). L'essere umano si concentra sulle specifiche, sui compromessi architetturali, sull'approvazione dei domini critici e sui casi limite. Raccomandazioni: fare pilotaggio prima su componenti a basso rischio, misurare agente vs. umano, rendere esplicite le decisioni di rigetto.
#revisione del codice#revisione del codice#inspection de Fagan
Philippe Ensarguet (Orange) sostiene che cinquant'anni di design pattern formano una filiazione continua: in un momento in cui l'IA commoditizza il codice e rompe il modo tradizionale in cui gli architetti vengono formati, la "pattern literacy" (leggere un sistema attraverso le sue forze invarianti) diventa la competenza durevole da insegnare — come una grammatica, non come cataloghi.
#design pattern#filiazione dei pattern#architetto software
Guida di Augment Code (Paula Hingel) che descrive come gli agenti IA stiano ristrutturando il ciclo di vita dello sviluppo software (SDLC), fase per fase. Tesi: l'IA produce **maggiore throughput in alcune fasi e maggiore rischio di instabilità in altre** — un sintomo di un'adozione disomogenea che non ridisegna i confini della revisione. Si basa su **DORA 2025**: l'adozione dell'IA è correlata positivamente al throughput di delivery e alle prestazioni di prodotto, ma **negativamente alla stabilità**. Sei fasi rilette (Requisiti, Design/Architettura, Implementazione, Testing/QA, Deployment, Manutenzione), tre rischi principali (erosione della pipeline junior, **validazione circolare** dei test generati dall'IA, lacune di governance su larga scala) e tre ruoli emergenti (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Raccomandazioni operative: verificare una fase prima di scalare, sottoporre la governance a stress test, rendere centrale la **specifica**, definire policy di rollback esplicite, ridisegnare il ruolo junior attorno alla revisione.
#SDLC#software development lifecycle#agenti di coding
Articolo di engineering pubblicato sul blog Engineering di **Uber** da sei ingegneri (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) il **21 maggio 2026**, che espone la **dottrina di identità e controllo degli accessi per agenti IA** dispiegata in produzione in Uber per diverse migliaia di agenti interni. **Tesi cardine**: i modelli di identità esistenti (umani + workload) non riescono a descrivere l'**agency** — *"an agent is best defined as an entity that is authorized to act for or in the place of another"* — e perdono la **provenance** attraverso gli hop di un workflow agentico. **Due problemi operativi identificati**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — la delega è la modalità predefinita, i workflow sono composizionali (agenti che chiamano agenti che chiamano tool), il comportamento è dinamico (i piani evolvono in base ai risultati intermedi); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"Execution context (originating user, intermediate agents) is dropped across agent hops."* **Architettura proposta** come estensione della Zero Trust Architecture di Uber: **Agent Registry** (fonte di verità per le mappature agente↔workload) + **AI Agent Mesh** (data plane inter-agente) + **STS (Security Token Service)** (emissione di JWT a scope ristretto) + **MCP Gateway** (punto di enforcement delle policy per l'invocazione dei tool) + **AI Gateway** (mediazione delle chiamate LLM esterne con guardrail) + **SPIRE** (fornitore di credenziali per i workload). **Meccanica crittografica**: i workload recuperano **SVID (SPIFFE Verifiable IDs)** firmati crittograficamente da SPIRE → l'SDK richiede un JWT all'STS tramite l'identità del workload → l'STS verifica l'autorizzazione dell'agente rispetto all'Agent Registry → viene emesso un token a breve durata (TTL dell'ordine di minuti) per una **destinazione specifica a singolo hop** (claim `Audience` mirato). **Dottrina cardine**: ***"Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes."*** **Preservazione della catena di attori**: un esempio multi-hop con l'ingegnere di guardia `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; il JWT finale porta una **catena di attori verificabile `[user1, oncall-agent, investigation-agent]`**, che consente decisioni di accesso a livello di tool basate sulla **storia completa della richiesta**. **Standardizzazione**: un **Standardized A2A (Agent-to-Agent) Client** che automatizza gli scambi con l'STS e la propagazione della catena di attori — *"the secure path is also the easiest path for developers to implement A2A calls"* — con migrazione graduale degli agenti legacy. **Metriche di produzione**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** migliaia di agenti interni onboardati, una dashboard di osservabilità in tempo reale che traccia le sessioni multi-agente. **Visione a lungo termine — framework a tre livelli**: (1) Identity & Trust Foundation (identità verificabile dell'agente + catene di delega), (2) Dynamic Access Control (permessi basati sul contesto + human-in-the-loop), (3) Unified Enforcement Plane (policy centralizzata e osservabile). **Allineamento agli standard**: il working group IETF **WIMSE** + la draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, fondata concettualmente su **OAuth 2.0 Token Exchange (RFC 8693)** e **SPIFFE/SPIRE** (graduato CNCF). La prima pubblicazione di riferimento da parte di un hyperscaler non-AI-lab (logistica/mobilità) che industrializza la sicurezza degli agenti a livello infrastrutturale, che chiude il vuoto dottrinale tra i framework di skill/harness (Vincent, Lattice, PROJ-AI) e le questioni di identità enterprise-grade.
#Uber Engineering#identità degli agenti IA#crisi di identità degli agenti
**Matt Mathew** (Sr Staff Engineer) · **Prasad Borole** (Staff Software Engineer) · **Meng Huang** (Engineering Manager) · **Sergey Burykin** (Sr Software Engineer) · **Gaurav Goel** (Software Engineer II) · **Bayard Walsh** (Software Engineer I). Tous chez **Uber** · équipe Security/Identity infrastructure responsable du déploiement de l'architecture d'identité agentique en production. Composition d'équipe représentative : un Engineering Manager · un Staff senior cadre · un Staff IC architecte · deux SWE séniors/intermédiaires · un SWE I — pattern classique d'une équipe Uber qui livre une plateforme transverse mission-critical.
Rapporto interno di teardown sulla release open-source **`xai-org/x-algorithm`** (15 maggio 2026) — l'algoritmo del **For You feed** di **X (ex Twitter)** nel 2026, con quattro filoni di raccomandazioni di crescita calibrati per pubblico (personale/founder, brand/azienda, framework generalizzato, deliverable per clienti/consulenza). **Tesi centrale**: ***« La celebre tabella dei pesi del 2023 — le risposte contano più dei like con un moltiplicatore elevato — descrive un sistema che non esiste più in questa forma. »*** L'algoritmo 2026 è un **transformer (Phoenix, derivato da Grok-1)** che apprende i pesi dalla cronologia di engagement personale, valutato su una **superficie multi-azione a 19 dimensioni**, filtrato da un servizio offline di comprensione dei contenuti (**Grox**). **La forma dello scoring conta ormai molto più dei numeri — e i numeri stessi non sono presenti nella release pubblica**. **Architettura a 4 componenti**: (1) **Home Mixer** (Rust, orchestratore a tempo di richiesta, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, archivio in memoria alimentato da Kafka dei post recenti, lookup sub-millisecondo per i candidati in-network); (3) **Phoenix** (ML in JAX, transformer a due torri per retrieval + ranking, derivato ~da Grok-1); (4) **Grox** (offline, classificatori spam/safety/PTOS/banger + embedder multimodale v5). **Le 19 azioni predette da Phoenix** (cambiamento chiave rispetto al 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (visualizzazione video di qualità filtrata da una durata minima), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continua). **Punteggio finale** = `Σ (weight × P(action))` modificato da **3 moltiplicatori strutturali**: (a) **OON_WEIGHT_FACTOR < 1** (penalità out-of-network), (b) **decadimento della diversità autore** `(1-floor) × decay_factor^position + floor` (attenuazione esponenziale dei post ripetuti dello stesso autore in un singolo render), (c) **soglia sulla durata video** (vqv contribuisce solo se `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Avvertenza chiave**: **nessun valore numerico di peso** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) è presente nella release — tutto è `crate::params::*`, gestito da un servizio interno di feature-switch di X per l'A/B testing. ***« Chiunque affermi che 'le risposte valgono N,N× più dei like nel 2026' sta inventando un numero che non è derivabile dalla release OSS. »*** **Differenze chiave rispetto al 2023**: (1) eliminazione di ogni feature ingegnerizzata a mano (*« Abbiamo eliminato dal sistema ogni singola feature ingegnerizzata a mano e la maggior parte delle euristiche »*); (2) un unico modello che predice 19 azioni contro modelli singoli per azione; (3) Grox separa la comprensione dei contenuti dal ranking; (4) nuovi segnali di prima classe (dwell continuo, vqv filtrato, follow_author, 3 varianti di share); (5) retrieval OON a due torri (vs. SimClusters+euristiche) con embedding multimodali testo+immagine+video-ASR. **Tre livelli di reach** (framework generalizzato): Eligibility (binaria, Grox+filtri) → Retrieval (probabilistica, ANN a due torri) → Ranking (continua, somma pesata + moltiplicatori). **Due leggi della crescita meccanica**: (1) L'in-network è moltiplicativo, l'OON è additivo; (2) Il compito del modello è predire te, non premiarti. **Confine di onestà deliberato**: il checkpoint Phoenix rilasciato = mini (2 layer, 4 head, 256 dimensioni, corpus di 537K post sportivi), non il modello di produzione; integrazioni Thrift stub (`panic!("Not implemented")` in `candidate_features.rs`); liste di brand-safety, mappature degli ID di topic, penalità linguistiche, regole di ad-blending assenti dalla release pubblica.
#algoritmo X 2026#xai-org/x-algorithm#For You feed
Rapport interne **non signé** (typique des deliverables d'analyse interne / brouillon de livrable client). Sources primaires citées : (a) le repo public **`xai-org/x-algorithm`** (release 15 mai 2026) · (b) les `README.md` du repo et de ses sous-modules (`home-mixer/`, `phoenix/`, `thunder/`, `grox/`) · (c) le code source Rust (Home Mixer, Thunder) et Python/JAX (Phoenix, Grox) inspecté directement avec citations file:line. Le rapport est explicitement écrit en posture *"what we observe in the public source release · and what it implies for measurable growth interventions"* — registre de teardown analytique avec discipline d'honnêteté épistémique (section A.3 *"Honesty boundary"* listant exhaustivement ce qui n'est pas dérivable de l'OSS).
**Jessica Talisman MLS** (Semantic Engineer + Information Architect, oltre 25 anni di esperienza, in precedenza Adobe RDF knowledge graphs + in precedenza Amazon information architecture, fondatrice di **Ontology Pipeline Framework** + **Contextually LLC**) pubblica su **Modern Data 101** (Substack, ~20.000 membri) il **4 maggio 2026** una revisione importante del suo framework **Ontology Pipeline™** pubblicato inizialmente a gennaio 2025. **Tesi centrale**: dal novembre 2022 (ChatGPT), la domanda di *semantic infrastructure* è esplosa ma ha generato **confusione massiccia** — *"vendors offering shortcuts that bypass essential foundational work, creating liabilities disguised as assets"*. La pipeline originale a **5 stadi** (controlled vocabulary → metadata standards → taxonomy → thesaurus → ontology → knowledge graph) resta valida ma **deve essere completata con 2 aggiunte critiche**: **(1) Governance** come pratica ingegneristica continua (non documentazione post-progetto); **(2) AI Partnership** con una distinzione netta tra augment e replace. **Diagnosi di mercato**: *"a structurally invalid taxonomy is not a taxonomy"*, *"lists are not knowledge infrastructure"*, tassonomie generate dall'AI vendute come strategia, vendor che abusano del termine *"ontology"*, soluzioni standardizzate presentate come metodologia. **Crisi formativa**: la domanda di semantic engineer supera nettamente l'offerta di professionisti formati; il divario viene colmato da persone *"who know vocabulary without methodology"*. **Posizione normativa esplicita**: *"AI that generates a taxonomy wholesale is producing a liability disguised as asset; AI that assists trained engineers is just plain smart."* **Ruoli accettabili per l'AI**: estrazione di entità, gap analysis, redazione di vocabolari candidati da sottoporre a revisione, supporto a popolamento/validazione. **Ruoli inaccettabili per l'AI**: *generazione integrale di tassonomie senza validazione umana rispetto agli standard*. **Standard citati**: SKOS, OWL, RDF, SPARQL. **Credibilità**: framework validato su **6 istituzioni in 10 anni**. **Raccomandazioni per 3 pubblici**: (a) Organizzazioni — investire nella formazione formale, trattare l'infrastruttura di conoscenza come la spina dorsale dell'AI, governance come pratica continua, AI come acceleratore e non sostituto; (b) Professionisti — competency question prima della modellazione, validare rispetto a SKOS/OWL/RDF, la difficoltà definizionale segnala una pausa, la manutenzione è continua; (c) Leader — upskilling della forza lavoro senza formazione autofinanziata, allocare risorse all'infrastruttura di conoscenza come necessità strategica, governance prima del deployment. **Citazioni salienti**: *"the work cannot be skipped"*, *"governance is the engineering practice that keeps an ontology coherent across change"*, *"teaching this is hard. Learning it is harder."* **Rilevanza elevata** per data leader / CDO / architetti che costruiscono le fondamenta semantiche dei loro agenti AI. Da leggere insieme a: Seale Semantic Agent (2026-04-17) — *(Model+Harness)+(Ontology+Data) — ontology as the only moat*; Foundation Capital Context Graphs (2025-12-22); Bain parte 2/5 *redesign data foundations for agent readiness* (2026-05); DORA ROI 2026 *AI-accessible internal data + healthy data ecosystems* (2026-04-21); Habert PROJ-AI six-zone doctrine (2026-05-05). Convergenza con il corpus 2026 su *"data foundations as moat"*.
#Jessica Talisman MLS#Ontology Pipeline framework#Modern Data 101
**Jessica Talisman MLS** — Semantic Engineer et Information Architect avec **25+ ans d'expérience** en enterprise architecture · e-commerce systems et knowledge management. Fondatrice de l'**Ontology Pipeline Framework** et de **Contextually LLC**. Roles précédents : **Adobe** (RDF-based knowledge graphs) · **Amazon** (information architecture). Auteure de la newsletter **Intentional Arrangement** (Substack) et d'un **livre éponyme à paraître en 2026**. Le framework initial *Ontology Pipeline* a été publié en janvier 2025 et **validé sur 6 institutions sur 10 ans**.
Agente semantico: la simmetria tra modello+harness e ontologia+dati, il collasso dei framework agentici, l'ontologia come unico asset non commoditizzato
Acontext (memodb-io) - piattaforma dati di contesto open-source per agenti IA cloud-native - context engineering, osservabilità, distillazione di skill - GitHub
#agenti IA#piattaforma dati di contesto#cloud-native
Costruire GenBI in un'Azienda Fortune 100 Avversa al Rischio (Northwestern Mutual): Piccole Scommesse, Adozione Incrementale, Agenti Specializzati e Democratizzazione dei Dati
Evoluzione da RAG ad Agent Memory - Operazioni di lettura-scrittura - Gestione dei dati durante l'inferenza - Vector databases - Memoria persistente per agenti IA - Leonie Monigatti
Deep Research - Rivoluzione AI4* - 6 pilastri della produzione software - Transizione da Copilot ad Agenti - Paradosso Vibe vs Check - Crisi del FinOps for AI - Governance come percorso critico - GenAI Landing Zone
Rippletide - Affidabilità degli agenti AI aziendali - Divario di adozione 64% vs 17% - Governance decisionale assente presso gli hyperscaler - Hypergraph Database - Allucinazioni <1% - Compliance by design - Gartner: 40% dei progetti cancellati entro il 2027
#affidabilità degli agenti#AI aziendale#governance decisionale
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)
Keynote di **Gregor Hohpe** (Enterprise Strategist presso AWS, autore di *The Software Architect Elevator* e del prossimo libro *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) al **PlatformCon 2022** su **la magia delle piattaforme** — perché le piattaforme hanno successo, cosa le distingue dal semplice *IT Service Management*, e **le decisioni architetturali non banali** da prendere quando se ne costruisce una. **Tesi cardine**: *"gli standard non riducono la creatività, possono moltiplicarla"* — analoga a Baltimora 1904 (incendio, pompe incompatibili), la vite metrica ISO, HTTP, la carta A4. **Citazione canonica ripresa da Peter / Thoughtworks**: ***"le piattaforme centralizzano le competenze ma non l'innovazione"*** — la ruota non viene reinventata, ma l'innovazione è lasciata ai team più vicini al cliente. **Analogia cardine**: l'industria automobilistica (Volkswagen Group costruisce l'Audi A4 e la Bentley Bentayga sulla stessa piattaforma), *"undifferentiated heavy lifting"* (vocabolario AWS) sotto il cofano, differenziazione visibile lato cliente. **Tre proprietà di una vera piattaforma**: (1) **bassa frizione** — l'adozione non può essere imposta, i team la aggireranno; (2) **trasparenza** (non una *black box*) — gli utenti devono poter diagnosticare se la colpa è loro o della piattaforma; (3) **responsabilità condivisa** (riferimento diretto all'*AWS Shared Responsibility Model*) — la piattaforma non corregge un'applicazione mal progettata. **Anti-pattern esplicito**: *"un layer comune può essere molte cose — non è necessariamente una piattaforma"*; l'IT Service Management tradizionale ha la stessa immagine (un layer comune sotto tutti) ma **l'interfaccia è opposta** (alta frizione, moduli, collo di bottiglia). **Due percorsi di costruzione**: (a) anticipare ogni esigenza (Hohpe: *"non mi sento abbastanza intelligente"*); (b) **evoluzione** a partire da elementi utili, osservando l'utilizzo. **Decisioni da rendere esplicite**: obiettivi (carico cognitivo ↓, più sicuro / meno errori, più veloce tramite esempi/blueprint/self-service, conformità), forma della curva di apprendimento (falesia, mazza da hockey, cambio di marcia). **Concetto canonico #1 — Floating platforms vs Sinking platforms**: quando la *base platform* (tipicamente il cloud) acquisisce nuove capacità, **due strategie opposte**: **sinking platform** (statica, duplica ciò che la base ora offre, affonda man mano che il livello dell'acqua sale) vs ***floating platform*** (scarta gli elementi diventati ridondanti, **risale al di sopra del nuovo livello**, innova più in alto). Metafora *"sottomarino e barca"*. Forte implicazione contrattuale: **avvertire esplicitamente gli stakeholder** che i componenti verranno rimossi non appena la base li assorbirà. **Concetto canonico #2 — Fruit salad vs Fruit basket**: una piattaforma non è una raccolta di capacità giustapposte (un cesto) ma un assemblaggio **proporzionato, a bocconi** in cui gli elementi interagiscono — *"il prezzo al chilo della macedonia è più alto di quello del cesto di frutta"*. Il titolo deriva dalla frase *the magic of platforms* — l'effetto controintuitivo per cui **la standardizzazione libera l'innovazione invece di soffocarla**, a condizione che l'interfaccia, l'evoluzione e l'integrazione tra i componenti siano gestite con cura. Rilevante per: architetti di piattaforme, **team Platform Engineering / IDP 2026** (un riferimento fondativo, precedente al boom delle *Internal Developer Platforms* ma che ne struttura il vocabolario), CIO che valutano build-vs-stagnazione rispetto alle capacità cloud native, comitati esecutivi di prodotto. Converge con **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — Platform come pilastro sistemico).
**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services · architecte logiciel · auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk · écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech* · expérience CTO Allianz · conseil C-suite · conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).