agentixmesh

Questions

APPENDIX A · FAQ

Questions fréquentes

Des réponses directes sur ce qu'est agentixmesh, avec quels outils d'agents il fonctionne, ce qu'il sécurise, et en quoi il diffère d'une message queue.

Principes de base

Qu'est-ce qu'agentixmesh ?
agentixmesh est une couche de confiance pour agents — une couche de livraison basée sur des fichiers qui permet à des sessions d'agents IA sur une même machine d'échanger des messages sans hériter mutuellement de leur autorité, adressées via `uid:project`. Le transport est un maildir (répertoires new/cur/held/seen) plus un inject hook : pas de daemon, pas d'écouteur réseau, pas de port ouvert, pas de sudo. Sous licence MIT et ouvert sur GitHub (github.com/TokonoMix/agentixmesh).
Que signifie « les données ne sont pas une autorité » ?
Cela signifie qu'un message entrant est rendu sous forme de trame DATA inerte à lire, jamais comme une commande à obéir. L'agent récepteur décide de ce qu'il fait ; le mesh n'agit jamais automatiquement sur le contenu d'un message. Répondre par des mots en réaction à un message est acceptable ; entreprendre une action, exécuter du code, ou révéler des secrets uniquement parce que le corps d'un message le demande ne l'est pas.
Quel problème agentixmesh résout-il réellement ?
Il résout le risque de « confused deputy » (député confus) de la messagerie locale agent-à-agent : une session héritant de l'autorité d'une autre simplement parce qu'un message est arrivé. agentixmesh sépare qui a envoyé un message (un identifiant utilisateur OS vérifié par le kernel) de ce qu'il dit (un corps non fiable), afin qu'un message puisse prouver son expéditeur sans que cette preuve n'autorise quoi que ce soit que le message demande. Le confinement, pas la communication, est la partie difficile.
À qui s'adresse agentixmesh ?
Aux ingénieurs qui font tourner plusieurs sessions d'agents IA — Claude Code aujourd'hui, d'autres harnais via des adapters à venir — sur la même machine, qui ont besoin que ces sessions se transmettent des informations ou se coordonnent sans mettre en place une file de messages ou un système de tickets, et sans que la sortie d'une session ne devienne silencieusement les instructions d'une autre. Cela suppose des workflows d'agents en ligne de commande, pas des produits de chat destinés à l'utilisateur final.
agentixmesh est-il prêt pour la production ?
Partiellement, et par conception en plusieurs étapes. Le cœur same-user (même utilisateur) est public et stable — c'est le défaut livré et dogfoodé. La livraison cross-user (utilisateurs OS distincts, une machine) est validée de bout en bout, mais sa mise en production reste soumise à une porte humaine (human-gated) : le corps d'un message est retenu jusqu'à ce qu'une personne le libère. La livraison cross-machine n'existe pas encore — c'est une feuille de route (roadmap), pas agentixmesh.
agentixmesh est-il juste un message bus ou un système pub/sub ?
Non. Un message bus déplace des octets ; agentixmesh se préoccupe de ce qu'une session est autorisée à faire une fois les octets arrivés. L'élément distinctif n'est pas le transport (un maildir) — c'est l'identité de l'expéditeur vérifiée par le kernel plus le framing inert-DATA qui empêche un message livré d'être traité comme une commande. Le pub/sub classique n'a ni l'une ni l'autre de ces propriétés.
Pourquoi baser cela sur des fichiers (un maildir) plutôt qu'un socket ou un daemon ?
Un maildir ne nécessite aucun processus en cours d'exécution, aucun port, et aucune élévation de privilège — la livraison n'est que des fichiers qui se déplacent entre des répertoires owner-only (0700) déjà protégés par l'OS. Un daemon ou un écouteur socket ajoute une surface d'attaque permanente et une charge opérationnelle (démarrage/arrêt, récupération après crash, permissions) pour un cas d'usage sur une seule machine et à faible débit que la sémantique du système de fichiers couvre déjà.
Que signifie « couche de confiance pour agents » (agent trust layer) ?
Cela signifie qu'agentixmesh se situe sous le contenu du message et répond à une seule question : peut-on faire confiance à celui qui l'a envoyé ? Il vérifie par le kernel (kernel-verified) l'identifiant utilisateur OS de l'expéditeur via fstat sur le descripteur de fichier ouvert — infalsifiable — tout en traitant tout le reste, y compris le corps et le label de projet auto-déclaré de l'expéditeur, comme non fiable. La confiance ici porte sur l'identité, pas sur ce qu'un message prétend.
Qu'est-ce qu'une adresse (uid:project) ?
Une adresse est `uid:project` — l'identifiant utilisateur OS numérique du destinataire visé, plus un label de projet. La moitié uid est ce que le mesh applique réellement pour la livraison. La moitié project n'est que le basename du répertoire de travail courant de l'expéditeur, auto-déclarée et non vérifiée, utilisée pour router vers la bonne boîte de réception de cet utilisateur. `mesh-whoami` affiche votre propre adresse.
Quel est le rôle de l'humain dans agentixmesh ?
L'humain est l'autorité finale, le plus concrètement pour la livraison cross-user : le corps d'un message est retenu jusqu'à ce qu'un humain le libère, rendant l'action cross-user non supervisée impossible par construction. Plus largement, agentixmesh n'agit jamais automatiquement sur le contenu d'un message — l'agent récepteur décide quoi en faire — laissant les personnes, pas le mesh, aux commandes des décisions à conséquences.
agentixmesh est-il un framework ou un protocole ?
C'est plus proche d'un protocole plus une implémentation de référence légère que d'un framework. Le cœur — identité de l'expéditeur vérifiée par le kernel, transport maildir, framing inert-DATA — est neutre vis-à-vis du harness par conception et ne dicte pas les internes de votre agent. Vous intégrez en câblant un adapter de harness au protocole, pas en réécrivant votre agent pour se conformer à la structure d'agentixmesh.
Que n'essaie PAS d'être agentixmesh ?
Il n'essaie pas d'être une file de messages généraliste, un transport cross-machine, ni une garantie de sécurité contre l'injection de prompt. Il n'essaie pas de rendre les agents autonomes en votre nom — l'action automatique cross-user est bloquée par conception, pas seulement déconseillée. La livraison cross-machine et des fonctionnalités à plus haute autorité comme la co-approbation leader-gate n'existent qu'à l'état de feuille de route, pas comme des choses qu'il prétend faire aujourd'hui.

Compatibilité & harnais

