Vai al contenuto

root / tags / linux-foundation

#Linux Foundation

7 fiches

Strumenti e Piattaforme Traduzione verificata automaticamente

Designing AI with character: what we learned building Berd

Post del blog aziendale di **Block** (`block.xyz/inside`), non firmato — l'autore indicato è **"Block"** —, pubblicato il **18 agosto 2026**, ~930 parole, che annuncia **l'apertura open source di Berd**, l'applicazione desktop interna di Block per lavorare con gli agenti, ed espone la tesi progettuale che l'ha guidata: dare carattere agli agenti *"non solo attraverso ruoli, istruzioni, skill e strumenti, ma attraverso identità visive distintive"* — da cui i personaggi animati proprietari, i *"Gloopies"*. Il post parte da un'osservazione di frammentazione (*"The technology was powerful, but the experience around it was fragmented"*) e da un problema d'interfaccia denominato con precisione: *"the product gives people little sense of how the agent is configured, which context and tools are available to it, and how it differs from another agent"*. Due contributi strutturanti. **(A) Un'articolazione a tre livelli**: **goose** resta il framework e il *runtime* che sostiene l'agent loop; **Berd** è il client desktop (progetti, contesto, sessioni, agenti, configurazione); i due comunicano tramite l'**Agent Client Protocol**. **Buzz** è designato come il seguito, per quando il lavoro solitario diventa collaborativo (*"Start alone, then go multiplayer"*). **(B) Sei requisiti trasmessi a Buzz**, formulati come conclusione: *"private space, durable context, recognizable agent identities, reusable skills, visible configuration, and clearer visibility into an agent's configured context, tools, and capabilities"* — una griglia direttamente riutilizzabile per valutare un client di agenti. Il testo stesso distingue identità e capacità: *"The avatars make the agent recognizable. Its role, skills, and tools make it useful."* Non viene prodotta alcuna cifra d'uso e non è indicata alcuna licenza per l'apertura open source.

#Berd#Block#open source

**Aucun auteur nommé** : le billet est signé **« Block »** — le champ *Author* de la page porte le nom de l'entreprise. Publié le **18 août 2026** sur `block.xyz/inside` · le blog **corporate** · et non sur `engineering.block.xyz`.

Architettura e Costruzione Traduzione verificata automaticamente

