Berd è un client desktop nativo per lavorare con agenti AI attraverso diversi progetti, strumenti, competenze e modelli. Il suo elemento distintivo non è un nuovo modello linguistico né un nuovo motore per agenti: è lo spazio di lavoro persistente che li circonda.
In pratica, l’app serve a organizzare il lavoro, conservare il contesto di un progetto e cambiare l’agente sottostante senza dover ricostruire ogni volta l’intero flusso operativo.
È importante non confondere Berd con Goose. Goose è il framework open source e il runtime per agenti sviluppato da Block; Berd è invece il livello grafico desktop che offre un’interfaccia coerente per usare Goose e gli altri agenti compatibili. Block spiega che Berd è nato dall’esperienza dei propri team con Goose e con più modelli e ambienti di esecuzione.
Berd usa l’Agent Client Protocol, o ACP, come livello di interoperabilità tra l’applicazione desktop e i diversi agent harness, cioè gli ambienti che eseguono e coordinano gli agenti. L’obiettivo è evitare di costruire un’integrazione proprietaria per ogni singolo strumento: un harness compatibile con ACP può comunicare con un client compatibile attraverso un protocollo comune.
Questo permette di inserire nello stesso flusso strumenti come Goose, Claude Code, Codex e altri agenti che supportano ACP. Berd, però, non è un sostituto universale delle configurazioni dei singoli provider.
Goose può essere usato come runtime integrato o strettamente collegato all’app, mentre Claude Code e Codex continuano a dipendere dalle rispettive installazioni, dagli account, dagli abbonamenti o dalle credenziali. Inoltre, l’agente selezionato determina quale provider riceverà prompt, codice, file e risultati degli strumenti.
Secondo le informazioni disponibili, Berd combina un’interfaccia realizzata con React 19 e il framework Tauri 2. Il risultato è un’applicazione desktop, non un workspace accessibile soltanto dal browser, con versioni disponibili per macOS, Windows e Linux.
Questa scelta la rende adatta agli sviluppatori che vogliono tenere file di progetto e sessioni degli agenti accanto al normale ambiente di sviluppo locale. In cambio, restano a carico dell’utente le responsabilità tipiche di un’app desktop: aggiornamenti, permessi locali, configurazione degli agenti e protezione delle credenziali.
L’approccio local-first indica che l’applicazione e la cronologia di progetti e conversazioni vengono conservate localmente, invece di essere archiviate in un workspace Block ospitato online.
È una distinzione importante per la privacy, ma non equivale a dire che ogni elaborazione AI avvenga sul computer. Se l’agente usa un modello cloud, un’API remota o uno strumento esterno, prompt, codice sorgente, file e risultati delle operazioni possono comunque uscire dal dispositivo.
La privacy dipende quindi non solo da Berd, ma anche dall’harness scelto, dal provider del modello, dagli strumenti collegati e dalla configurazione adottata.
Le informazioni disponibili non permettono di stabilire una policy definitiva sulla telemetria di Berd né di identificare con certezza quale portachiavi o sistema di gestione delle credenziali del sistema operativo venga utilizzato. Chi valuta l’app per attività sensibili dovrebbe verificare questi aspetti nella documentazione aggiornata del repository, in particolare nelle sezioni dedicate a sicurezza e privacy.
Berd è gratuita e open source con licenza Apache 2.0. Questo, però, non significa che ogni interazione con un agente sia gratuita. In genere l’utente deve fornire l’abbonamento o la chiave API richiesti dal modello e dall’harness selezionati; i provider possono inoltre applicare costi in base all’utilizzo.
Il modello economico è quindi diviso in più livelli:
Berd sembra progettata innanzitutto come strumento desktop individuale e local-first, non come piattaforma enterprise completa per l’amministrazione centralizzata.
L’espressione “distribution seams”, o “punti di frizione nella distribuzione”, descrive il lavoro operativo necessario per trasformare un’app desktop utile per singoli sviluppatori in un prodotto gestito da un’azienda. Tra questi aspetti rientrano installazione e aggiornamenti centralizzati, gestione delle identità e degli accessi, distribuzione delle credenziali, policy di rete e proxy, registri di audit, assistenza e regole organizzative sulle azioni degli agenti.
Le evidenze disponibili non mostrano che Berd offra già un livello completo per tutte queste esigenze. Le aziende dovrebbero quindi trattarle come domande da verificare in fase di deployment, non come funzionalità automaticamente garantite dalla licenza Apache 2.0.
La chiusura automatica di una pull request proveniente dall’esterno è una scelta relativa al processo di contribuzione. Può significare che i manutentori preferiscono discutere prima le modifiche nelle issue o che il repository pubblico rifletta una fonte di codice interna.
Questa pratica non annulla la licenza Apache 2.0: chiunque può continuare a esaminare, usare, modificare e forkare il codice nel rispetto dei termini della licenza. Tuttavia, le informazioni disponibili non chiariscono il motivo preciso della policy adottata da Block. Sarebbe quindi speculativo attribuirla a ragioni di sicurezza, licenza o ostilità verso i contributi esterni.
I due progetti di Block si collocano su livelli diversi.
Berd è il workspace desktop individuale. Una persona lo usa per dirigere uno o più agenti tra progetti locali, file, competenze e sessioni.
Buzz è il workspace collaborativo. Block lo ha lanciato il 21 luglio 2026 come ambiente condiviso in cui persone e agenti AI possono comunicare. Il progetto punta a mantenere identità, permessi e cronologia del progetto anche quando cambiano il modello o l’harness. Buzz supporta Claude Code, Codex, Goose e altri agenti compatibili con ACP.
Buzz può inoltre essere configurato con un relay gestito autonomamente, eseguito in locale o su infrastruttura sotto il controllo dell’operatore. La collaborazione, quindi, non richiede necessariamente infrastruttura ospitata da Block, anche se questa scelta trasferisce all’operatore una maggiore responsabilità per configurazione e sicurezza.
I due progetti condividono un approccio neutrale rispetto a modelli e harness, ma le informazioni disponibili non confermano una futura fusione Berd–Buzz né una roadmap condivisa.
La presentazione pubblica di Block descrive Berd come un workspace flessibile per progetti, strumenti, competenze, modelli e runtime diversi, non come una semplice interfaccia dedicata a Goose. L’interoperabilità è quindi la direzione più chiaramente sostenuta dalle informazioni disponibili.
Non ci sono invece elementi sufficienti per affermare che Block abbia già annunciato una roadmap precisa su amministrazione enterprise, telemetria, cambiamenti di prezzo o integrazione formale tra Berd e Buzz. Per queste questioni sarà necessario attendere documentazione aggiuntiva nel repository o un futuro annuncio ufficiale.
Berd è un client desktop nativo per lavorare con agenti AI attraverso diversi progetti, strumenti, competenze e modelli. Il suo elemento distintivo non è un nuovo modello linguistico né un nuovo motore per agenti: è lo spazio di lavoro persistente che li circonda.
In pratica, l’app serve a organizzare il lavoro, conservare il contesto di un progetto e cambiare l’agente sottostante senza dover ricostruire ogni volta l’intero flusso operativo.
È importante non confondere Berd con Goose. Goose è il framework open source e il runtime per agenti sviluppato da Block; Berd è invece il livello grafico desktop che offre un’interfaccia coerente per usare Goose e gli altri agenti compatibili. Block spiega che Berd è nato dall’esperienza dei propri team con Goose e con più modelli e ambienti di esecuzione.
Berd usa l’Agent Client Protocol, o ACP, come livello di interoperabilità tra l’applicazione desktop e i diversi agent harness, cioè gli ambienti che eseguono e coordinano gli agenti. L’obiettivo è evitare di costruire un’integrazione proprietaria per ogni singolo strumento: un harness compatibile con ACP può comunicare con un client compatibile attraverso un protocollo comune.
Questo permette di inserire nello stesso flusso strumenti come Goose, Claude Code, Codex e altri agenti che supportano ACP. Berd, però, non è un sostituto universale delle configurazioni dei singoli provider.
Goose può essere usato come runtime integrato o strettamente collegato all’app, mentre Claude Code e Codex continuano a dipendere dalle rispettive installazioni, dagli account, dagli abbonamenti o dalle credenziali. Inoltre, l’agente selezionato determina quale provider riceverà prompt, codice, file e risultati degli strumenti.
Secondo le informazioni disponibili, Berd combina un’interfaccia realizzata con React 19 e il framework Tauri 2. Il risultato è un’applicazione desktop, non un workspace accessibile soltanto dal browser, con versioni disponibili per macOS, Windows e Linux.
Questa scelta la rende adatta agli sviluppatori che vogliono tenere file di progetto e sessioni degli agenti accanto al normale ambiente di sviluppo locale. In cambio, restano a carico dell’utente le responsabilità tipiche di un’app desktop: aggiornamenti, permessi locali, configurazione degli agenti e protezione delle credenziali.
L’approccio local-first indica che l’applicazione e la cronologia di progetti e conversazioni vengono conservate localmente, invece di essere archiviate in un workspace Block ospitato online.
È una distinzione importante per la privacy, ma non equivale a dire che ogni elaborazione AI avvenga sul computer. Se l’agente usa un modello cloud, un’API remota o uno strumento esterno, prompt, codice sorgente, file e risultati delle operazioni possono comunque uscire dal dispositivo.
La privacy dipende quindi non solo da Berd, ma anche dall’harness scelto, dal provider del modello, dagli strumenti collegati e dalla configurazione adottata.
Le informazioni disponibili non permettono di stabilire una policy definitiva sulla telemetria di Berd né di identificare con certezza quale portachiavi o sistema di gestione delle credenziali del sistema operativo venga utilizzato. Chi valuta l’app per attività sensibili dovrebbe verificare questi aspetti nella documentazione aggiornata del repository, in particolare nelle sezioni dedicate a sicurezza e privacy.
Berd è gratuita e open source con licenza Apache 2.0. Questo, però, non significa che ogni interazione con un agente sia gratuita. In genere l’utente deve fornire l’abbonamento o la chiave API richiesti dal modello e dall’harness selezionati; i provider possono inoltre applicare costi in base all’utilizzo.
Il modello economico è quindi diviso in più livelli:
Berd sembra progettata innanzitutto come strumento desktop individuale e local-first, non come piattaforma enterprise completa per l’amministrazione centralizzata.
L’espressione “distribution seams”, o “punti di frizione nella distribuzione”, descrive il lavoro operativo necessario per trasformare un’app desktop utile per singoli sviluppatori in un prodotto gestito da un’azienda. Tra questi aspetti rientrano installazione e aggiornamenti centralizzati, gestione delle identità e degli accessi, distribuzione delle credenziali, policy di rete e proxy, registri di audit, assistenza e regole organizzative sulle azioni degli agenti.
Le evidenze disponibili non mostrano che Berd offra già un livello completo per tutte queste esigenze. Le aziende dovrebbero quindi trattarle come domande da verificare in fase di deployment, non come funzionalità automaticamente garantite dalla licenza Apache 2.0.
La chiusura automatica di una pull request proveniente dall’esterno è una scelta relativa al processo di contribuzione. Può significare che i manutentori preferiscono discutere prima le modifiche nelle issue o che il repository pubblico rifletta una fonte di codice interna.
Questa pratica non annulla la licenza Apache 2.0: chiunque può continuare a esaminare, usare, modificare e forkare il codice nel rispetto dei termini della licenza. Tuttavia, le informazioni disponibili non chiariscono il motivo preciso della policy adottata da Block. Sarebbe quindi speculativo attribuirla a ragioni di sicurezza, licenza o ostilità verso i contributi esterni.
I due progetti di Block si collocano su livelli diversi.
Berd è il workspace desktop individuale. Una persona lo usa per dirigere uno o più agenti tra progetti locali, file, competenze e sessioni.
Buzz è il workspace collaborativo. Block lo ha lanciato il 21 luglio 2026 come ambiente condiviso in cui persone e agenti AI possono comunicare. Il progetto punta a mantenere identità, permessi e cronologia del progetto anche quando cambiano il modello o l’harness. Buzz supporta Claude Code, Codex, Goose e altri agenti compatibili con ACP.
Buzz può inoltre essere configurato con un relay gestito autonomamente, eseguito in locale o su infrastruttura sotto il controllo dell’operatore. La collaborazione, quindi, non richiede necessariamente infrastruttura ospitata da Block, anche se questa scelta trasferisce all’operatore una maggiore responsabilità per configurazione e sicurezza.
I due progetti condividono un approccio neutrale rispetto a modelli e harness, ma le informazioni disponibili non confermano una futura fusione Berd–Buzz né una roadmap condivisa.
La presentazione pubblica di Block descrive Berd come un workspace flessibile per progetti, strumenti, competenze, modelli e runtime diversi, non come una semplice interfaccia dedicata a Goose. L’interoperabilità è quindi la direzione più chiaramente sostenuta dalle informazioni disponibili.
Non ci sono invece elementi sufficienti per affermare che Block abbia già annunciato una roadmap precisa su amministrazione enterprise, telemetria, cambiamenti di prezzo o integrazione formale tra Berd e Buzz. Per queste questioni sarà necessario attendere documentazione aggiuntiva nel repository o un futuro annuncio ufficiale.