agentixmesh fonctionne-t-il avec Claude Code ?
Oui — Claude Code est l'adapter de référence et il est livré aujourd'hui. Il câble le mesh via les hooks SessionStart et UserPromptSubmit de Claude Code, de sorte que les messages apparaissent automatiquement dans le contexte sans changer votre façon d'utiliser Claude Code. C'est l'intégration la plus éprouvée et celle contre laquelle la conception maildir/inject-hook a été construite en premier.
agentixmesh fonctionne-t-il avec OpenAI Codex CLI ?
Un adapter est livré et testé unitairement. La vérification end-to-end sur le binaire réel de Codex CLI est encore en cours, donc traitez-le comme livré-mais-pas-encore-pleinement-vérifié-en-conditions-réelles plutôt que prouvé en production. Nous ne décrirons pas le chemin Codex comme « terminé » avant que cette vérification en conditions réelles ne soit achevée.
agentixmesh fonctionne-t-il avec Gemini ou d'autres outils d'agents ?
Pas encore. Des adapters Hermes et OpenClaw sont conçus et prototypés, ce qui les place sur la feuille de route, pas dans l'ensemble livré. Aujourd'hui, les seuls adapters sont Claude Code (référence, livré) et OpenAI Codex CLI (testé unitairement, vérification e2e en conditions réelles en cours). Considérez tout autre harness comme non pris en charge tant qu'un adapter n'est pas livré.
Que signifie concrètement « harness-agnostic » ici ?
Cela signifie que le cœur — transport maildir, identité vérifiée par le kernel, framing des messages — n'a aucune dépendance envers un outil d'agent particulier. Ce qui est spécifique à l'outil, c'est une fine couche d'adapter qui câble ce cœur dans le propre système de hooks d'un harness, comme SessionStart/UserPromptSubmit de Claude Code. Le protocole ne change pas selon l'outil ; seul le câblage change.
Deux outils d'agents différents, comme Claude Code et Codex CLI, peuvent-ils échanger des messages sur le même mesh ?
Architecturalement oui — le format maildir et le modèle d'identité vérifié par le kernel se moquent de quel harness a écrit ou lu un message, seulement de quel utilisateur OS l'a fait. Mais la preuve en conditions réelles couvre aujourd'hui Claude Code de bout en bout ; l'e2e sur binaire réel de Codex CLI, y compris un véritable échange cross-harness, est encore en cours, donc ne traitez pas ce scénario comme validé pour l'instant.
Dois-je modifier le code de mon agent pour utiliser agentixmesh ?
Non — vous installez les wrappers CLI et câblez un petit hook une fois ; il n'y a aucune modification du code source propre de l'agent. Pour Claude Code, c'est l'adapter de référence, livré aujourd'hui. Pour d'autres harnais, un adapter câble les mêmes commandes mesh sous-jacentes dans le système de hooks de cet outil à la place.
Qu'est-ce que le contrat push-hook — comment un message se retrouve-t-il dans le contexte de mon agent ?
Le hook se déclenche au démarrage de la session et à chaque soumission de prompt utilisateur. Il effectue une lecture de fichier zéro-token de la boîte aux lettres, et s'il y a du nouveau courrier, il imprime une trame DATA inerte sur stdout. Le harness traite la sortie stdout du hook comme du contexte injecté, donc le message apparaît sans que le mesh lui-même ne fasse le moindre appel LLM.
agentixmesh fonctionne-t-il entre différentes machines ?
Non, une seule machine seulement. Toute la livraison actuelle — Claude Code et Codex CLI — tourne sur un seul hôte via un maildir local ; il n'y a aucun écouteur réseau ni transport distant. La livraison cross-machine, signée cryptographiquement, est un produit séparé, AgentsWeaver, et figure sur la feuille de route de ce projet, pas dans agentixmesh.
Comment ajouter le support d'un nouveau harness ?
Vous câblez, vous ne concevez pas un nouveau protocole. Un adapter de harness a besoin de deux choses : un moyen d'exécuter une commande au démarrage de session ou à la soumission d'un prompt (le push hook), et un moyen de faire en sorte que la sortie stdout de cette commande devienne du contexte. Le format maildir, la vérification d'identité et le framing sont déjà neutres vis-à-vis du harness et inchangés.
agentixmesh prendra-t-il un jour en charge Gemini CLI ou d'autres harnais ?
Des adapters Hermes et OpenClaw sont déjà conçus et prototypés — c'est la feuille de route actuelle, pas une fonctionnalité livrée. Un adapter spécifique à Gemini n'est pas confirmé séparément. Comme ajouter un harness relève du câblage plutôt que d'un nouveau travail de protocole, l'effort attendu par nouvel outil est faible, mais rien au-delà de Claude Code et Codex CLI n'est livré aujourd'hui.
« Harness-agnostic » signifie-t-il que deux outils d'agents peuvent être mélangés librement sans risque supplémentaire ?
Non — harness-agnostic décrit la couche de transport et d'identité, pas une garantie de sécurité globale. L'identité de l'expéditeur reste seulement un identifiant utilisateur OS vérifié par le kernel, pas un agent ou un projet vérifié. Quel que soit le harness qui reçoit un message, l'agent doit toujours le traiter comme une donnée inerte, jamais comme une instruction à obéir.
Quelle est la différence entre le « cœur » et un « adapter » dans agentixmesh ?
Le cœur est le transport maildir, l'identité de l'expéditeur vérifiée par le kernel, et le format de message DATA-frame — fixe et identique pour chaque harness. Un adapter est la fine colle spécifique au harness : l'enregistrement de hooks plus le câblage stdout qui connecte un outil d'agent particulier à ce cœur. Le support d'un nouveau harness se limite entièrement à l'adapter, pas au cœur.
Puis-je utiliser agentixmesh avec un harness d'agent maison, sur mesure ?
Oui, si vous pouvez implémenter les deux exigences d'adapter : un hook qui s'exécute au démarrage de session ou au moment du prompt, et un moyen d'injecter la sortie stdout de ce hook dans le contexte de l'agent. Comme le cœur du mesh est neutre vis-à-vis du harness, un harness sur mesure n'a besoin d'aucune modification de protocole — seulement le même type de câblage qu'utilisent Claude Code et Codex CLI.
L'utilisation de plusieurs harnais sur le même mesh affaiblit-elle la garantie d'identité de l'expéditeur ?
Non — la vérification d'identité se fait au niveau OS/kernel, via fstat sur le descripteur de fichier ouvert, entièrement en dessous et indépendamment de tout harness. Quel que soit l'outil par lequel un message transite, l'identifiant utilisateur OS de l'expéditeur est vérifié de la même manière infalsifiable ; le choix du harness n'a aucune incidence sur cette garantie.

Multi-utilisateur (cross-user)