Buzz (buzz.xyz) — Rapport de recherche pour présentation

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/`.

Architettura e Costruzione Traduzione verificata automaticamente

Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

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*.

#Piattaforme agent enterprise#convergenza architetturale#portabilità

Janakiram MSV

Economia e Mercato Traduzione verificata automaticamente

Tokenomics foundation : l'ère du FinOps appliqué à l'IA est officiellement ouverte

Analisi di **Olivier Rafal** per **WeNvision** (società di consulenza francese), pubblicata il **4 giugno 2026** (~4 min di lettura), che commenta il lancio della **Tokenomics Foundation** da parte della **Linux Foundation** (annuncio del 3 giugno, in partenariato con la **FinOps Foundation**), evento che l'autore interpreta come l'apertura ufficiale de **l'era del "FinOps for AI".** **Tesi centrale**: l'IA ha trasformato l'economia dello sviluppo software; il **token** è diventato *"la nuova unità di misura della spesa tecnologica"*, in parallelo con il cloud degli anni 2010 (costi **ricorrenti e variabili** da gestire attivamente), da cui il passaggio dei fornitori dal prezzo forfettario alla **fatturazione a token**. **Scala (urgenza)**: *"Secondo Goldman Sachs, l'uso globale di token dovrebbe moltiplicarsi per 24 entro il 2030, raggiungendo 120 quadrilioni di token al mese"* — un ordine di grandezza che fa passare l'efficienza dei token da *"dettaglio tecnico"* a tema di **consiglio di amministrazione**. Citazione di **J.R. Storment** (fondatore della FinOps Foundation): *"I costi e l'efficienza dei token sono diventati una preoccupazione di livello CEO, non una nota tecnica a piè di pagina."* **Problema di trasparenza/standardizzazione**: l'attuale pricing dell'IA non è comparabile (token in ingresso / sistemi di caching / output differiscono da un modello all'altro) → la Tokenomics Foundation punta a **estendere la specifica FOCUS** open source per fornire un **linguaggio comune** per l'acquisto e il confronto. **Messaggio centrale di Rafal (al di là del costo)**: *"Lo scopo del FinOps non è tanto tagliare i costi quanto ottimizzare l'efficienza"* — la metrica reale è il **costo dell'IA relativo all'impatto sul business** (*time to market, qualità, funzionalità, eco-design*). **Limiti dei soli standard**: le norme tecniche non bastano, occorre **ripensare il Target Operating Model** (team, processi, cultura del dato, allineamento con il business); gli americani annunciano già *"la fine dei double-pizza team a favore dei sandwich team"*. **Segnale di allerta**: *"un SDLC potenziato dall'IA non farà che […] amplificare i problemi e aiutarvi ad andare più veloci… contro il muro"* (in assenza di fondamenta organizzative). **Sponsor della fondazione citati**: Accenture, Booking.com, Google Cloud, Microsoft, IBM, Salesforce. **Offerta di WeNvision**: *"co-costruire una roadmap, ripensare il modello operativo per l'era agentica e stabilire la governance finanziaria diventata indispensabile."* **Lettura in lingua francese, rivolta a dirigenti/responsabili della trasformazione**, della scheda [[tokenomics-foundation-linux-finops-token-economics-about-2026-06-03]]; converge con il cluster FinOps agentico [[finops-foundation-finops-for-ai-overview-2026-02-17]], finout-finops-ai-agents-four-step-allocation-framework-2026-04-27, gupta-token-budget-wars-marginal-token-utility-2026-05-28 (token→risultato, valore > volume).

#Tokenomics Foundation#FinOps for AI#FinOps for AI

**Olivier Rafal** · pour **WeNvision** (cabinet de conseil français — bureaux à Paris, Lille, Strasbourg, Bordeaux, Nantes, Toulouse, Belgique, Luxembourg). Olivier Rafal écrit en analyste/conseil familier des préoccupations de comité de direction (ancien analyste IT, profil conseil-transformation). Publié le **4 juin 2026**.

Economia e Mercato Traduzione verificata automaticamente

About — Tokenomics Foundation (a Linux Foundation project)

**Pagina About** del sito **tokeneconomics.com**, che presenta la **Tokenomics Foundation** — un progetto **Linux Foundation** annunciato il **3 giugno 2026**, gestito in **stretta collaborazione con la FinOps Foundation**. **Missione dichiarata**: *"establish open industry standards, benchmarks, and best practices for the economics of AI infrastructure"* — che collega **produzione, consumo e monetizzazione** dei token al **valore di business**. **Definizione quadro della tokenomics**: *"Tokenomics is not just about the cost of tokens, it's about the entire layer of AI that they drive from production, to consumption to monetization"* — ossia **l'intero strato economico dell'IA**, dal costo dell'infrastruttura alla selezione del modello fino all'ottimizzazione del valore. **Tesi delle fasi**: l'adozione iniziale dell'IA privilegiava la **capacità**; la fase attuale si sposta verso **efficienza e valore**, il che richiede una gestione sistematica dei costi e **visibilità**. **5 principi fondatori**: (1) ***"Efficiency is a design choice. AI cost is shaped by architecture, not just usage"***; (2) ***"Bigger is not always better. The best AI system is not always the one using the most expensive model"*** (right-tool / routing); (3) ***"Visibility comes before optimisation. Teams cannot manage what they cannot see"***; (4) ***"Value matters more than volume. More tokens, more calls, and more automation do not automatically mean better outcomes"***; (5) ***"Open knowledge benefits everyone"*** (standard condivisi, apprendimento collettivo, trasparenza). **Governance**: un **Governing Board** (direzione industriale + allocazione dei fondi) e un **Technical Committee** (specifiche aperte + benchmark). **Deliverable**: estensione della **FOCUS specification** (FinOps), specifiche aperte, benchmark, framework e metriche condivisi. **Pubblico target**: CAIO, CTO, CIO, CFO, ingegneri, team di prodotto, professionisti FinOps, ricercatori, startup, imprese, settore pubblico. **Obiettivo dichiarato**: portare le organizzazioni *"from experimental AI adoption to sustainable AI operations"* estendendo la disciplina della **spesa tecnologica variabile** all'era dei token. **Rilevanza per questa rassegna**: istituzionalizzazione/standardizzazione del **FinOps agentico** a livello di fondazione di settore — converge direttamente con le schede [[finops-foundation-finops-for-ai-overview-2026-02-17]], [[finout-finops-ai-agents-four-step-allocation-framework-2026-04-27]], orq-ai-finops-ai-agents-cost-per-outcome-hosseini-2026-04-15, gupta-token-budget-wars-marginal-token-utility-2026-05-28 (livello di allocazione, token verso outcome) e con lo spostamento **token → outcome** (Salesforce/Tallapragada, Sierra/Greenwald). I 5 principi corrispondono esattamente alle leve già rilevate: architettura > uso, **routing Haiku/Sonnet/Opus**, osservabilità prima dell'ottimizzazione, valore ≠ volume.

#Tokenomics Foundation#tokenomics#economia dei token

**Tokenomics Foundation** (entité collective, projet de **The Linux Foundation**, en partenariat avec la **FinOps Foundation**). Page institutionnelle *About* — **aucun auteur individuel nommé**. Annonce datée du **3 juin 2026**.