Block, la società tecnologica statunitense fondata nel 2009 come Square da Jack Dorsey, cofondatore ed ex CEO di Twitter e oggi Chairman e “Block Head” di Block, e da Jim McKelvey, imprenditore statunitense cofondatore anche di LaunchCode, ha reso open source Berd, un’applicazione desktop sviluppata inizialmente per uso interno per riunire in un unico ambiente il lavoro con agenti AI, modelli, strumenti e progetti diversi. Square, Inc. ha assunto il nome Block, Inc. nel dicembre 2021, quando le attività del gruppo avevano ormai superato il perimetro originario dei pagamenti per commercianti. L’attuale ecosistema di Block comprende Square, con soluzioni commerciali e finanziarie per le imprese; Cash App, per pagamenti e servizi finanziari rivolti ai consumatori; Afterpay, attiva nel buy now, pay later; la piattaforma musicale TIDAL; Bitkey, wallet bitcoin self-custody; e Proto, dedicata all’hardware e ai servizi per il mining di bitcoin. A queste attività Block ha affiancato negli ultimi anni diversi progetti open source legati allo sviluppo di sistemi agentici.
Berd nasce da un problema incontrato direttamente dai team dell’azienda. L’uso contemporaneo di strumenti come goose, il framework agentico open source sviluppato da Block per consentire ai modelli AI di usare strumenti, lavorare sul codice ed eseguire attività operative, Claude Code e Codex comportava interfacce, configurazioni e modalità differenti di gestione del contesto.
Questi strumenti funzionano come agent harness, cioè runtime che avvolgono il modello linguistico e gestiscono il ciclo operativo dell’agente – sessioni, strumenti, autorizzazioni, esecuzione delle azioni e mantenimento dello stato. Passare da un harness all’altro significava quindi ricostruire parte del contesto di lavoro, soprattutto nei progetti prolungati che coinvolgono conversazioni, file, istruzioni, skill e strumenti esterni.
Berd introduce sopra questi componenti uno spazio di lavoro persistente nel quale organizzare conversazioni, file, cartelle, istruzioni, agenti, skill, provider, estensioni e automazioni. Modello e runtime possono cambiare mentre progetto, cronologia e configurazione rimangono associati allo stesso ambiente operativo.
Il codice sorgente di Berd è pubblicato con licenza Apache 2.0. Le prime release pubbliche si stanno succedendo a distanza di pochi giorni, segnale di un progetto ancora in rapido consolidamento.
Un workspace che conserva lo stato del lavoro
Berd è pensato per ingegneri, product designer e altri professionisti che lavorano stabilmente con agenti AI e devono mantenere continuità fra attività diverse. Una conversazione può essere associata a un progetto, ricevere file e cartelle come contesto, utilizzare un determinato agente e modello, accedere a skill ed estensioni e recuperare successivamente lo stato della sessione.
Il contesto viene reso esplicito nell’interfaccia. Berd mostra quale progetto è attivo, quali risorse sono associate alla conversazione, quale agente sta operando, quale modello e provider vengono utilizzati e in quale stato si trova l’esecuzione.
La persistenza diventa particolarmente importante quando una sessione agentica supera il modello della semplice chat. Un agente può utilizzare strumenti, modificare file, eseguire comandi, delegare attività a subagent e accumulare una cronologia articolata di decisioni e operazioni. In questi casi ricostruire manualmente lo stato a ogni cambio di strumento riduce sensibilmente la continuità del lavoro.
Le conversazioni inattive possono essere archiviate automaticamente e successivamente ripristinate, mentre vengono preservate quelle attive, fissate o contenenti bozze. Nelle chat lunghe Berd protegge inoltre la cronologia esistente quando un caricamento o una compattazione del contesto restituiscono dati incompleti.
Anche i messaggi inviati mentre l’agente è ancora impegnato vengono gestiti attraverso una coda: le istruzioni restano in attesa e vengono inoltrate quando la sessione è nuovamente disponibile, preservandone l’ordine.
Un desktop leggero costruito sopra tecnologie web
La distribuzione pubblica di Berd è un’applicazione standalone costruita con Tauri 2 e React 19. Tauri è un framework open source per sviluppare applicazioni desktop e mobile multipiattaforma utilizzando un frontend basato su tecnologie web e una componente nativa in Rust.
L’architettura di Tauri differisce da quella di framework desktop come Electron perché utilizza il motore WebView già disponibile nel sistema operativo invece di incorporare un browser Chromium completo nell’applicazione. Questa scelta permette in genere di contenere le dimensioni del pacchetto e il consumo di risorse, lasciando al frontend web la gestione dell’interfaccia e alla componente nativa l’accesso alle funzionalità del sistema operativo.
In Berd, React gestisce l’interfaccia del workspace, mentre Tauri fornisce il contenitore desktop e il collegamento con le componenti native.
Il runtime agentico resta separato dall’interfaccia
Berd affida a goose l’esecuzione del ciclo agentico. Il runtime viene distribuito come sidecar, cioè come processo separato incluso insieme all’applicazione. Il desktop avvia o individua il servizio goose serve e comunica con esso attraverso Agent Client Protocol (ACP). La versione del backend viene fissata attraverso un lockfile, in modo che una specifica build di Berd utilizzi una versione conosciuta del runtime.
La separazione assegna responsabilità precise ai diversi componenti: Berd gestisce workspace, progetti, configurazione e rappresentazione delle sessioni; goose esegue il ciclo operativo dell’agente.
goose fa inoltre parte dell’ecosistema della Agentic AI Foundation della Linux Foundation, insieme ad altre tecnologie sviluppate per standardizzare componenti fondamentali dello stack agentico.
ACP separa il client dal motore dell’agente
L’Agent Client Protocol definisce il canale di comunicazione fra un’applicazione client e un agente. Il protocollo utilizza JSON-RPC e comprende operazioni per inizializzare il collegamento, creare e riprendere sessioni, inviare prompt, ricevere aggiornamenti, gestire richieste di autorizzazione e accedere alle capacità esposte dall’ambiente.
In Berd, ACP costituisce il confine fra l’interfaccia desktop e il runtime agentico. Il workspace può seguire l’avanzamento dell’esecuzione e visualizzare attività, tool call e cambiamenti di stato senza incorporare direttamente nell’interfaccia la logica con cui l’agente pianifica ed esegue il lavoro.
Questa funzione è distinta da quella del Model Context Protocol, MCP, utilizzato per collegare modelli e agenti a strumenti, servizi e sorgenti di dati esterne. ACP standardizza il rapporto fra applicazione e agente; MCP standardizza il rapporto fra l’agente e le capacità che può utilizzare.
La distinzione crea quindi una catena composta da livelli separati: workspace desktop, runtime agentico, strumenti e modello.
La portabilità fra harness è ancora parziale
Berd separa il workspace dal runtime per mantenere progetto, configurazione e cronologia indipendenti dall’agent harness utilizzato. Le connessioni MCP possono essere associate a Goose, Claude Code e Codex, permettendo di far convivere nello stesso ambiente configurazioni e strumenti provenienti da ecosistemi diversi.
Nella distribuzione pubblica, goose è il backend direttamente integrato dell’applicazione e ACP costituisce l’interfaccia utilizzata per gestire sessioni, modelli e configurazione.
La versione pubblica attuale utilizza quindi goose come runtime agentico principale, mentre la separazione fra workspace e harness rende l’architettura predisposta a una maggiore intercambiabilità dei componenti. Questo non implica che Claude Code, Codex o qualsiasi altro harness possano già sostituire liberamente goose nella distribuzione disponibile oggi.
Modello, provider e workspace restano separati
goose può lavorare con provider e modelli differenti. Berd mantiene così separati interfaccia, runtime e modello, consentendo di cambiare il provider senza modificare il workspace nel quale sono organizzati progetto e sessioni.
Questa architettura chiarisce anche il significato del carattere local-first dell’applicazione. Persistenza locale e inferenza locale sono due proprietà diverse.
goose conserva la cronologia delle sessioni in locale e, dalla versione 1.10, utilizza un database SQLite sessions.db al posto dei precedenti file JSONL. Berd costruisce sopra questa infrastruttura le funzioni di continuità delle conversazioni e dei progetti.
Se il modello viene eseguito sulla macchina dell’utente, anche l’inferenza può rimanere locale. Se viene scelto un provider cloud, prompt e contesto necessari alla generazione vengono invece inviati al servizio remoto configurato.
Il fatto che workspace e cronologia siano locali non significa automaticamente che tutti i dati elaborati dal modello rimangano sul dispositivo.
I dati restano locali, con limiti da distinguere
La telemetria di Berd è disabilitata per impostazione predefinita nelle distribuzioni ufficiali. L’utente può decidere di abilitarla dalle impostazioni dell’applicazione.
Quando viene attivata, Block raccoglie un identificatore casuale dell’installazione e un insieme limitato di eventi d’uso. La telemetria esclude esplicitamente prompt, messaggi, file, codice sorgente, credenziali, nomi e indirizzi email.
Gli indirizzi IP non vengono inclusi nei dati applicativi di telemetria, anche se possono essere elaborati durante il trasporto delle richieste per funzioni tecniche quali sicurezza e rate limiting.
Queste condizioni riguardano esclusivamente la telemetria di Berd verso Block. Il provider utilizzato per l’inferenza segue proprie condizioni e politiche di trattamento dei dati, che devono essere valutate separatamente.
Fork e distribuzioni di terze parti possono inoltre modificare, disabilitare o reindirizzare la telemetria, quindi le caratteristiche della build ufficiale non si estendono automaticamente a qualsiasi versione modificata.
L’agente diventa una configurazione riutilizzabile
Berd organizza ogni agente attraverso ruolo, istruzioni, skill, strumenti e identità visiva. L’interfaccia permette così di distinguere rapidamente configurazioni differenti all’interno dello stesso workspace.
Un agente dedicato alla scrittura può utilizzare istruzioni e capacità diverse da uno destinato al coding, alla revisione di un progetto o a un altro compito specialistico. La rappresentazione visuale rende riconoscibile quale configurazione sta intervenendo nella conversazione.
La versione 0.6.2 include sette agenti forniti inizialmente con l’applicazione e permette di esportare le agent card. Le configurazioni possono essere condivise come archivio ZIP mantenendo istruzioni e impostazioni, oppure esportate nei formati PNG e Markdown.
Il modello AI costituisce soltanto una parte di questa configurazione. L’identità operativa dell’agente comprende anche istruzioni, strumenti e competenze disponibili.
La complessità dell’esecuzione diventa visibile
Berd rende visibili anche le attività delegate ai subagent, cioè agenti secondari ai quali il runtime può affidare parti specifiche di un lavoro più ampio. Quando le informazioni sono disponibili, il workspace può mostrare l’identità del subagent e il compito assegnato.
Questa visibilità assume importanza nei workflow in cui l’agente compie azioni sul sistema. Una singola sessione può modificare file, eseguire comandi, invocare tool, delegare task e attendere risultati. L’interfaccia deve quindi consentire all’utente di ricostruire quale componente sta operando e in quale fase si trova l’esecuzione.
La gestione delle code dei messaggi segue la stessa logica. L’utente può continuare a impartire istruzioni mentre l’agente è occupato e Berd conserva le richieste fino a quando il runtime è pronto a elaborarle.
L’architettura prevede anche deployment enterprise
Un’organizzazione può utilizzare Berd come base per distribuzioni enterprise personalizzate, aggiungendo configurazioni gestite dei provider, agenti privati, risorse interne, strumenti opzionali, canali di aggiornamento e una propria infrastruttura di firma e pubblicazione.
La build pubblica rimane indipendente da questi componenti e non richiede registri di pacchetti privati o credenziali enterprise.
Questa struttura consente di configurare centralmente provider, strumenti e agenti autorizzati mantenendo separato il codice pubblico dalle componenti specifiche dell’organizzazione.
Codice aperto, governance chiusa
La licenza Apache 2.0 consente di utilizzare, modificare, compilare e distribuire Berd, compresa la creazione di fork e l’impiego in prodotti commerciali nel rispetto dei termini della licenza.
Lo sviluppo del repository ufficiale rimane però sotto il controllo di Block. Le pull request provenienti da collaboratori esterni non autorizzati vengono chiuse automaticamente.
La partecipazione della community passa attraverso issue per bug e richieste di funzionalità. Per i problemi tecnici vengono richiesti casi riproducibili, comportamento atteso ed effettivo, frequenza, versione dell’applicazione, sistema operativo e log pertinenti.
Licenza e governance operano quindi su piani differenti: il codice può essere liberamente forkato e sviluppato in modo indipendente, mentre la direzione del repository upstream rimane sotto il controllo di Block.
Tre release in cinque giorni
La velocità con cui si susseguono le prime versioni pubbliche dà una misura concreta della fase ancora iniziale del progetto. Berd 0.6.0 è stato pubblicato il 14 agosto 2026, la 0.6.1 il 17 agosto e la 0.6.2 il 18 agosto. Nell’arco di cinque giorni sono quindi arrivate tre release, con interventi sulla gestione delle conversazioni lunghe, sulla coda dei messaggi, sulle agent card, sulla navigazione, sulle connessioni MCP e sul sistema di aggiornamento.
La versione 0.6.2 indica inoltre che l’installer NSIS per Windows e i pacchetti Linux non dispongono attualmente delle firme native previste dalle rispettive piattaforme. Gli archivi destinati all’aggiornamento rimangono autenticati tramite Minisign e gli asset vengono accompagnati dai relativi hash SHA-256.
L’elemento tecnicamente più rilevante di Berd sta nella separazione dei livelli che compongono il sistema. Tauri e React costruiscono il workspace desktop; ACP collega l’interfaccia al runtime; goose gestisce il ciclo dell’agente; MCP espone strumenti e sorgenti dati; il provider determina il modello utilizzato per l’inferenza.
Questa struttura rende persistenti progetto, cronologia, configurazione e capacità operative mentre modelli, provider e runtime continuano a evolvere. Berd prova così a dare continuità al lavoro dell’utente in un ecosistema agentico nel quale i componenti sottostanti cambiano molto più rapidamente dei progetti su cui vengono impiegati.