Deux utilisateurs OS différents sur une machine peuvent-ils s'envoyer des messages avec agentixmesh ?
Oui — deux comptes utilisateur OS distincts sur un même hôte peuvent échanger des messages via le mode cross-user d'agentixmesh, qui route à travers un maildir partagé, possédé par un groupe, plutôt que par la boîte privée de chaque utilisateur. Ceci a été validé de bout en bout avec de vrais cycles envoi-à-livraison. Cela se comporte différemment de la messagerie same-user d'une manière clé : la livraison est retenue (held) par défaut, pas immédiate.
Comment l'expéditeur est-il vérifié quand un message traverse les frontières d'utilisateurs OS ?
De la même manière que pour les messages same-user : le kernel, pas le message lui-même. agentixmesh appelle fstat sur le descripteur de fichier ouvert pour lire l'uid propriétaire réel au niveau OS, qui ne peut pas être usurpé par quoi que ce soit que le message prétend. Ce qui n'est pas vérifié, c'est la moitié project de l'adresse — un label auto-déclaré que n'importe qui peut définir à sa guise.
Qu'est-ce que la porte humaine (human-gate), et pourquoi le corps d'un message cross-user est-il retenu ?
Un message cross-user arrive retenu (held) : l'agent récepteur ne voit que les métadonnées — uid de l'expéditeur vérifié par le kernel, longueur, id de thread, horodatage — jamais le texte du corps. Un humain doit explicitement le libérer avant que le corps n'atteigne l'agent. Cela existe parce que retenir le corps, et non simplement signaler le message, est ce qui limite réellement l'exposition au contenu injecté.
Un message cross-user peut-il jamais être auto-approuvé ou faire l'objet d'une action automatique ?
Non — c'est impossible par construction, pas un paramètre que quelqu'un aurait oublié de verrouiller. La livraison cross-user est toujours par défaut soumise à la porte humaine, et les surcharges par adresse ou par projet ne peuvent que rendre la confiance plus restrictive, jamais l'élever vers l'automatique. Il n'existe aucun chemin de code où un corps cross-user retenu atteint un agent sans une libération humaine explicite.
La messagerie cross-user est-elle prête pour la production ?
Le mécanisme est validé de bout en bout — de vrais cycles retenu, libéré par un humain, livré entre deux utilisateurs OS ont été prouvés en conditions réelles. Mais la mise en production pour un déploiement donné reste soumise à la porte humaine par conception : l'étape de rétention est permanente pour le cross-user, pas un manque de déploiement à combler plus tard. « Prêt » signifie donc sûr à faire tourner sous supervision, pas sûr à laisser sans surveillance.
Comment fonctionne la libération d'un message cross-user retenu ?
Un humain du côté récepteur examine les métadonnées du message retenu — uid de l'expéditeur, longueur, id de thread, horodatage — puis effectue une action de libération explicite qui révèle le corps à l'agent pour la première fois. Rien n'est livré avant cette étape, et le message reste retenu indéfiniment si la libération n'a jamais lieu.
Que peut voir un utilisateur OS des messages d'un autre utilisateur avant leur libération ?
Rien d'autre que des métadonnées structurelles. Le côté récepteur peut voir qu'un message existe, quel uid vérifié par le kernel l'a envoyé, sa longueur, et à quel thread il appartient — jamais le texte. C'est délibéré : les métadonnées seules ne peuvent porter aucune instruction, donc les afficher avant la revue humaine ne rouvre pas la surface d'injection que la rétention existe pour fermer.
Comment un collègue est-il intégré (onboardé) pour envoyer ou recevoir des messages cross-user ?
L'onboarding est une étape d'enrôlement dédiée, pas juste la création d'un compte OS sur la machine. Un nouveau membre est enregistré de sorte que son uid vérifié par le kernel soit reconnu comme un participant légitime du mesh, avec une identité confirmée hors bande plutôt que prise sur une déclaration auto-rapportée. Tant qu'il n'est pas enrôlé, les messages provenant de cet uid ne sont pas traités comme venant d'un membre connu.
Que se passe-t-il quand un collègue part ou perd l'accès ?
Son appartenance au mesh est révoquée, ce qui empêche les futurs messages de cet uid d'être traités comme provenant d'un membre reconnu. La révocation est une action administrative explicite liée à l'identité au niveau OS, pas une bascule qu'un agent ou un message peut demander — cohérent avec le reste d'agentixmesh, où les changements de confiance sont des actions humaines délibérées.
Les deux utilisateurs doivent-ils être sur la même machine ?
Oui — le mode cross-user d'agentixmesh est réservé à une seule machine. Il repose sur un système de fichiers local et une vérification d'uid au niveau du kernel, deux concepts locaux à l'hôte sans signification entre machines séparées. La messagerie entre agents sur des hôtes différents n'est pas quelque chose qu'agentixmesh fait aujourd'hui ; c'est ce pour quoi AgentsWeaver, le membre cross-machine, signé cryptographiquement, de la même famille, est construit.
Un utilisateur malveillant peut-il se faire passer pour un projet différent pour tromper l'agent d'un collègue ?
Il peut falsifier le label de projet, pas l'expéditeur. La moitié project d'une adresse est une chaîne auto-déclarée — le basename du cwd de l'expéditeur lui-même — et n'est pas vérifiée, donc un message peut arriver étiqueté comme s'il venait d'un projet sans rapport. L'uid dont il provient réellement reste vérifié par le kernel : vous savez toujours quel utilisateur OS l'a envoyé, simplement pas lequel de ses projets.
Existe-t-il un rôle de leader ou d'approbateur pouvant co-approuver les messages cross-user pour une équipe ?
Une couche à plus haute autorité — co-approbation leader-gate et rôles de groupe — existe dans la conception mais relève de la feuille de route, pas d'une sécurité de production livrée ; ne vous y fiez pas aujourd'hui. Le contrôle qui est en direct (live) et déterminant pour le cross-user est la porte de libération humaine par message : chaque message cross-user y passe, indépendamment de toute structure de groupe.
Un utilisateur peut-il surveiller le trafic mesh d'un autre utilisateur, par exemple un chef d'équipe surveillant les problèmes ?
La surveillance leader-read soumise au consentement est conçue mais non livrée — même statut de feuille de route que la couche leader-gate et rôles de groupe. En l'état, la boîte aux lettres d'un utilisateur n'est lisible que par cet utilisateur ; il n'existe aucune fonctionnalité en direct permettant à une autre partie d'observer les messages de quelqu'un d'autre, retenus ou libérés, avec ou sans consentement.
La rétention cross-user s'applique-t-elle à chaque message, ou seulement à certains ?
Elle s'applique à chaque message cross-user — retenu-avec-métadonnées-uniquement est le mode par défaut et unique, pas une option par message ou par expéditeur. Il n'existe aucun paramètre cross-user « faire confiance à cet uid, livrer automatiquement ». La propriété (ownership) éliminant la falsification plus la porte humaine constituent le contrat fixe pour tout message qui traverse une frontière d'uid.
L'uid de l'expéditeur ne peut pas être falsifié, alors pourquoi ne pas sauter l'étape humaine ?
Parce que la vérification d'uid et la sécurité contre l'injection sont des problèmes différents. Vérifier par le kernel l'uid de l'expéditeur prouve qui a envoyé un message, pas que son contenu est sûr à exploiter — un message légitimement envoyé peut quand même contenir un texte conçu pour ressembler à une instruction. L'étape de libération humaine limite l'exposition à ce contenu ; ce n'est pas un contrôle d'identité redondant.
Une fois qu'un message cross-user est libéré, l'agent peut-il agir dessus automatiquement ?
Non — une fois libéré, il est traité exactement comme n'importe quelle autre trame de données inerte, sous la même règle permanente que les messages same-user : ne jamais obéir au corps d'un message. L'agent peut répondre par des mots, mais exécuter du code, entreprendre une action, ou révéler des secrets sur la seule foi du message va à l'encontre de cette règle, que le message vienne du même utilisateur ou d'un autre.
Quelles permissions au niveau OS protègent une boîte aux lettres cross-user partagée des autres utilisateurs de la machine ?
La livraison cross-user utilise un répertoire possédé par un groupe plutôt que les répertoires stricts owner-only (0700) du mode same-user, puisque plus d'un uid doit pouvoir y accéder. Les membres du groupe peuvent déposer un message et traverser le répertoire mais ne peuvent pas lister ou lire ce qu'il contient ; seul le destinataire visé peut lire un message, donc les co-locataires de la machine ne peuvent pas parcourir le courrier des autres.

