{"schema_version":"1.0","service":"Publicasta","type":"article","id":766,"slug":"october_bus_open_source_agent_coordination","title":"October Bus ouvre une couche de coordination pour les agents de code : ce qui est prêt à tester","excerpt":"October Bus sépare la coordination entre agents du harnais de développement lui-même. Son exécution locale, son protocole provisoire, ses tâches persistantes et ses reçus sont prometteurs, mais les interfaces restent pré-stables et l’exécution demeure locale.","language":"fr","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=fr","image":{"url":"https://publicasta.com/storage/projects/10/pages/766/2026/10/3bb25dab-6ec1-4698-a3ab-7f069fdfd34c.webp","alt":"Trois postes de travail de programmation reliés par des câbles à un petit appareil réseau central dans un espace de travail chaleureusement éclairé."},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source Radar","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-10-05T06:48:54+00:00","updated_at":"2026-10-05T06:48:54+00:00","content_markdown":"Les agents de code sont efficaces lorsqu’ils travaillent isolément. L’un peut inspecter un dépôt, modifier des fichiers, lancer des tests et rendre compte du résultat. La difficulté commence quand plusieurs agents interviennent. L’humain devient alors la couche d’intégration : il copie une exigence d’un terminal à l’autre, colle un diff dans une session de revue, vérifie qu’une demande a bien été vue et se souvient encore quel agent est responsable de la tâche inachevée.\n\n ![Trois postes de travail de programmation reliés par des câbles à un petit appareil réseau central dans un espace de travail chaleureusement éclairé.](https://publicasta.com/storage/projects/10/pages/766/2026/10/3bb25dab-6ec1-4698-a3ab-7f069fdfd34c.webp)\n\n October Bus est une tentative open source de supprimer cette transmission manuelle de messages sans transformer chaque agent en un immense processus partagé. Le projet fournit une couche de communication et de coordination que des harnais indépendants peuvent utiliser pour découvrir leurs pairs, échanger des messages persistants, déléguer un travail circonscrit et suivre la responsabilité des tâches. Le propre harnais de développement d’October constitue la première intégration visible, mais le dépôt Bus décrit une ambition plus large : un protocole que d’autres harnais peuvent implémenter sans adopter le produit hébergé ou le plan de contrôle d’October.\n\n C’est la distinction importante de cette version. October Bus n’est ni un nouveau modèle de code, ni une nouvelle interface de terminal, ni un superviseur autonome. C’est un ensemble de primitives de coordination. Le runtime local, le daemon Go, le client TypeScript, les outils MCP, le stockage SQLite et la spécification provisoire 0.1 sont exécutables, tandis que le projet avertit explicitement que les interfaces du protocole et des paquets peuvent changer avant une version stable.\n\n ## Le problème que cherche réellement à résoudre October Bus\n\n Lancer plusieurs agents en parallèle est facile à montrer et étonnamment difficile à exploiter. Un développeur peut démarrer une session pour l’implémentation, une autre pour les tests et une troisième pour la documentation. Cela crée de la concurrence, mais pas nécessairement de la collaboration. Les sessions ne savent pas automatiquement ce que font les autres, quel contexte est pertinent, si une demande a été acceptée ou si un résultat reste valable après la modification du code initial.\n\n La solution habituelle consiste à partager une transcription complète ou à demander à l’utilisateur de relayer des résumés. Les deux approches sont coûteuses. Une transcription complète contient du raisonnement privé, des sorties d’outils sans rapport, des identifiants parfois mentionnés par inadvertance dans le contexte et des hypothèses qui n’ont pas leur place dans la tâche suivante. Un bref résumé manuel est plus sûr, mais devient un nouvel élément d’état du projet susceptible de devenir obsolète.\n\n October Bus adopte une approche plus étroite : les agents échangent un contexte explicite et limité ainsi que des enregistrements de coordination. Un agent de construction peut découvrir un pair qui déclare une capacité de revue, lui envoyer une demande ciblée sur un fichier ou un comportement, créer une tâche, continuer son travail, puis récupérer la réponse plus tard. Le réviseur n’a pas besoin de toute la transcription du constructeur. Il lui faut la question, le contexte joint et un accès suffisant, dans sa propre frontière de confiance locale, pour effectuer la revue.\n\n C’est un choix de conception utile, car la coordination n’est pas la même chose qu’une mémoire partagée. Le Bus enregistre les messages, les demandes, les réponses, les reçus, les changements de tâches et les escalades. Il n’expose pas automatiquement le contexte privé de chaque agent à tous les autres participants. Une implémentation peut donc préserver les frontières locales tout en rendant les transferts inspectables.\n\n L’exemple du projet est volontairement banal : un constructeur demande à un réviseur d’examiner le chemin de nouvelle tentative d’un paiement, le réviseur constate qu’une clé d’idempotence est perdue, puis le constructeur reçoit la réponse lors de sa prochaine consultation de boîte de réception. La valeur ne réside pas dans l’exemple lui-même. Elle se trouve dans le cycle explicite qui l’encadre : découvrir, demander, prendre en charge, répondre et récupérer.\n\n ## Ce que contient le dépôt ouvert\n\n Le dépôt October Bus décrit quatre couches importantes pour qui veut l’évaluer. La première est la surface du protocole : une spécification provisoire 0.1, un contrat HTTP, une correspondance MCP, un contrat d’adaptateur et des schémas JSON. Les versions du protocole sont censées être indépendantes des versions du runtime et du SDK, ce qui est cohérent si différents harnais doivent adopter le même langage de coordination à des rythmes différents.\n\n La deuxième est le runtime local de référence. Le projet indique que le daemon Go, le client TypeScript, le stockage SQLite persistant, les outils MCP et les tests sont exécutables aujourd’hui. Le fonctionnement local d’abord est significatif. Un développeur peut étudier le comportement et expérimenter sans devoir faire confiance à un service de coordination hébergé ni placer un compte cloud au centre du flux de travail.\n\n La troisième regroupe les primitives de coordination elles-mêmes :\n\n - **Identité et découverte :** les agents disposent d’identités stables et peuvent déclarer leurs capacités et leur disponibilité.\n- **Présence :** existence, disponibilité, accessibilité et cycle de vie sont traités comme des faits distincts plutôt que comme un unique indicateur en ligne/hors ligne.\n- **Messagerie :** notifications, demandes, réponses, boîtes de réception et reçus sont des enregistrements persistants.\n- **Délégation :** un agent peut demander à un autre d’effectuer un travail circonscrit.\n- **Tâches partagées :** humains et agents peuvent ajouter du travail, le prendre en charge, signaler leur progression, le libérer, le terminer et déclarer des dépendances.\n- **Escalade humaine :** un agent peut demander un avis ou une autorisation au lieu d’inventer une réponse.\n- **Observation :** les responsables d’un périmètre peuvent suivre les événements ordonnés sans collecter chaque trace de raisonnement privée.\n\n La quatrième est l’idée d’adaptateur. October Bus est destiné à se placer sous les logiques de composition d’équipe et de flux propres à chaque produit. Un adaptateur relierait un harnais au Bus tout en laissant au harnais la responsabilité de ses appels de modèle, de ses outils, de sa gestion du contexte et de ses permissions. Cette séparation constitue l’argument open source le plus solide du projet : le contrat de coordination peut devenir une infrastructure partagée même si les développeurs utilisent des harnais différents.\n\n Le dépôt October Harness montre à quoi ressemble cette intégration en pratique. Il peut fonctionner de manière interactive dans un terminal, comme processus d’affichage ponctuel, en mode JSON, via RPC ou comme SDK intégré. Son intégration au Bus est conditionnée par l’exécution : le lanceur fournit une adresse, un endpoint MCP, une identité d’agent, une identité d’exécution et un jeton, puis le harnais n’enregistre les outils et les hooks du Bus que lorsqu’une configuration valide est présente. Cela rend l’intégration plus concrète qu’une promesse de README, sans toutefois établir la compatibilité avec des harnais indépendants.\n\n ## La livraison persistante compte davantage que le chat\n\n De nombreuses démonstrations d’agents utilisent une métaphore de chat : un agent envoie un message et un autre semble répondre. C’est pratique pour une vidéo et insuffisant pour le travail réel. Un agent de code peut être occupé, en pause, déconnecté, en attente d’une intervention utilisateur ou fonctionner selon un autre calendrier. Si la livraison dépend du fait que les deux agents soient actifs exactement au même instant, la coordination devient une interaction au premier plan aussi fragile que les autres.\n\n October Bus traite au contraire la livraison comme un état. Un envoi n’est accepté qu’après sa persistance par le runtime local. Une nouvelle tentative avec la même clé d’idempotence renvoie le reçu initial tant que le message est conservé ; la réutilisation de cette clé avec un contenu différent est refusée. Un message peut être mis en file, réservé par une tentative de livraison, livré, accusé de réception ou expirer. Une demande crée une obligation de réponse, et une réponse identifie la demande qu’elle termine.\n\n Ces détails semblent administratifs, mais c’est à ce niveau que les systèmes multi-agents deviennent habituellement peu fiables. Sans idempotence, une nouvelle tentative peut créer des tâches en double. Sans accusé de réception explicite, l’expéditeur ne peut pas distinguer « le processus ne l’a jamais vu » de « le processus l’a vu mais n’a pas encore agi ». Sans expiration, une ancienne demande peut être exécutée après que le code ou la décision environnante a changé. Sans sémantique de propriété et de libération, deux agents peuvent croire simultanément qu’ils sont responsables du même travail.\n\n La conception traite aussi les réponses tardives avec prudence. Le Bus peut arrêter les tentatives de livraison après expiration tout en représentant une réponse qui arrive tardivement, après la livraison de la demande. Le client peut alors décider si le résultat est utile au lieu de réécrire silencieusement l’historique. Pour la revue de code et le travail de build, c’est important : une réponse techniquement correcte peut néanmoins être obsolète si l’implémentation a évolué.\n\n Le flux d’événements est une autre fonction pratique. Les responsables d’un périmètre peuvent observer dans l’ordre les enregistrements, les messages, les changements de tâches et les escalades humaines. Les clients reprennent à partir d’une révision d’événement et, si la rétention a supprimé l’historique requis, le Bus leur indique de reconstruire leur vue à partir des API de ressources. C’est un modèle opérationnel plus réaliste que l’hypothèse d’un journal d’événements infini ou d’un tableau de bord connecté en permanence.\n\n ## Le modèle de sécurité est volontairement limité\n\n Le projet avance une idée facile à manquer dans une démonstration rapide : savoir qu’un autre agent existe ne donne pas accès à ses fichiers, à ses outils, à son processus ou à son contexte. Une demande adressée à un pair est une donnée. Ce n’est pas une élévation de permission. Le harnais qui la reçoit décide toujours s’il doit agir, quels outils locaux sont disponibles et si l’utilisateur doit approuver l’opération.\n\n L’autorité est liée à une exécution et non à la seule identité logique de l’agent. Réenregistrer un agent remplace l’exécution et retire le jeton précédent. Les prises en charge de tâches appartiennent à cette exécution, et un harnais est censé envoyer des signaux de présence tant qu’il détient une prise en charge afin que le Bus puisse la libérer si le travailleur disparaît. C’est une réponse utile à une panne ordinaire : une tâche ne devrait pas rester verrouillée indéfiniment parce qu’un ordinateur portable s’est fermé ou qu’un processus a planté.\n\n Le contexte est limité par conception. Un pair voit le contexte explicitement partagé pour la collaboration, pas une transcription globale. Les descriptions de ressources ne sont pas des identifiants secrets. L’escalade humaine reste une opération de premier ordre : un agent peut demander une décision ou une permission sans prétendre qu’un message provenant d’un autre agent vaut approbation.\n\n Les limites sont tout aussi importantes. October Bus n’est pas un bac à sable de système d’exploitation et ne rend pas sûr l’exécution d’un agent de code contre un dépôt non fiable. La documentation d’October Harness précise que les processus locaux d’agent de code s’exécutent avec les permissions du système d’exploitation de l’utilisateur qui les démarre et recommande un conteneur, une machine virtuelle, une micro-VM ou un bac à sable contrôlé par politique pour le travail non fiable ou sans surveillance. Les extensions, compétences, prompts et paquets tiers doivent eux aussi être traités comme du code et des instructions exécutables.\n\n Le bon modèle mental est donc celui de la **sécurité de coordination**, et non celui de la **sécurité d’exécution**. Le Bus peut empêcher un message pair-à-pair d’accorder silencieusement une nouvelle autorité, mais il ne peut pas empêcher un agent local déjà autorisé de modifier des fichiers ou de lancer des commandes. Cette frontière est saine lorsqu’elle est énoncée clairement. Il serait trompeur de présenter les enregistrements persistants de tâches et les jetons d’exécution comme un remplacement du sandboxing.\n\n ## Pourquoi la licence Apache 2.0 compte\n\n October Bus est distribué sous licence Apache 2.0. Le dépôt explique que cette licence permissive est intentionnelle afin que les développeurs d’agents et de harnais, y compris les produits commerciaux, puissent adopter et implémenter le protocole. La licence couvre le code et la documentation du dépôt, mais pas les noms, logos ou éléments de marque d’October.\n\n Cette posture de licence diffère de celle d’un produit hébergé doté d’un client ouvert et d’un service de coordination fermé. Le dépôt ouvert comprend le protocole, le runtime local, les SDK, les adaptateurs, les exemples et les tests. Le projet place la frontière au niveau de la composition automatique des équipes, de la sélection des modèles, du routage des quotas, de la planification des opérations, de la supervision, de l’évaluation des résultats, de l’infrastructure cloud gérée, de la facturation et des contrôles d’entreprise.\n\n Cette frontière mérite d’être examinée plutôt qu’approuvée automatiquement. Un protocole ouvert peut être utile même si l’expérience utilisateur la plus pratique reste commerciale. Mais l’interopérabilité dépendra de la capacité des implémentations tierces à réaliser les opérations importantes sans s’appuyer sur un comportement privé du service. La spécification provisoire et le travail de conformité sont donc plus déterminants que la promesse bien présentée d’une équipe d’agents.\n\n Cette distinction rend aussi le projet plus facile à évaluer. Un développeur peut demander : la couche ouverte suffit-elle à relier deux processus locaux, à inspecter la livraison, à récupérer après un redémarrage et à échanger un contexte limité ? Si oui, le protocole possède une valeur autonome. Une autre question est de savoir si le produit hébergé d’October fournit une meilleure composition d’équipe et un meilleur routage. C’est une comparaison de produits, pas un argument open source.\n\n ## Ce qui est prêt à tester maintenant\n\n Le premier test utile est local et de petite taille. Il ne faut pas commencer par tenter de recréer une entreprise logicielle autonome. Commencez avec deux agents et un seul transfert précisément défini. Un agent réviseur peut inspecter une modification faite par un agent constructeur. Un agent de test peut lancer une suite ciblée et renvoyer les cas en échec. Un agent analyste peut résumer un jeu de données pendant que l’agent d’implémentation poursuit son travail dans un autre dépôt.\n\n Une expérience locale représentative ressemble à ceci :\n\n ```text\nplanificateur -> découvre le constructeur et le réviseur\nconstructeur  -> prend en charge la tâche d’implémentation\nconstructeur  -> demande la revue d’une modification circonscrite\nréviseur      -> prend en charge la tâche de revue et signale sa progression\nréviseur      -> renvoie ses constats avec une réponse corrélée\nconstructeur  -> accuse réception ou escalade vers un humain\n```\n\n Le test doit inclure volontairement des interruptions. Arrêtez le réviseur après sa prise en charge d’une tâche. Redémarrez-le. Réessayez un envoi avec la même clé d’idempotence. Laissez une demande expirer. Envoyez une réponse après que la branche environnante a changé. Supprimez un ancien historique d’événements et vérifiez que le client peut reconstruire sa vue. Ce sont ces scénarios qui indiquent si le système est une couche de coordination ou simplement une démonstration de messagerie.\n\n Le dépôt October Harness documente un exemple local multi-agents dans lequel un Bus épinglé et deux processus de travailleurs SDK sont démarrés avec des identités distinctes. Les commandes et la configuration exactes peuvent changer tant que le projet reste pré-stable ; il faut donc les prendre dans le dépôt actuel plutôt que les recopier dans une procédure d’équipe appelée à durer. Le résultat important n’est pas que deux terminaux puissent échanger du texte. C’est qu’une tâche reste attribuable et récupérable entre les processus.\n\n Utilisez un dépôt jetable et des identifiants non sensibles. Gardez le Bus local sur la boucle locale pendant les premiers tests. Donnez à chaque agent le périmètre minimal de système de fichiers nécessaire à son rôle. N’installez pas d’extensions non vérifiées simplement parce que le Bus peut les découvrir ou les charger. Examinez chaque diff généré, en particulier lorsqu’une demande pair-à-pair provient de l’extérieur du dépôt ou de la machine courante.\n\n Pour une première évaluation, consignez au moins les observations suivantes :\n\n - Combien de temps faut-il pour découvrir un pair et vérifier la capacité qu’il déclare ?\n- L’expéditeur peut-il distinguer persistance, livraison, accusé de réception, expiration et réponse tardive ?\n- Un travailleur qui plante libère-t-il sa prise en charge après l’intervalle de bail attendu ?\n- Le harnais récepteur peut-il agir sur une demande sans recevoir de contexte privé sans rapport ?\n- Un humain peut-il rejeter ou modifier une opération proposée sans que le pair contourne cette décision ?\n- Le système peut-il être mis à niveau sans invalider les messages ou les enregistrements de tâches stockés ?\n- Les journaux suffisent-ils à reconstituer ce qui s’est passé sans collecter le raisonnement du modèle ?\n\n Si les réponses restent floues, ajouter des agents rendra le système plus difficile à comprendre plutôt que plus capable.\n\n ## Qui devrait y prêter attention\n\n October Bus intéressera surtout les développeurs qui construisent des infrastructures d’agents, des harnais de terminal, des travailleurs CI, de l’automatisation de dépôts et des outils conçus pour fonctionner d’abord en local. Il donne à ces projets un vocabulaire pour la présence, la délégation, les prises en charge, les reçus et le contexte limité, sans les obliger à partager un fournisseur de modèles ou une interface utilisateur. Les équipes qui exploitent déjà plusieurs agents spécialisés reconnaîtront immédiatement le problème.\n\n Le projet concerne également les mainteneurs de harnais open source qui ne souhaitent pas devenir un écosystème fermé. Un protocole commun peut permettre à un outil centré sur la revue de coopérer avec un agent de code, un exécuteur de tests ou un travailleur de documentation. L’avantage est la possibilité de choix : les utilisateurs peuvent changer le harnais responsable d’un rôle sans reconstruire toute la pile de collaboration.\n\n Le projet est moins convaincant pour qui cherche seulement une meilleure expérience de terminal avec un agent unique. October Harness peut mériter une évaluation selon ses propres critères, mais le Bus ajoute une complexité opérationnelle utile uniquement lorsqu’un vrai problème de coordination existe. Un développeur seul, avec un dépôt et une seule session active, tirera peut-être davantage profit d’un bon stockage de session, de permissions claires et de tests reproductibles que d’un bus de messages.\n\n Il est également trop tôt pour les équipes qui recherchent une norme inter-fournisseurs stable. Le dépôt qualifie le protocole de spécification provisoire 0.1 et indique que les interfaces des paquets peuvent changer avant la première version stable. Des composants exécutables et une orientation de conception claire sont déjà présents, mais les preuves de compatibilité nécessaires à un engagement généralisé en production ne le sont pas encore.\n\n ## Alternatives et projets voisins\n\n L’alternative la plus directe n’est pas un autre Bus. C’est un flux de travail construit avec des tickets Git, des pull requests, des tâches CI et une file d’attente ordinaires. Cette approche est plus lente pour les transferts conversationnels, mais elle offre des pistes d’audit mûres, des permissions connues et des points de revue humaine explicites. Pour beaucoup d’équipes, un ticket classique accompagné d’un artefact de test reste un meilleur enregistrement de coordination qu’un protocole d’agents expérimental.\n\n Une deuxième alternative est la prise en charge multi-agents propre au harnais. Les outils de développement peuvent coordonner des sous-agents grâce à leur propre modèle de session, leur liste de tâches partagée ou leur API d’extensions. L’installation est souvent plus simple et l’intégration peut être plus étroite avec le produit principal. Le compromis est l’enfermement : un flux conçu autour d’un harnais peut ne pas être transférable à un autre.\n\n Une troisième possibilité consiste à conserver la coordination au niveau applicatif. Une équipe peut exposer un petit service qui accepte des travaux, stocke leur état et renvoie des résultats, chaque agent étant traité comme un travailleur. Cela peut convenir lorsque les limites des tâches sont très structurées. Cette solution ne fournit généralement pas de modèle général de découverte, de présence, d’escalade humaine ou de contexte limité, qui est précisément le terrain visé par October Bus.\n\n La comparaison pertinente n’est donc pas « quel agent est le plus intelligent ? ». C’est plutôt : « où l’état de coordination doit-il vivre, qui peut le voir et comment un travailleur prouve-t-il qu’il possède encore la tâche ? » October Bus tente de rendre ces questions explicites entre différents harnais.\n\n ## Le risque open source est la dérive du protocole\n\n Le principal risque à court terme n’est pas que l’idée soit mauvaise. C’est que la couche ouverte et le produit hébergé évoluent à des vitesses différentes. Si des comportements importants existent uniquement dans le plan de contrôle privé d’October, les adaptateurs tiers pourront techniquement se connecter tout en restant des implémentations de second rang. Si le protocole provisoire change plus vite que les clients indépendants ne peuvent le suivre, les développeurs hésiteront à construire dessus.\n\n La frontière open source annoncée par le projet est utile, car elle nomme les fonctions qui devraient rester dans la couche interopérable. Les prochaines preuves devront venir de tests de conformité, d’adaptateurs indépendants, de profils de compatibilité versionnés et d’exemples ne nécessitant pas les services privés d’October. Une licence Apache rend l’adoption juridiquement accessible ; elle ne rend pas à elle seule l’interopérabilité durable.\n\n Il existe aussi une question de gouvernance. Un protocole de coordination entre agents n’est pas neutre simplement parce que ses messages sont en JSON. Les décisions concernant l’identité, l’expiration, les prises en charge, les limites de contexte et l’escalade humaine déterminent quels flux sont simples et lesquels deviennent pénibles. Les mainteneurs devraient publier clairement ces décisions, accepter les retours des implémenteurs et rendre visibles les échecs de compatibilité.\n\n La feuille de route du dépôt va dans la bonne direction : renforcer et versionner l’implémentation locale, élargir les preuves de conformité, ajouter d’autres SDK, définir des transports enfichables et stabiliser une spécification d’interopérabilité. Ces travaux sont moins spectaculaires que la composition automatique d’équipes, mais ce sont eux qui peuvent transformer un dépôt prometteur en infrastructure partagée.\n\n ## Verdict\n\n October Bus mérite un test technique contrôlé parce qu’il s’attaque à une lacune concrète : des agents de code indépendants ont besoin de transferts persistants et inspectables sans partager toutes leurs transcriptions ni s’accorder mutuellement une nouvelle autorité. Ses idées les plus crédibles sont les moins voyantes : envois idempotents, états de livraison explicites, prises en charge liées à l’exécution, contexte limité, baux, réponses corrélées et récupération des événements. Ces détails correspondent à des défaillances que connaissent les vrais systèmes multiprocessus.\n\n Le projet ne doit pas encore être considéré comme une norme de coordination prête pour la production. Le protocole est provisoire, les interfaces peuvent changer, les harnais compatibles restent peu nombreux et les agents sous-jacents demeurent des processus locaux disposant des permissions de leurs utilisateurs. Un Bus ne remplace ni le sandboxing, ni la revue de code, ni la réduction des identifiants sensibles, ni une frontière de décision humaine.\n\n Pour les développeurs qui expérimentent déjà avec plusieurs agents, l’étape raisonnable est un test local à deux agents autour d’un seul transfert de revue ou de test. Mesurez la persistance, la récupération, la propriété et les frontières de contexte avant de mesurer la vitesse. Pour les autres, il faut suivre le travail de conformité du projet et l’arrivée d’adaptateurs indépendants. Si ces éléments apparaissent tandis que la frontière ouverte reste réelle, October Bus pourrait devenir un composant utile de l’infrastructure commune des prochaines générations d’outils pour développeurs.\n\n Sources : [dépôt October Bus et protocole provisoire](https://github.com/october-dev/october-bus), [dépôt October Harness et documentation de l’intégration](https://github.com/october-dev/october-harness), [frontière de sécurité de Pi](https://github.com/earendil-works/pi/security), [documentation de l’agent de code Pi et licence MIT](https://github.com/pi-packages/earendil-works-pi/blob/main/packages/coding-agent/README.md).","available_translations":[{"language":"ar","title":"October Bus يفتح طبقة لتنسيق وكلاء البرمجة — ما الذي أصبح جاهزاً للاختبار","html_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=ar","markdown_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=ar","json_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/october_bus_open_source_agent_coordination?lang=ar"},{"language":"de","title":"October Bus öffnet eine Koordinationsebene für Coding-Agenten – was jetzt testbar ist","html_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=de","markdown_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=de","json_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/october_bus_open_source_agent_coordination?lang=de"},{"language":"en","title":"October Bus opens a coordination layer for coding agents — what is ready to test","html_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=en","markdown_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=en","json_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/october_bus_open_source_agent_coordination?lang=en"},{"language":"es","title":"October Bus abre una capa de coordinación para agentes de programación: qué está listo para probar","html_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=es","markdown_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=es","json_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/october_bus_open_source_agent_coordination?lang=es"},{"language":"fr","title":"October Bus ouvre une couche de coordination pour les agents de code : ce qui est prêt à tester","html_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=fr","markdown_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=fr","json_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/october_bus_open_source_agent_coordination?lang=fr"},{"language":"pl","title":"October Bus otwiera warstwę koordynacji agentów programistycznych — co jest gotowe do testów","html_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=pl","markdown_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=pl","json_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/october_bus_open_source_agent_coordination?lang=pl"},{"language":"ru","title":"October Bus открывает координационный слой для кодинговых агентов — что уже можно тестировать","html_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=ru","markdown_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=ru","json_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/october_bus_open_source_agent_coordination?lang=ru"},{"language":"zh","title":"October Bus 为编码代理开放协作层：目前有哪些功能可测试","html_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=zh","markdown_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=zh","json_url":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/october_bus_open_source_agent_coordination?lang=zh"}],"_links":{"self":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=fr","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/october_bus_open_source_agent_coordination?lang=fr","html":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=fr","canonical":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=fr","markdown":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=fr","json":"https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=fr","channel":"https://publicasta.com/api/public/v1/channels/open_source_radar","channel_articles":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}