Berd s’appuie sur l’Agent Client Protocol (ACP), un protocole d’interopérabilité entre le client de bureau et les environnements d’exécution des agents. L’objectif est d’éviter de développer une intégration spécifique pour chaque outil : un agent compatible ACP peut communiquer avec un client compatible selon une interface commune. Goose, Claude Code, Codex et d’autres outils peuvent ainsi s’inscrire dans un même flux de travail.
Dans la pratique, Berd n’est toutefois pas un remplacement universel des installations et comptes de chaque fournisseur. Goose peut être intégré de près à l’application ou fourni comme runtime associé, tandis que Claude Code et Codex continuent de dépendre de leurs propres installations, abonnements ou identifiants. L’agent sélectionné détermine également quel fournisseur reçoit les requêtes, le code et les résultats des outils.
La pile technique annoncée combine Tauri 2 et React 19. Berd se présente donc comme une application de bureau, et non comme un simple espace de travail accessible dans un navigateur. Des versions sont disponibles pour macOS, Windows et Linux.
Ce choix vise les développeurs qui souhaitent garder leurs fichiers de projet et leurs sessions d’agents à proximité de leur environnement de développement habituel. En contrepartie, ils doivent gérer les questions classiques d’un logiciel installé localement : mises à jour, permissions, configuration des agents et protection des identifiants.
La conception « local-first » signifie que l’application et l’historique des projets ou des conversations sont conservés sur l’ordinateur, plutôt que dans un espace Block hébergé. C’est une limite de confidentialité importante, mais elle ne garantit pas que les traitements d’IA restent sur la machine.
Lorsqu’un agent utilise un modèle distant, une API en ligne ou un outil externe, les prompts, le code source, les fichiers et les résultats d’outils concernés peuvent quitter l’ordinateur. La confidentialité dépend donc aussi du harness choisi, du fournisseur de modèle, des outils connectés et de la configuration adoptée.
Les informations disponibles ne permettent pas d’établir une politique définitive de télémétrie pour Berd ni d’identifier précisément le coffre-fort de mots de passe ou le trousseau utilisé par chaque système d’exploitation. Pour un usage sensible, ces points doivent être vérifiés dans la documentation de sécurité et de confidentialité du dépôt actuel.
Berd est gratuit et open source sous licence Apache 2.0. Cela ne signifie pas que toutes les interactions avec les agents sont gratuites. Les utilisateurs doivent généralement fournir les abonnements ou les clés API requis par le modèle et le harness choisis, et les fournisseurs peuvent facturer l’utilisation.
Le coût réel se répartit donc en plusieurs catégories :
L’expression « distribution seams » désigne les zones opérationnelles à traiter pour passer d’un outil de bureau pratique à un produit administré à l’échelle d’une entreprise. Cela peut inclure l’installation et les mises à jour centralisées, la gestion des identités et des accès, la distribution des identifiants, les règles réseau et proxy, les journaux d’audit, le support et les politiques encadrant les actions des agents.
Les éléments disponibles ne montrent pas que Berd propose déjà une couche complète d’administration d’entreprise. Les organisations doivent donc considérer ces fonctions comme des points à vérifier lors du déploiement, et non comme des fonctionnalités automatiquement incluses dans la version Apache 2.0.
La fermeture automatique d’une pull request externe relève du processus de contribution du projet. Elle peut signifier que les mainteneurs souhaitent d’abord discuter des changements dans les issues, ou que le dépôt public reflète une source de code interne.
Cette pratique ne remet pas en cause la licence Apache 2.0 : chacun peut toujours consulter, utiliser, modifier et forker le code dans le respect de ses conditions. En revanche, les éléments disponibles ne précisent pas la raison exacte de Block. Il serait donc spéculatif d’attribuer cette politique à la sécurité, aux licences ou à une opposition aux contributions externes.
Berd et Buzz ne répondent pas au même usage.
Berd est l’espace de travail individuel. Une personne y pilote des agents sur ses projets locaux, ses fichiers, ses compétences et ses sessions.
Buzz est l’espace collaboratif. Lancé par Block le 21 juillet 2026, il propose un environnement partagé où humains et agents IA peuvent communiquer. Son modèle met l’accent sur une identité persistante du projet, les permissions et l’historique, même lorsque le modèle ou le harness change. Buzz prend en charge Claude Code, Codex, Goose et d’autres agents compatibles ACP.
Buzz peut aussi être configuré avec un relais géré par l’opérateur, notamment sur une machine locale ou une infrastructure privée. La collaboration ne dépend donc pas nécessairement d’une infrastructure hébergée par Block, même si cette option transfère à l’opérateur les responsabilités de déploiement et de sécurité.
Les deux projets partagent une approche indépendante du modèle et du harness, mais rien dans les informations disponibles ne confirme une fusion prévue entre Berd et Buzz ni une feuille de route commune.
La présentation publique de Block décrit Berd comme un espace adaptable couvrant les projets, outils, compétences, modèles et runtimes d’agents, plutôt que comme une simple interface dédiée à Goose. L’interopérabilité est donc la direction la plus clairement étayée.
En revanche, aucun élément suffisamment confirmé ne permet d’annoncer une feuille de route précise concernant l’administration d’entreprise, la télémétrie, l’évolution des tarifs ou une intégration officielle entre Berd et Buzz. Ces sujets restent ouverts jusqu’à une éventuelle documentation de Block ou une future annonce.