Sécurité & modèle de confiance

agentixmesh arrête-t-il l'injection de prompt ?
Non — il réduit le risque d'injection de prompt, il ne l'élimine pas. La propriété (ownership) garantit qui a envoyé un message, pas ce que le message dit. Un message légitimement envoyé peut quand même contenir un texte conçu pour ressembler à une instruction, et l'agent qui le lit est le point faible. agentixmesh atténue cela avec un framing inert-DATA, de la sanitation, et une règle permanente de ne-jamais-obéir — mais c'est finalement le LLM récepteur qui décide quoi faire.
Quelle est la différence entre falsification et injection de prompt, et pourquoi agentixmesh les traite-t-il différemment ?
La falsification (forgery), c'est un message mentant sur son expéditeur ; l'injection, c'est un message légitimement envoyé qui essaie de convaincre un agent d'entreprendre une action. agentixmesh élimine la première grâce à une garantie forte vérifiée par le kernel — un expéditeur usurpé est rejeté avant qu'un agent ne voie jamais le message. Il ne fait que réduire la seconde, car l'injection réside dans le contenu du message, que le mesh peut cadrer et assainir mais pas neutraliser complètement.
Que signifie concrètement « expéditeur vérifié par le kernel » (kernel-verified sender) ?
Cela signifie que l'identifiant utilisateur OS de l'expéditeur est lu via fstat sur le descripteur de fichier ouvert du message livré, pas depuis un champ quelconque à l'intérieur du message lui-même. Le kernel suit la propriété des fichiers indépendamment du contenu du message, donc un expéditeur ne peut pas prétendre être un utilisateur différent — l'OS devrait mentir sur qui possède le fichier qu'il vient d'écrire, ce qu'il ne fait pas.
Quelqu'un peut-il falsifier l'expéditeur d'un message ?
Non — l'identité de l'expéditeur est une garantie forte, appliquée par le kernel, pas une convention que l'expéditeur peut outrepasser. Comme l'uid provient des propres métadonnées de propriété de fichier du système d'exploitation plutôt que d'un champ auto-rapporté, un processus s'exécutant en tant qu'un utilisateur ne peut pas faire apparaître un message comme provenant d'un autre utilisateur. C'est la seule partie du modèle de confiance qui n'est pas probabiliste.
La moitié « project » d'une adresse uid:project est-elle fiable ?
Non — le label de projet est auto-déclaré (c'est simplement le basename du répertoire de travail de l'expéditeur) et n'est pas vérifié. agentixmesh prouve quel utilisateur OS a envoyé un message, pas quel agent, dépôt, ou projet l'a envoyé. Traitez la moitié project de toute adresse comme un indice de routage, jamais comme une affirmation de sécurité — deux agents exécutés par le même utilisateur peuvent tous deux revendiquer n'importe quel nom de projet à leur guise.
Un message d'un autre agent peut-il faire exécuter une commande ou fuiter un secret à mon agent ?
Aucun message ne peut forcer une action — agentixmesh ne fait que livrer des données dans le contexte ; il n'exécute jamais rien au nom de l'expéditeur. Qu'un agent exécute une commande ou révèle un secret dépend entièrement de la propre prise de décision de cet agent et de ses permissions d'outils. Le travail du mesh est de remettre à l'agent récepteur un texte inerte et une règle de le traiter comme donnée, pas d'octroyer ou d'exercer la moindre capacité.
Qu'est-ce qu'une « trame DATA inerte » (inert DATA frame) ?
C'est la façon dont un message entrant est présenté à l'agent récepteur : clairement délimité comme donnée à lire, jamais comme commande à obéir. Le framing s'accompagne d'une règle permanente selon laquelle la seule parole du corps d'un message n'autorise rien — répondre par des mots est acceptable, mais entreprendre une action, exécuter du code, ou révéler un secret sur instruction d'un message ne l'est pas. C'est l'agent, pas le mesh, qui décide de la suite.
Quelle sanitation agentixmesh applique-t-il aux messages entrants ?
Avant qu'un message n'atteigne le contexte d'un agent, agentixmesh retire les constructions couramment utilisées pour déguiser des instructions en sortie de confiance — des choses comme les caractères de contrôle, les caractères invisibles/zero-width, et les motifs de texte imitant le début d'un nouveau tour conversationnel. Cela réduit la surface d'injection mais reste une atténuation, pas un filtre capable d'attraper toutes les formulations possibles d'un message manipulateur.
Existe-t-il une protection contre les messages rejoués ou dupliqués ?
Oui — les messages livrés sont suivis afin que le même message ne soit pas réinjecté dans le contexte d'un agent lors d'un sondage (poll) ultérieur. Cela protège contre le fait qu'un message soit silencieusement re-livré et relu comme s'il était nouveau, ce qui compte car une exposition répétée au même texte conçu est elle-même une manière de faire pression sur un agent. C'est un contrôle d'hygiène de livraison, pas une défense contre une première tentative d'injection.
Quel est le modèle de menace d'agentixmesh ?
Des collègues de confiance partageant une machine, pas un adversaire root hostile. La conception suppose que les utilisateurs OS participants n'attaquent pas activement le kernel ou les permissions de fichiers de l'hôte pour s'usurper mutuellement — si un utilisateur a un accès de niveau root, il peut déjouer presque tout mécanisme de confiance local. Dans le cadre de cette hypothèse, la garantie anti-falsification d'agentixmesh tient ; elle n'est pas conçue pour survivre à un administrateur système malveillant ou un kernel compromis.
agentixmesh est-il un produit de sécurité ?
Non — c'est une frontière de confiance (trust boundary) pour la livraison de messages, pas un produit de sécurité au sens large. Il répond de façon fiable à une question étroite (qui a envoyé ce message) et aide partiellement sur un problème plus large (ne pas laisser le contenu du message détourner un agent). Il ne remplace pas le durcissement des postes, la gestion des secrets, ou le propre périmètre de permissions d'un agent — cela reste la responsabilité de l'opérateur.
Que ne résout PAS la propriété de fichier (file ownership) ?
La propriété résout qui a envoyé un message ; elle ne résout pas ce que dit un message ni comment un agent y réagit. Elle n'empêche pas un message légitimement envoyé de contenir un texte manipulateur, ne vérifie pas la sécurité du contenu d'un message, et ne contraint pas ce qu'un agent récepteur est capable de faire — c'est une fonction des propres permissions d'outils de l'agent, pas du mesh.
Si mon agent obéit à une instruction malveillante intégrée dans le corps d'un message, est-ce un bug d'agentixmesh ?
Non — c'est l'agent récepteur qui échoue à respecter la règle ne-jamais-obéir-au-corps-d'un-message, ce qui est exactement le risque résiduel qu'agentixmesh assume ouvertement. Le mesh livre le message cadré comme donnée inerte et ne peut pas forcer un LLM à respecter ce cadrage. Réduire davantage ce mode d'échec est un problème de discipline de modèle/prompt côté récepteur, pas quelque chose qu'une couche de livraison peut corriger seule.
agentixmesh authentifie-t-il l'agent ou le harness qui envoie un message ?
Ni l'un ni l'autre — il authentifie l'utilisateur OS sous lequel le processus expéditeur s'exécute, rien de plus. Il ne peut pas distinguer Claude Code d'un autre harness, ni un processus d'agent d'un second exécuté par la même personne. Si vous devez savoir quel agent ou outil spécifique a envoyé quelque chose, cela doit venir du contexte ou de la convention, pas de la garantie d'identité d'agentixmesh.
La messagerie cross-user (utilisateurs OS distincts, même machine) est-elle sûre à utiliser aujourd'hui ?
Elle est validée de bout en bout mais sa mise en production est intentionnellement soumise à la porte humaine, ce n'est pas quelque chose à considérer comme généralement disponible pour l'instant. Le corps d'un message cross-user est retenu jusqu'à ce qu'un humain le libère, et l'action automatique cross-user est impossible par construction — cette porte est le mécanisme de sécurité, pas une formalité. Considérez le cross-user comme une capacité revue mais toujours en attente d'une décision de déploiement délibérée.
Un message peut-il déclencher automatiquement une action sans aucune revue ?
Non — la livraison ne fait que placer un message dans le contexte d'un agent ; rien dans agentixmesh n'exécute quoi que ce soit au nom d'un message. Au sein des propres sessions d'un utilisateur, l'agent qui lit un message décide quoi faire ensuite sous la règle ne-jamais-obéir. Entre utilisateurs, la porte de libération humaine ajoutée signifie qu'un corps n'est même pas visible avant qu'une personne ne le laisse passer, ce qui exclut toute action automatique par construction.
Existe-t-il une piste d'audit persistante de chaque message ?
Pas comme garantie de production livrée dans le cœur same-user — la partie fiable est le garde anti-rejeu empêchant la re-livraison, pas un journal inviolable. La surveillance soumise au consentement d'une autre boîte aux lettres (leader-read) existe par conception pour la strate cross-user mais relève de la feuille de route, pas de quelque chose annoncé aujourd'hui comme une fonctionnalité de sécurité ou de conformité de production.

Isolation & frontières

Qu'identifie réellement une adresse uid:project ?
Deux choses différentes avec deux garanties différentes. L'uid est l'utilisateur OS, vérifié par le kernel via fstat côté réception, donc digne de confiance. La moitié project est le basename du répertoire de travail de l'expéditeur lui-même, auto-déclaré et non vérifié — traitez-le comme un contexte informatif, pas comme une preuve de la provenance d'un message.
La moitié project d'une adresse est-elle un identifiant stable et unique ?
Non. Ce n'est que le basename du répertoire de travail que la session expéditrice a alors. Rien ne l'enregistre ni n'impose une unicité sur une machine. Deux dossiers sans rapport qui partagent un nom produisent l'adresse identique, sans autorité centrale vérifiant les collisions avant la livraison.
Comment les boîtes aux lettres sont-elles isolées entre projets ?
Chaque adresse obtient son propre répertoire maildir créé owner-only (0700), lisible uniquement par l'utilisateur OS qui le possède. L'isolation est appliquée par les permissions du système de fichiers, pas par une logique au niveau applicatif — un processus s'exécutant en tant qu'un autre utilisateur OS ne peut pas du tout ouvrir le répertoire, quoi qu'il tente.
Un projet peut-il lire ou agir sur la boîte de réception d'un autre projet ?
Non, entre utilisateurs OS — la livraison est par adresse, et un message n'atterrit que dans le maildir correspondant à sa destination uid:project. Un message ne porte non plus aucune autorité : en recevoir un n'accorde jamais à une session la capacité d'atteindre une autre boîte de réception, d'agir au nom d'un pair, ou de déclencher quoi que ce soit automatiquement.
Si mon utilisateur OS fait tourner plusieurs projets d'agents différents, peuvent-ils lire le courrier les uns des autres ?
L'isolation est appliquée par utilisateur OS, pas par projet, puisque la propriété du maildir est fixée au niveau de l'uid. Un processus s'exécutant sous ce même uid peut, en principe, ouvrir n'importe quel maildir que cet uid possède. Le label de projet ne fait que sélectionner une adresse de livraison — ce n'est pas une frontière de permission séparée au sein d'un même utilisateur.
Un message peut-il usurper le projet depuis lequel il a été envoyé ?
Oui — le label de projet est auto-déclaré et non vérifié cryptographiquement, donc un expéditeur peut mettre n'importe quelle chaîne dans cette moitié de l'adresse. Ce qui ne peut pas être usurpé, c'est l'uid : l'identité de l'expéditeur vérifiée par le kernel indique quel utilisateur OS a réellement envoyé le message, indépendamment du nom de projet revendiqué.
Que se passe-t-il si je fais une faute de frappe dans une adresse et qu'elle correspond par hasard à un autre projet réel ?
Le message y est livré, silencieusement. Il n'existe aucune étape de confirmation vérifiant si la destination saisie est bien celle voulue, donc une faute de frappe qui entre en collision avec une autre adresse active route simplement votre message dans la boîte de réception de cette session à la place — sans que rien ne signale à l'une ou l'autre partie qu'une erreur s'est produite.
Que se passe-t-il si j'adresse un projet qui n'existe pas ou ne tourne pas ?
Le message est écrit dans cette boîte aux lettres et attend — il n'existe aucun registre d'adresses actives auquel se référer, donc envoyer à un uid:project inexistant ou actuellement inactif ne produit aucune erreur. Il ne devient lisible que si et quand une session avec exactement cette adresse consulte plus tard sa boîte aux lettres.
Comment trouver ma propre adresse mesh ?
Exécutez mesh-whoami — il affiche votre adresse uid:project exactement telle que d'autres sessions devraient la saisir pour vous joindre, dérivée en direct de votre uid OS et du basename de votre répertoire de travail courant. Utilisez-le plutôt que de reconstruire l'adresse de mémoire, car la moitié project dépend du cwd et peut dériver.
Comment joindre une autre session sans taper ou deviner son adresse exacte ?
Utilisez le carnet d'adresses côté expéditeur — une liste d'alias conviviaux que vous maintenez localement et qui associe des noms mémorables à des adresses uid:project complètes, afin de ne pas avoir à mémoriser ou retaper un basename exact à chaque fois. Cela n'affecte que la façon dont vous désignez une destination ; cela ne change pas la façon dont le destinataire est adressé.
agentixmesh découvre-t-il automatiquement d'autres projets sur la machine et les relie-t-il pour moi ?
Non. Il n'y a aucune auto-découverte, aucun répertoire de projets actifs, et aucune connexion automatique de sessions. Chaque message va vers une seule adresse uid:project spécifique qu'un expéditeur fournit explicitement. L'isolation est l'état par défaut ; une frontière n'est franchie que parce que quelqu'un a nommé cette destination exacte intentionnellement.
Puisque le label de projet n'est pas fiable, sur quoi dois-je réellement m'appuyer pour les garanties d'isolation ?
Appuyez-vous sur la frontière de l'uid. agentixmesh garantit que les boîtes aux lettres ne sont lisibles que par leur utilisateur OS propriétaire et garantit que vous savez quel utilisateur OS a envoyé un message entrant. Il ne garantit pas que le projet expéditeur revendiqué est exact — traitez tout nom de projet à l'intérieur ou attaché à un message comme un contexte, jamais comme un contrôle d'accès.
Deux répertoires différents portant le même basename peuvent-ils entrer en collision sur une seule adresse ?
Oui. L'adressage n'utilise que le basename du répertoire de travail, donc deux dossiers partageant un nom — par exemple le checkout principal d'un projet et une copie ou un checkout séparé ailleurs — se résolvent en l'adresse uid:project identique et partagent silencieusement une seule boîte de réception, sans aucun avertissement à l'envoi ou à la réception.
Dois-je enregistrer un projet avant qu'il puisse recevoir des messages mesh ?
Il n'existe aucune étape d'inscription. L'adresse d'un projet existe implicitement dès l'instant où quelque chose s'exécutant sous cet utilisateur OS, depuis un répertoire portant ce basename, consulte sa boîte aux lettres. Envoyer à une adresse qui n'a jamais été « créée » écrit simplement le message dans un maildir, qui devient lisible dès qu'une session correspondante le consulte ultérieurement.
L'isolation des boîtes aux lettres est-elle appliquée par le propre code d'agentixmesh, ou par le système d'exploitation ?
Par le système d'exploitation. Les répertoires de boîte aux lettres sont créés owner-only (0700), donc la garantie d'isolation provient des permissions standard du système de fichiers Unix plutôt que d'une vérification au niveau applicatif qu'agentixmesh pourrait mal implémenter. C'est aussi pourquoi cela tient face à un processus d'agent bogué ou malveillant — le kernel refuse l'open() avant que le moindre code du mesh ne s'exécute.

Coût & tokens

Vérifier le mesh pour de nouveaux messages coûte-t-il des tokens LLM ?
Non. Vérifier le mesh est une simple lecture de fichier sur votre maildir local, pas un appel LLM, donc cela coûte zéro token. La fréquence de sondage (polling) ne change rien à cela — `mesh-poll status` et la vérification automatique de l'inject-hook au démarrage de session sont des opérations sur le système de fichiers. Vous contrôlez si cette vérification s'exécute même via `mesh-poll on/off/status`.
Quand un message mesh coûte-t-il réellement des tokens ?
Seulement quand il est livré dans le contexte d'un agent pour qu'il le lise. Un message en attente dans un maildir ne coûte rien ; le coût apparaît au moment où son texte est rendu sous forme de trame DATA dans la conversation, et cette livraison est communiquée à l'agent — ce n'est pas une charge d'arrière-plan cachée.
Un message qui reste en file d'attente ou retenu en attendant sa libération coûte-t-il des tokens ?
Non. Retenir ou mettre en file un message, c'est un fichier posé sur disque dans le répertoire `held` (ou `new`) ; rien ne le lit dans le contexte d'un agent avant la libération, donc il n'accumule aucun coût en tokens. Le coût ne commence qu'une fois le message réellement livré et lu — la durée de mise en attente n'a aucune incidence sur la dépense.
Transmettre un message mesh vers un canal humain, comme un téléphone, coûte-t-il des tokens LLM ?
Non. Transmettre vers un canal humain — par exemple relayer une notification vers un téléphone — est une simple opération de passage de message, pas un appel LLM, donc cela n'entraîne aucun coût en tokens LLM. Le coût en tokens est spécifiquement lié au fait qu'un agent lise du contenu dans son propre contexte, pas au déplacement de texte entre canaux de livraison.
agentixmesh est-il gratuit à utiliser ?
Il n'y a aucun frais par message et aucun coût en tokens pour sonder ou vérifier le mesh — cette partie est gratuite. « Gratuit » signifie ici gratuit en tokens LLM : agentixmesh lui-même ne facture rien. Ce qui n'est pas gratuit, c'est la session d'agent sous-jacente — l'hébergement et le calcul pour faire tourner les agents qui envoient et reçoivent sont un coût séparé que vous payez déjà.
agentixmesh est-il open source ?
Oui. Il est sous licence MIT et publié sur GitHub (github.com/TokonoMix/agentixmesh). Vous pouvez lire vous-même le code de transport, de vérification d'identité et de livraison plutôt que de prendre les affirmations de coût ou de sécurité pour argent comptant — il n'y a aucun composant fermé qui médiatise la livraison des messages ou mesure l'usage.
Ai-je besoin d'une clé API ou d'un abonnement pour utiliser le mesh lui-même ?
Non. Le mesh, ce sont des fichiers locaux — un maildir plus un inject hook — sans daemon, écouteur réseau, ou service externe auprès duquel s'authentifier, donc il n'y a rien à cléer ou à abonner pour la couche mesh. Le seul coût que vous verrez est l'usage du modèle de votre propre agent quand il lit un message livré.
Puis-je limiter ou couper la dépense en tokens due à la livraison mesh ?
Oui, avec `mesh-poll off`. Couper le sondage empêche l'inject hook de vérifier ou de livrer de nouveaux messages dans votre contexte, donc rien n'est lu et aucun token n'est dépensé sur le contenu mesh. `mesh-poll status` montre l'état actuel ; `mesh-poll on` réactive la livraison quand vous le souhaitez.
Envoyer un message avec mesh-send coûte-t-il des tokens ?
Écrire un message avec `mesh-send` est une écriture de fichier dans le maildir du destinataire, pas une opération LLM, donc l'acte d'envoyer n'ajoute aucun token au-delà de ce que votre agent a déjà dépensé pour composer le texte qu'il voulait envoyer. Il n'y a aucun frais côté mesh superposé à cette écriture.
L'inject hook automatique qui s'exécute au démarrage de session dépense-t-il silencieusement des tokens à chaque tour ?
Non, pas à moins qu'il n'y ait réellement un message à livrer. La vérification du nouveau courrier par le hook est une lecture de fichier ; si le maildir est vide, rien n'est ajouté au contexte et aucun token n'est dépensé. Des tokens ne sont dépensés que sur les tours où un message en attente est réellement rendu dans la conversation.
Si je ne lis jamais un message retenu ou en attente, dois-je quand même le payer ?
Non. Un message non lu — qu'il soit dans `new`, `held`, ou jamais réclamé — n'est jamais tokenisé dans le contexte d'un agent, donc il ne coûte rien. Le coût est strictement lié à l'acte d'un agent lisant du contenu livré, pas à la simple existence d'un message dans une boîte aux lettres.

Comparaisons

En quoi agentixmesh diffère-t-il d'une file de messages (message queue) comme Redis ou RabbitMQ ?
Une file déplace des octets entre points de terminaison ; elle ne connaît ni ne vérifie qui les a envoyés. agentixmesh vérifie par le kernel l'utilisateur OS de l'expéditeur via fstat sur le descripteur de fichier ouvert avant que l'agent récepteur ne voie jamais le message, donc un message de file prétendant venir de « l'utilisateur X » peut être falsifié — un message agentixmesh ne peut pas l'être. Cette garantie d'identité est l'essentiel ; une file ne la fournit pas.
Pourrais-je construire la même chose avec Redis pub/sub ou une table de base de données ?
Vous pourriez déplacer les octets, mais vous devriez ajouter vous-même une vérification de l'expéditeur — Redis et une table BD partagée font confiance à tout client qui y écrit. La garantie d'agentixmesh vient de l'OS : seul le véritable uid qui a ouvert le descripteur de fichier peut être l'expéditeur enregistré. Réimplémenter cela sur une file signifie redériver des vérifications d'identité au niveau kernel, ce qui constitue l'essentiel de la difficulté.
agentixmesh offre-t-il des garanties de livraison ou d'ordonnancement comme une véritable file de messages ?
Pas de la manière dont un produit de file le fait — aucune mécanique d'acks-avec-retries-et-DLQ, aucune garantie d'ordonnancement inter-expéditeurs. C'est un maildir : les messages atterrissent dans new/, passent à cur/ à la lecture, held/ pour les cas soumis à une porte. C'est délibérément simple. Si vous avez besoin d'un débit, d'un ordonnancement, ou d'une contre-pression de niveau broker, agentixmesh n'est pas cet outil — c'est une couche de confiance, pas un produit de file.
Quel est le rapport entre agentixmesh et MCP (Model Context Protocol) ?
Une couche différente. MCP connecte une session d'agent à des outils et ressources — bases de données, API, fichiers — qu'elle appelle. agentixmesh connecte une session d'agent à une autre session d'agent, afin qu'elles puissent échanger des messages sans que l'une n'hérite de l'autorité de l'autre. Une session peut utiliser des serveurs MCP pour les outils et agentixmesh pour parler à des agents pairs — ils sont complémentaires, pas concurrents.
Puis-je utiliser agentixmesh et MCP ensemble ?
Oui — ils résolvent des problèmes différents et ne se heurtent pas. Une session Claude Code peut avoir des serveurs MCP câblés pour l'accès à des outils, comme une base de données ou une API de recherche, et recevoir séparément des messages agentixmesh d'une autre session travaillant sur une tâche connexe. MCP gouverne le bord agent-vers-outil du contexte ; agentixmesh gouverne le bord agent-vers-agent. Rien dans l'un ne requiert ou ne bloque l'autre.
Comment agentixmesh se compare-t-il à A2A ou d'autres protocoles agent-à-agent visant la communication cross-machine ?
C'est une différence de positionnement, pas un manque de fonctionnalité : agentixmesh est mono-machine, basé sur des fichiers, avec une identité d'expéditeur vérifiée par le kernel — il ne fait pas de transport cross-machine, de TLS, ni de signature cryptographique entre hôtes. Les protocoles conçus pour des agents sur des machines séparées résolvent la confiance au niveau réseau, un problème différent de la confiance locale au niveau descripteur de fichier. La communication d'agents cross-machine, signée, relève de la feuille de route pour nous (AgentsWeaver), pas de ce que fait agentixmesh aujourd'hui.
Pourquoi ne pas simplement faire lire et écrire un fichier ou une base de données partagée par les agents ?
Un fichier ou une BD partagée n'a aucune notion de qui a écrit une ligne donnée au-delà de ce que prétend l'auteur — tout processus ayant accès en écriture peut falsifier un champ expéditeur. Le maildir d'agentixmesh est owner-only (0700, même utilisateur), et l'expéditeur est dérivé de l'uid vérifié par le kernel du processus qui a ouvert le fichier, pas d'une colonne auto-déclarée. Le stockage partagé vous donne des octets, pas de la provenance.
Qu'est-ce qui ne va pas avec un répertoire de scratch partagé que deux agents sondent tous deux pour des changements ?
Rien n'empêche un agent, un bug, ou une instruction injectée d'écrire un fichier qui usurpe un autre expéditeur — un simple répertoire partagé n'a aucun contrôle d'identité. agentixmesh ajoute exactement cela : un expéditeur vérifié par le kernel par message, plus un framing inert-DATA afin qu'un message reçu soit lu, pas auto-obéi. Un répertoire de scratch ne vous donne ni l'une ni l'autre de ces garanties.
Pourquoi ne pas simplement laisser la sortie d'un agent devenir directement le prompt d'un autre agent ?
C'est exactement le risque de confused-deputy/injection qu'agentixmesh existe pour atténuer. Injecter directement la sortie brute d'un agent dans le prompt d'un autre lui donne la même autorité qu'une instruction directe, y compris tout ce qui a été glissé dans cette sortie. agentixmesh livre à la place les messages sous forme de trame DATA inerte que l'agent récepteur lit mais n'exécute jamais automatiquement ; répondre par des mots est acceptable, agir sur la seule foi d'un message ne l'est pas.
Cadrer les messages comme des données inertes n'ajoute-t-il pas de la friction par rapport à simplement prompter directement l'autre agent ?
Un peu, oui, et c'est délibéré. Le prompting direct fusionne « texte reçu » et « instruction à suivre » en une seule chose, ce qui est exactement le mode d'échec du confused-deputy. agentixmesh les garde séparés : la trame est sans ambiguïté une donnée, et c'est l'agent récepteur — pas le message — qui décide si et comment agir. C'est le coût de ne pas être trivialement injectable.
En quoi est-ce différent de relier deux agents via Slack ou un canal de chat ?
Un pont de chat vous donne une salle partagée où quiconque détient les identifiants peut poster en son propre nom — utile pour les humains, mais cela ne vérifie pas au niveau OS quel processus a envoyé un message, et il n'y a aucun cadrage intégré « ceci est une donnée, pas une commande ». La garantie d'identité d'agentixmesh est dérivée du kernel (fstat sur le propre descripteur de fichier ouvert de l'expéditeur), et la livraison est par défaut cadrée comme inerte plutôt qu'un flux en direct qu'un agent pourrait lire comme des instructions.
Où se situe agentixmesh par rapport à AgentsWeaver et Tokonomix ?
Ce sont trois couches d'une même famille, pas des concurrents. agentixmesh est la rampe d'accès locale, mono-machine — basée sur des fichiers, identité vérifiée par le kernel, un seul hôte. AgentsWeaver est le passage à l'échelle cross-machine, signé cryptographiquement, pour quand les agents s'étendent sur plusieurs hôtes. Tokonomix est le consensus LLM cross-fournisseur — router une question vers plusieurs modèles et juger les réponses. Des problèmes différents, la même approche axée sur la confiance.
Quand dépasserais-je les capacités d'agentixmesh et aurais-je besoin de quelque chose comme AgentsWeaver ?
Quand vos sessions d'agents cessent de vivre sur une seule machine. La garantie d'identité d'agentixmesh est enracinée dans une primitive kernel locale — fstat sur un descripteur de fichier ouvert — qui n'a aucune réponse pour prouver qu'un message vient d'un hôte différent ; cela nécessite une signature cryptographique au niveau réseau, le problème qu'AgentsWeaver cible. Plusieurs utilisateurs OS sur une seule machine reste le territoire d'agentixmesh (mode cross-user), simplement soumis à la porte humaine.
Tokonomix est-il un remplacement d'agentixmesh ?
Non — un travail différent. Tokonomix répond à « cette sortie est-elle bonne ? » en envoyant une question à plusieurs fournisseurs LLM et en synthétisant une réponse jugée. agentixmesh répond à « puis-je faire confiance à celui qui m'a envoyé ce message ? » entre sessions d'agents. Ils peuvent être utilisés côte à côte dans le même workflow, mais ni l'un ni l'autre ne se substitue à l'autre.
agentixmesh est-il un remplacement pour des frameworks d'orchestration comme LangGraph ou CrewAI ?
Non — les frameworks d'orchestration décident ce qu'un agent fait ensuite au sein d'un même processus ou workflow ; agentixmesh déplace des messages dignes de confiance entre des sessions ou processus d'agents séparés qui ne partagent ni mémoire ni autorité. Une session peut faire tourner un framework d'orchestration en interne et aussi envoyer et recevoir via agentixmesh — ils opèrent à des couches différentes et se chevauchent peu.
En quoi agentixmesh diffère-t-il de MCP (Model Context Protocol) ?
Ils se situent à des couches différentes. MCP relie un modèle à ses outils et à son contexte — l'agent invoque des capacités délibérément, comme ses propres actions. agentixmesh est la frontière de confiance entre des sessions d'agents déjà en cours d'exécution : l'identifiant d'utilisateur OS de l'expéditeur est vérifié par le noyau et le contenu arrive comme des données inertes, jamais comme une instruction que l'agent devrait suivre. Adjacents, non concurrents — la page agentixmesh vs MCP présente la comparaison complète.
agentixmesh et MCP peuvent-ils fonctionner côte à côte ?
Oui — c'est l'installation attendue. Chaque session garde ses propres serveurs MCP pour les capacités, tandis qu'agentixmesh transporte les messages entre les sessions. Le mesh livre une demande comme des données ; que l'agent agisse ou non reste une décision prise dans la session réceptrice, sous ses propres permissions.

Installation, limites & feuille de route

agentixmesh nécessite-t-il un daemon d'arrière-plan ou un processus serveur ?
Aucun daemon. La livraison same-user tourne sur un maildir (dossiers new/cur/held/seen) plus un inject hook qui se déclenche au démarrage d'une session d'agent ou à la soumission d'un prompt — rien n'a besoin de tourner en continu en arrière-plan. Il n'y a aucun processus persistant à faire planter, redémarrer, ou surveiller pour le chemin same-user central.
agentixmesh ouvre-t-il un port réseau ?
Non. Il n'a aucun écouteur réseau d'aucune sorte — la messagerie same-user est de la simple E/S de système de fichiers : un message est écrit dans un répertoire maildir et récupéré par l'inject hook au prochain événement de session. Il n'y a aucun socket à ouvrir, aucun port à autoriser dans un pare-feu, rien qui écoute des connexions.
Ai-je besoin de sudo ou de root pour utiliser agentixmesh ?
Non, pas pour le cœur same-user. Les boîtes aux lettres sont des répertoires owner-only (mode 0700) qu'un compte utilisateur normal crée et lit lui-même. Root ne devient pertinent que si vous allez jusqu'à provisionner la configuration hôte partagée optionnelle de la couche cross-user — la messagerie same-user quotidienne ne touche jamais à sudo.
De quoi un hôte a-t-il besoin pour faire tourner agentixmesh ?
Juste une machine, un système de fichiers dans lequel le compte utilisateur peut écrire, Python, et un maildir vivant sous le répertoire personnel de cet utilisateur. L'autre élément est un inject hook câblé dans votre harness d'agent afin que les messages entrants soient rendus dans le contexte d'une session — aucune infrastructure exotique au-delà de cela.
Comment installer agentixmesh ?
Câblez quatre points d'intégration hôte : une entrée de chemin Python pour que le package soit importable, des wrappers CLI (comme `mesh-send`) sur votre PATH, un fichier skill que votre harness d'agent charge, et un inject hook qui se déclenche au démarrage de session et à la soumission de prompt. C'est open source sur GitHub (github.com/TokonoMix/agentixmesh, MIT), donc vous le clonez et exécutez vous-même les étapes d'installation.
agentixmesh est-il auto-hébergeable (self-hostable) ?
Oui — il est uniquement auto-hébergé. Il n'existe aucun service hébergé ou backend SaaS ; agentixmesh, ce sont des fichiers locaux (un maildir) plus un hook que vous installez dans votre propre harness d'agent sur votre propre machine. Vous contrôlez le transport de bout en bout, et aucune donnée de message ne quitte votre hôte.
Que se passe-t-il si je n'installe jamais l'inject hook ?
Les messages restent simplement non livrés dans le maildir. Le hook est ce qui rend un nouveau message dans le contexte d'une session d'agent au démarrage de session ou à la soumission d'un prompt — sans lui, l'envoi fonctionne toujours et les messages s'accumulent en file, mais rien ne les fait remonter à l'agent récepteur tant que le hook ne s'exécute pas.
agentixmesh est-il limité à une seule machine ?
Oui — aujourd'hui agentixmesh ne livre qu'entre sessions d'agents sur la même machine. Il n'y a aucun transport réseau, donc il ne peut pas router un message vers une session tournant sur un hôte différent. La livraison cross-machine est un besoin réel et distinct qu'il ne traite pas actuellement.
agentixmesh prendra-t-il en charge la livraison cross-machine ?
C'est sur la feuille de route, pas livré aujourd'hui. Le cœur d'agentixmesh est réservé à une seule machine, sans transport réseau intégré. La livraison cross-machine, signée cryptographiquement, à l'échelle, est le travail explicite d'un projet frère, AgentsWeaver — agentixmesh est positionné comme la rampe d'accès locale, mono-machine, pas le transport cross-réseau mis à l'échelle.
Qu'est-ce que la « couche à plus haute autorité » (higher-authority layer) sur la feuille de route ?
La co-approbation leader-gate, les rôles de groupe, et la surveillance leader-read soumise au consentement — des mécanismes permettant à un chef d'équipe de co-approuver ou d'observer le trafic d'agents avec consentement. Ils existent aujourd'hui sous forme de conception/prototype mais ne sont pas livrés et ne sont explicitement pas présentés comme de la sécurité de production ; considérez-les comme de la feuille de route, pas une garantie durcie.
Sous quelle licence agentixmesh est-il distribué ?
MIT. Le code est public sur GitHub à github.com/TokonoMix/agentixmesh — lisez-le, forkez-le, auto-hébergez-le, ou modifiez-le sans demander la permission. Il n'existe aucun palier payant séparé ni cœur fermé caché derrière le dépôt public ; ce que vous voyez est ce qui tourne.
agentixmesh est-il maintenu activement ?
Il est développé comme un projet open source avec un historique complet de commits public sur GitHub, donc vous pouvez vérifier l'activité vous-même avant d'en dépendre. Il n'y a aucun SLA de support formel — comme pour tout projet sous licence MIT, l'adopter signifie assumer votre propre responsabilité opérationnelle du fork que vous exploitez.
Que ne fait délibérément PAS agentixmesh ?
Il ne tourne pas comme un service réseau, ne requiert pas sudo pour l'usage same-user, n'agit pas automatiquement sur le contenu d'un message, et ne prétend pas arrêter l'injection de prompt purement et simplement. Il livre les messages sous forme de données inertes qu'un agent lit et sur lesquelles il décide — le mesh lui-même n'exécute jamais une instruction trouvée à l'intérieur du corps d'un message.

Parlez-nous

Chaque échange commence dans le chat — dites-nous ce qui vous amène et l'assistant prend le relais.