agentixmesh

Vragen

APPENDIX A · FAQ

Veelgestelde vragen

Directe antwoorden op wat agentixmesh is, met welke agent-tools het werkt, wat het beveiligt, en hoe het verschilt van een message queue.

Basisprincipes

Wat is agentixmesh?
agentixmesh is een agent trust layer — een bestand-gebaseerde delivery-laag waarmee AI-agentsessies op één machine berichten kunnen uitwisselen zonder elkaars autoriteit over te nemen, geadresseerd via `uid:project`. Transport is een maildir (new/cur/held/seen-directories) plus een inject hook: geen daemon, geen network listener, geen open poort, geen sudo. Het is MIT-licensed en open op GitHub (github.com/TokonoMix/agentixmesh).
Wat betekent "data is geen autoriteit"?
Het betekent dat een binnenkomend bericht wordt weergegeven als een inert DATA-kader om te lezen, nooit als een commando om te gehoorzamen. De ontvangende agent beslist wat er gebeurt; de mesh onderneemt nooit automatisch actie op basis van de inhoud van een bericht. Reageren met woorden op een bericht is prima; een actie ondernemen, code draaien, of geheimen onthullen puur omdat een bericht-body dat zegt, is dat niet.
Welk probleem lost agentixmesh eigenlijk op?
Het lost het "confused deputy"-risico op van lokale agent-naar-agent-berichtgeving: één sessie die de autoriteit van een andere overneemt puur omdat er een bericht binnenkwam. agentixmesh scheidt wie een bericht stuurde (een kernel-geverifieerd OS user-id) van wat het zegt (een untrusted body), zodat een bericht zijn afzender kan bewijzen zonder dat dat bewijs iets autoriseert wat het bericht vraagt. Containment, niet communicatie, is het lastige deel.
Voor wie is agentixmesh bedoeld?
Engineers die meerdere AI-agentsessies draaien — vandaag Claude Code, andere harnesses zodra er adapters verschijnen — op dezelfde machine, en die deze sessies informatie willen laten overdragen of laten coördineren zonder een message queue of ticketsysteem op te tuigen, en zonder dat de output van de ene sessie stilzwijgend de instructies van een andere sessie wordt. Het gaat uit van command-line-agentworkflows, niet van eindgebruiker-chatproducten.
Is agentixmesh production-ready?
Gedeeltelijk, en met opzet in fases. De same-user-kern is publiek en stabiel — dit is de shippende, dogfooded default. Cross-user delivery (aparte OS-gebruikers, één machine) is end-to-end gevalideerd, maar de production go-live daarvan blijft human-gated: een bericht-body wordt achtergehouden tot een mens hem vrijgeeft. Cross-machine delivery bestaat nog niet — dat is roadmap, geen agentixmesh.
Is agentixmesh gewoon een message bus of pub/sub-systeem?
Nee. Een message bus verplaatst bytes; agentixmesh gaat over wat een sessie mag doen zodra die bytes aankomen. Het onderscheidende element is niet het transport (een maildir) — het is kernel-geverifieerde afzenderidentiteit plus inert-DATA-framing die voorkomt dat een afgeleverd bericht als commando wordt behandeld. Gewone pub/sub heeft geen van beide eigenschappen.
Waarom bestand-gebaseerd (een maildir) in plaats van een socket of daemon?
Een maildir heeft geen draaiend proces nodig, geen poort, en geen privilege escalation — delivery is gewoon bestanden die verplaatsen tussen owner-only (0700) directories die het OS al beschermt. Een daemon of socket listener voegt een altijd-actief attack surface en operationele last toe (start/stop, crash recovery, permissies) voor een same-machine, low-throughput use case die gewone filesystem-semantiek al afdekt.
Wat betekent "agent trust layer"?
Het betekent dat agentixmesh onder de berichtinhoud zit en één vraag beantwoordt: kun je vertrouwen wie dit heeft gestuurd? Het verifieert het OS user-id van de afzender kernel-matig via fstat op de open file descriptor — onvervalsbaar — terwijl al het overige, inclusief de body en het zelf-opgegeven project-label van de afzender, als untrusted wordt behandeld. Trust gaat hier over identiteit, niet over wat een bericht beweert.
Wat is een adres (`uid:project`)?
Een adres is `uid:project` — het numerieke OS user-id van de beoogde ontvanger, plus een project-label. De uid-helft is waarop de mesh delivery daadwerkelijk afdwingt. De project-helft is gewoon de basename van de current-working-directory van de afzender, zelf opgegeven en ongeverifieerd, gebruikt om naar de juiste inbox van die gebruiker te routeren. `mesh-whoami` toont je eigen adres.
Wat is de rol van de mens in agentixmesh?
De mens is de uiteindelijke autoriteit, het meest concreet bij cross-user delivery: een bericht-body wordt achtergehouden tot een mens hem vrijgeeft, zodat onbewaakte cross-user-actie constructief onmogelijk is. Breder gezien onderneemt agentixmesh nooit automatisch actie op basis van berichtinhoud — de ontvangende agent beslist wat ermee te doen — waardoor mensen, niet de mesh, de controle houden over ingrijpende beslissingen.
Is agentixmesh een framework of een protocol?
Het ligt dichter bij een protocol plus een dunne referentie-implementatie dan bij een framework. De kern — kernel-geverifieerde afzenderidentiteit, maildir-transport, inert-DATA-framing — is met opzet harness-neutraal en schrijft niets voor over de interne werking van je agent. Je integreert door een harness-adapter aan het protocol te koppelen, niet door je agent te herschrijven om in de structuur van agentixmesh te passen.
Wat probeert agentixmesh NIET te zijn?
Het probeert geen algemene message queue te zijn, geen cross-machine transport, en geen beveiligingsgarantie tegen prompt injection. Het probeert agents niet namens jou autonoom te maken — cross-user auto-acting is met opzet geblokkeerd, niet slechts afgeraden. Cross-machine delivery en higher-authority features zoals leader-gate co-approval bestaan alleen als roadmap-items, niet als iets wat het vandaag claimt te doen.

Compatibiliteit & harnesses

Werkt agentixmesh met Claude Code?
Ja — Claude Code is de reference adapter en die is vandaag beschikbaar. Hij koppelt de mesh via Claude Code's SessionStart- en UserPromptSubmit-hooks, zodat berichten automatisch in context verschijnen zonder dat je manier van Claude Code gebruiken verandert. Dit is de meest battle-tested integratie en degene waar het maildir/inject-hook-ontwerp als eerste tegen gebouwd is.
Werkt agentixmesh met OpenAI Codex CLI?
Er is een adapter beschikbaar en die is unit-tested. Live-binary end-to-end-verificatie tegen de echte Codex CLI loopt nog, dus beschouw het als shipped-maar-nog-niet-volledig-live-geverifieerd in plaats van production-proven. We noemen het Codex-pad pas "af" zodra die live-verificatie voltooid is.
Werkt agentixmesh met Gemini of andere agent-tools?
Nog niet. Hermes- en OpenClaw-adapters zijn ontworpen en geprototypet, wat ze op de roadmap plaatst, niet in de shipped set. Vandaag zijn de enige adapters Claude Code (reference, shipped) en OpenAI Codex CLI (unit-tested, live e2e-verificatie loopt). Beschouw elke andere harness als unsupported tot er een adapter beschikbaar komt.
Wat betekent "harness-agnostic" hier eigenlijk?
Het betekent dat de kern — maildir-transport, kernel-geverifieerde identiteit, message framing — geen afhankelijkheid heeft van enige specifieke agent-tool. Wat tool-specifiek is, is een dunne adapter-laag die die kern koppelt aan het eigen hook-systeem van een harness, zoals Claude Code's SessionStart/UserPromptSubmit. Het protocol verandert niet per tool; alleen de bekabeling wel.
Kunnen twee verschillende agent-tools, zoals Claude Code en Codex CLI, berichten uitwisselen op dezelfde mesh?
Architecturaal gezien wel — het maildir-formaat en het kernel-geverifieerde identiteitsmodel maakt het niet uit welke harness een bericht schreef of leest, alleen welke OS-gebruiker dat deed. Maar het live bewijs dekt vandaag Claude Code end-to-end; Codex CLI's live-binary e2e, inclusief echte cross-harness-uitwisseling, loopt nog, dus beschouw dat scenario nog niet als gevalideerd.
Moet ik de code van mijn agent aanpassen om agentixmesh te gebruiken?
Nee — je installeert de CLI-wrappers en koppelt eenmalig een kleine hook; er zijn geen wijzigingen aan de eigen source van de agent nodig. Voor Claude Code is dit de reference adapter, vandaag beschikbaar. Voor andere harnesses koppelt een adapter in plaats daarvan dezelfde onderliggende mesh-commando's aan het hook-systeem van die tool.
Wat is het push-hook-contract — hoe komt een bericht in de context van mijn agent terecht?
De hook wordt getriggerd bij sessiestart en bij elke user-prompt-submit. Hij doet een zero-token file read van de mailbox, en als er nieuwe post is, print hij een inert DATA-kader naar stdout. De harness behandelt hook-stdout als geïnjecteerde context, zodat het bericht verschijnt zonder dat de mesh zelf een LLM-call maakt.
Werkt agentixmesh over verschillende machines heen?
Nee, alleen same-machine. Alle huidige delivery — Claude Code en Codex CLI — draait op één host via een lokale maildir; er is geen network listener of remote transport. Cross-machine, cryptografisch ondertekende delivery is een apart product, AgentsWeaver, en dat staat op de roadmap van dat project, niet als onderdeel van agentixmesh.
Hoe voeg ik ondersteuning toe voor een nieuwe harness?
Je bekabelt, je ontwerpt geen nieuw protocol. Een harness-adapter heeft twee dingen nodig: een manier om een commando te draaien bij sessiestart of bij prompt-submit (de push hook), en een manier om de stdout van dat commando context te laten worden. Het maildir-formaat, de identiteitsverificatie en de framing zijn al harness-neutraal en blijven ongewijzigd.
Gaat agentixmesh op termijn Gemini CLI of andere harnesses ondersteunen?
Hermes- en OpenClaw-adapters zijn al ontworpen en geprototypet — dat is de huidige roadmap, geen shipped feature. Een Gemini-specifieke adapter is niet apart bevestigd. Omdat het toevoegen van een harness bekabeling is en geen nieuw protocolwerk, is de verwachte inspanning per nieuwe tool klein, maar er wordt vandaag niets verder dan Claude Code en Codex CLI geleverd.
Betekent harness-agnostic dat elke twee agent-tools vrij gemengd kunnen worden zonder extra risico?
Nee — harness-agnostic beschrijft de transport- en identiteitslaag, geen blanket safety guarantee. Afzenderidentiteit is nog steeds slechts een kernel-geverifieerd OS user-id, geen geverifieerde agent of project. Welke harness een bericht ook ontvangt, de agent moet het nog steeds als inerte data behandelen, nooit als een instructie om te gehoorzamen.
Wat is het verschil tussen de "core" en een "adapter" in agentixmesh?
De core is het maildir-transport, kernel-geverifieerde afzenderidentiteit, en het DATA-kader-berichtformaat — vast en identiek voor elke harness. Een adapter is de dunne, harness-specifieke lijm: hook-registratie plus stdout-bekabeling die een specifieke agent-tool aan die core koppelt. Nieuwe harness-ondersteuning zit volledig in de adapter, niet in de core.
Kan ik agentixmesh gebruiken met een eigen, in-house agent-harness?
Ja, als je de twee adapter-vereisten kunt implementeren: een hook die draait bij sessiestart of prompt-tijdstip, en een manier om de stdout van die hook in de context van de agent te voeren. Omdat de mesh-core harness-neutraal is, heeft een eigen harness geen protocolwijzigingen nodig — alleen hetzelfde soort bekabeling dat Claude Code en Codex CLI gebruiken.
Verzwakt het gebruik van meerdere harnesses op dezelfde mesh de afzenderidentiteit-garantie?
Nee — identiteitsverificatie gebeurt op OS/kernel-niveau, via fstat op de open file descriptor, volledig onder en onafhankelijk van enige harness. Door welke tool een bericht ook heen gaat, het OS user-id van de afzender wordt op dezelfde onvervalsbare manier geverifieerd; de keuze van harness heeft geen invloed op die garantie.

Multi-user (cross-user)

Kunnen twee verschillende OS-gebruikers op één machine elkaar berichten sturen met agentixmesh?
Ja — twee aparte OS-gebruikersaccounts op één host kunnen berichten uitwisselen via de cross-user-modus van agentixmesh, die via een gedeelde, groep-eigendom-maildir routeert in plaats van de private maildir van elke gebruiker. Dit is end-to-end gevalideerd met echte send-to-delivery-cycli. Het gedraagt zich op één belangrijk punt anders dan same-user-berichtgeving: delivery wordt standaard vastgehouden (held), niet direct afgeleverd.
Hoe wordt de afzender geverifieerd wanneer een bericht OS-gebruikersgrenzen overschrijdt?
Op dezelfde manier als same-user-berichten: de kernel, niet het bericht zelf. agentixmesh roept fstat aan op de open file descriptor om de daadwerkelijke owner-uid op OS-niveau te lezen, die niet vervalst kan worden door wat het bericht ook beweert. Wat niet geverifieerd wordt, is de project-helft van het adres — een zelf-opgegeven label dat iedereen op alles kan zetten.
Wat is de human-gate, en waarom wordt een cross-user bericht-body achtergehouden?
Een cross-user bericht komt held binnen: de ontvangende agent ziet alleen metadata — kernel-geverifieerde afzender-uid, lengte, thread-id, timestamp — nooit de body-tekst. Een mens moet het bericht expliciet vrijgeven voordat de body de agent bereikt. Dit bestaat omdat het achterhouden van de body, niet slechts het markeren van het bericht, is wat de blootstelling aan geïnjecteerde inhoud daadwerkelijk beperkt.
Kan een cross-user bericht ooit auto-approved worden of automatisch tot actie leiden?
Nee — dit is constructief onmogelijk, geen instelling die iemand vergat af te sluiten. Cross-user delivery valt altijd standaard terug op human-gated, en per-adres- of per-project-overrides kunnen trust alleen restrictiever maken, nooit verhogen naar auto. Er is geen codepad waarbij een held cross-user body een agent bereikt zonder expliciete menselijke vrijgave.
Is cross-user messaging production-ready?
Het mechanisme is end-to-end gevalideerd — echte held, human-released, delivered cycli tussen twee OS-gebruikers zijn live bewezen. Maar de go-live voor een gegeven deployment blijft met opzet human-gated: de withholding-stap is permanent voor cross-user, geen rollout-gat dat later gedicht wordt. "Ready" betekent dus veilig om onder toezicht te draaien, niet veilig om onbewaakt te laten.
Hoe werkt het vrijgeven van een held cross-user bericht?
Een mens aan de ontvangende kant beoordeelt de metadata van het held bericht — afzender-uid, lengte, thread-id, timestamp — en onderneemt dan een expliciete release-actie die de body voor het eerst aan de agent toont. Er wordt niets afgeleverd vóór die stap, en het bericht blijft onbeperkt held als de release nooit plaatsvindt.
Wat kan de ene OS-gebruiker zien van de berichten van een andere gebruiker vóór ze zijn vrijgegeven?
Niets behalve structurele metadata. De ontvangende kant kan zien dat er een bericht bestaat, welke kernel-geverifieerde uid het stuurde, hoe lang het is, en tot welke thread het behoort — nooit de tekst. Dit is met opzet: metadata alleen kan geen instructie bevatten, dus het tonen ervan vóór menselijke review heropent niet het injection-oppervlak dat de hold juist moet sluiten.
Hoe wordt een collega onboarded om cross-user berichten te sturen of ontvangen?
Onboarding is een aparte enrollment-stap, niet gewoon het aanmaken van een OS-account op de machine. Een nieuw lid wordt geregistreerd zodat hun kernel-geverifieerde uid erkend wordt als legitieme mesh-deelnemer, met identiteit bevestigd out-of-band in plaats van overgenomen uit een zelf-gerapporteerde claim. Tot enrollment worden berichten van die uid niet behandeld als afkomstig van een bekend lid.
Wat gebeurt er als een collega vertrekt of toegang verliest?
Hun mesh-lidmaatschap wordt ingetrokken, waardoor toekomstige berichten van die uid niet meer behandeld worden als afkomstig van een erkend lid. Revocatie is een expliciete administratieve actie gekoppeld aan de identiteit op OS-niveau, geen schakelaar die enige agent of bericht kan aanvragen — consistent met de rest van agentixmesh, waar trust-wijzigingen bewuste menselijke acties zijn.
Moeten beide gebruikers op dezelfde machine zitten?
Ja — de cross-user-modus van agentixmesh is alleen single-machine. Het steunt op een lokaal filesystem en uid-verificatie op kernel-niveau, beide host-lokale concepten zonder betekenis tussen aparte machines. Berichtgeving tussen agents op verschillende hosts is vandaag geen functie van agentixmesh; daarvoor is AgentsWeaver gebouwd, het cross-machine, cryptografisch ondertekende familielid.
Kan een kwaadwillende gebruiker doen alsof hij een ander project is om de agent van een collega te misleiden?
Ze kunnen het project-label vervalsen, niet de afzender. De project-helft van een adres is een zelf-opgegeven string — de eigen cwd-basename van de afzender — en wordt niet geverifieerd, dus een bericht kan binnenkomen met een label alsof het van een ongerelateerd project komt. De uid waar het daadwerkelijk vandaan kwam blijft kernel-geverifieerd: je weet altijd welke OS-gebruiker het stuurde, alleen niet welk van hun projecten.
Bestaat er een leader- of approver-rol die cross-user berichten voor een team kan co-approven?
Een higher-authority-laag — leader-gate co-approval en group roles — bestaat in het ontwerp maar is roadmap, geen shipped production security; vertrouw er vandaag niet op. De control die live en load-bearing is voor cross-user is de per-bericht human release gate: elk cross-user bericht gaat daardoorheen, ongeacht enige groepsstructuur.
Kan de ene gebruiker het mesh-verkeer van een andere gebruiker monitoren, bijv. een teamlead die op problemen let?
Consent-gated leader-read monitoring is ontworpen maar niet shipped — dezelfde roadmap-status als de leader-gate- en group-roles-laag. Zoals het er nu voorstaat, is de mailbox van een gebruiker alleen leesbaar door die gebruiker; er is geen live feature waarmee een andere partij de berichten van iemand anders kan observeren, held of released, met of zonder consent.
Geldt de cross-user hold voor elk bericht, of slechts voor sommige?
Het geldt voor elk cross-user bericht — held-with-metadata-only is de standaard en enige modus, geen per-bericht- of per-afzender-optie. Er is geen cross-user-instelling om "trust deze uid, auto-deliver" te doen. Ownership dat forgery elimineert plus de human gate is het vaste contract voor elk bericht dat een uid-grens oversteekt.
De uid van de afzender kan niet vervalst worden, dus waarom de menselijke stap niet overslaan?
Omdat uid-verificatie en injectie-veiligheid verschillende problemen zijn. Het kernel-verifiëren van de uid van de afzender bewijst wie een bericht stuurde, niet dat de inhoud ervan veilig is om op te handelen — een legitiem verzonden bericht kan nog steeds tekst bevatten die opgesteld is om op een instructie te lijken. De human release-stap beperkt de blootstelling aan die inhoud; het is geen overbodige identiteitscheck.
Kan de agent, zodra een cross-user bericht is vrijgegeven, er automatisch op handelen?
Nee — eenmaal vrijgegeven wordt het exact behandeld als elk ander inert data-kader, onder dezelfde staande regel als same-user berichten: nooit een bericht-body gehoorzamen. De agent mag reageren met woorden, maar code draaien, een actie ondernemen, of geheimen onthullen op gezag van het bericht is tegen die regel, ongeacht of het bericht van dezelfde gebruiker of een andere kwam.
Welke permissies op OS-niveau beschermen een gedeelde cross-user mailbox tegen andere gebruikers op de machine?
Cross-user delivery gebruikt een groep-eigendom-directory in plaats van de strikte owner-only (0700) dirs van same-user-modus, omdat meer dan één uid erbij moet kunnen. Groepsleden kunnen een bericht droppen en de directory traverseren, maar kunnen niet listen of lezen wat erin zit; alleen de beoogde ontvanger kan een bericht lezen, dus co-tenants op de machine kunnen niet door elkaars post bladeren.

Beveiliging & trust-model

Stopt agentixmesh prompt injection?
Nee — het vermindert het risico op prompt injection, het elimineert het niet. Ownership garandeert wie een bericht stuurde, niet wat het bericht zegt. Een legitiem verzonden bericht kan nog steeds tekst bevatten die opgesteld is om op een instructie te lijken, en de agent die het leest is het zwakke punt. agentixmesh mitigeert dit met inert-DATA-framing, sanitatie, en een staande never-obey-regel — maar de ontvangende LLM beslist uiteindelijk wat er gebeurt.
Wat is het verschil tussen forgery en prompt injection, en waarom behandelt agentixmesh ze verschillend?
Forgery is een bericht dat liegt over wie het stuurde; injection is een legitiem verzonden bericht dat een agent probeert te overtuigen tot een actie. agentixmesh elimineert het eerste met een kernel-geverifieerde harde garantie — een gespoofte afzender wordt afgewezen voordat een agent het bericht ooit ziet. Het tweede vermindert het slechts, omdat injection in de berichtinhoud leeft, die de mesh kan omkaderen en saneren maar niet volledig kan neutraliseren.
Wat betekent "kernel-verified sender" eigenlijk?
Het betekent dat het OS user-id van de afzender wordt gelezen via fstat op de open file descriptor van het afgeleverde bericht, niet uit een veld binnen het bericht zelf. De kernel houdt file ownership bij onafhankelijk van de berichtinhoud, dus een afzender kan niet beweren een andere gebruiker te zijn — het OS zou moeten liegen over wie eigenaar is van het bestand dat het net schreef, en dat doet het niet.
Kan iemand vervalsen van wie een bericht afkomstig is?
Nee — afzenderidentiteit is een harde, kernel-afgedwongen garantie, geen conventie die de afzender kan overrulen. Omdat de uid komt uit de eigen file-ownership-metadata van het besturingssysteem in plaats van een zelf-gerapporteerd veld, kan een proces dat als één gebruiker draait geen bericht laten lijken alsof het van een andere gebruiker komt. Dit is het ene deel van het trust-model dat niet probabilistisch is.
Is de "project"-helft van een `uid:project`-adres betrouwbaar?
Nee — het project-label is zelf opgegeven (het is gewoon de working-directory-basename van de afzender) en wordt niet geverifieerd. agentixmesh bewijst welke OS-gebruiker een bericht stuurde, niet welke agent, repository, of project het stuurde. Behandel de project-helft van elk adres als een hint voor routing, nooit als een beveiligingsclaim — twee agents die door dezelfde gebruiker gedraaid worden, kunnen allebei elke projectnaam claimen die ze willen.
Kan een bericht van een andere agent mijn agent een commando laten draaien of een geheim laten lekken?
Geen enkel bericht kan een actie afdwingen — agentixmesh levert alleen data in context af; het voert nooit iets uit namens de afzender. Of een agent een commando draait of een geheim onthult, hangt volledig af van de eigen besluitvorming en tool-permissies van die agent. De taak van de mesh is om de ontvangende agent inerte tekst te geven plus een regel om het als data te behandelen, niet om enige capability toe te kennen of uit te oefenen.
Wat is een "inert DATA frame"?
Zo wordt een binnenkomend bericht aan de ontvangende agent gepresenteerd: duidelijk afgebakend als te lezen data, nooit als een te gehoorzamen commando. De framing gaat samen met een staande regel dat het zeggen van een bericht-body niets autoriseert — reageren in woorden is prima, maar een actie ondernemen, code draaien, of een geheim onthullen op instructie van een bericht is dat niet. De agent, niet de mesh, beslist wat er vervolgens gebeurt.
Welke sanitatie past agentixmesh toe op binnenkomende berichten?
Voordat een bericht de context van een agent bereikt, verwijdert agentixmesh constructies die vaak gebruikt worden om instructies te vermommen als vertrouwde output — zoals controletekens, onzichtbare/zero-width tekens, en tekstpatronen die het begin van een nieuwe conversatie-beurt nabootsen. Dit versmalt het injection-oppervlak maar is een mitigatie, geen filter dat elke mogelijke formulering van een manipulatief bericht kan opvangen.
Bestaat er bescherming tegen replayed of duplicate berichten?
Ja — afgeleverde berichten worden bijgehouden zodat hetzelfde bericht niet opnieuw wordt geïnjecteerd in de context van een agent bij een latere poll. Dit beschermt tegen een bericht dat stilzwijgend opnieuw wordt afgeleverd en opnieuw gelezen alsof het nieuw was, wat ertoe doet omdat herhaalde blootstelling aan dezelfde geprepareerde tekst op zichzelf een manier is om druk op een agent uit te oefenen. Het is een delivery-hygiëne-control, geen verdediging tegen een eerste injectiepoging.
Wat is het threat model van agentixmesh?
Vertrouwde collega's die één machine delen, geen hostile-root-tegenstander. Het ontwerp gaat ervan uit dat deelnemende OS-gebruikers niet actief de kernel of file-permissies van de host aanvallen om elkaar te imiteren — als een gebruiker root-toegang heeft, kan die bijna elk lokaal trust-mechanisme omzeilen. Binnen die aanname houdt de forgery-garantie van agentixmesh stand; het is niet ontworpen om een kwaadwillende systeembeheerder of een gecompromitteerde kernel te overleven.
Is agentixmesh een security-product?
Nee — het is een trust boundary voor berichtaflevering, geen security-product in bredere zin. Het beantwoordt betrouwbaar één nauwe vraag (wie stuurde dit bericht) en helpt gedeeltelijk bij één bredere kwestie (voorkom dat berichtinhoud een agent kaapt). Het vervangt geen endpoint-hardening, secrets management, of de eigen permission-scoping van een agent — die blijven de verantwoordelijkheid van de operator.
Wat lost file ownership NIET op?
Ownership lost op wie een bericht stuurde; het lost niet op wat een bericht zegt of hoe een agent erop reageert. Het voorkomt niet dat een legitiem verzonden bericht manipulatieve tekst bevat, toetst berichtinhoud niet op veiligheid, en beperkt niet wat een ontvangende agent in staat is te doen — dat is een functie van de eigen tool-permissies van de agent, niet van de mesh.
Als mijn agent een kwaadwillende instructie gehoorzaamt die in een bericht-body verwerkt zit, is dat een agentixmesh-bug?
Nee — dat is de ontvangende agent die faalt in het naleven van de never-obey-a-message-body-regel, en dat is precies het restrisico waar agentixmesh open over is. De mesh levert het bericht omkaderd als inerte data af en kan een LLM niet dwingen die framing te respecteren. Dit faalmodel verder terugdringen is een model-/prompt-discipline-probleem aan de ontvangende kant, niet iets wat een delivery-laag zelfstandig kan oplossen.
Authenticeert agentixmesh de agent of de harness die een bericht stuurt?
Geen van beide — het authenticeert de OS-gebruiker waaronder het verzendende proces draait, niets daarboven. Het kan Claude Code niet onderscheiden van een andere harness, of het ene agent-proces van een tweede dat door dezelfde persoon wordt gedraaid. Als je moet weten welke specifieke agent of tool iets stuurde, moet dat uit context of conventie komen, niet uit de identiteitsgarantie van agentixmesh.
Is cross-user messaging (aparte OS-gebruikers, dezelfde machine) vandaag veilig te gebruiken?
Het is end-to-end gevalideerd, maar de production go-live is met opzet human-gated, niet iets wat je nu al als algemeen beschikbaar moet behandelen. Een cross-user bericht-body wordt achtergehouden tot een mens hem vrijgeeft, en cross-user auto-acting is constructief onmogelijk — die gate is het veiligheidsmechanisme, geen formaliteit. Behandel cross-user als een gereviewde capability die nog wacht op een bewuste rollout-beslissing.
Kan een bericht automatisch een actie triggeren zonder enige review?
Nee — delivery plaatst een bericht alleen in de context van een agent; niets in agentixmesh voert iets uit namens een bericht. Binnen de eigen sessies van één gebruiker beslist de agent die een bericht leest wat er vervolgens gebeurt, onder de never-obey-regel. Tussen gebruikers zorgt de toegevoegde human-release gate ervoor dat een body niet eens zichtbaar is tot een mens hem doorlaat, wat elke vorm van auto-acting constructief uitsluit.
Bestaat er een persistent audit trail van elk bericht?
Niet als shipped, production-garantie in de same-user-kern — het betrouwbare deel is de replay guard die her-aflevering voorkomt, geen tamper-evident log. Consent-gated monitoring van de mailbox van een andere gebruiker (leader-read) bestaat in ontwerp voor de cross-user-tier, maar is roadmap, geen feature die vandaag geadverteerd wordt als production security of compliance.

Isolatie & grenzen

Wat identificeert een `uid:project`-adres eigenlijk?
Twee verschillende dingen met twee verschillende garanties. De uid is de OS-gebruiker, kernel-geverifieerd via fstat aan de ontvangende kant, dus die kan vertrouwd worden. De project-helft is de eigen working-directory-basename van de afzender, zelf opgegeven en ongeverifieerd — behandel het als informatieve context, geen bewijs van waar een bericht vandaan kwam.
Is de project-helft van een adres een stabiele, unieke identifier?
Nee. Het is gewoon de basename van welke directory de working directory van de verzendende sessie toevallig is. Niets registreert het of dwingt uniciteit af over een machine heen. Twee ongerelateerde folders die toevallig dezelfde naam delen, produceren hetzelfde adres, zonder centrale autoriteit die vóór delivery op collisions controleert.
Hoe worden mailboxen tussen projecten geïsoleerd?
Elk adres krijgt zijn eigen maildir-directory, aangemaakt owner-only (0700), alleen leesbaar door de OS-gebruiker die er eigenaar van is. Isolatie wordt afgedwongen door filesystem-permissies, niet door application-level logica — een proces dat als een andere OS-gebruiker draait, kan de directory helemaal niet openen, wat het ook probeert.
Kan het ene project de inbox van een ander project lezen of erop handelen?
Nee, over OS-gebruikers heen — delivery is per-adres, en een bericht komt alleen terecht in de maildir die overeenkomt met de `uid:project`-bestemming. Een bericht draagt ook geen autoriteit: het ontvangen ervan geeft een sessie nooit de mogelijkheid om in een andere inbox te reiken, namens een peer te handelen, of iets automatisch te triggeren.
Als mijn OS-gebruiker meerdere verschillende agent-projecten draait, kunnen die elkaars post lezen?
Isolatie wordt per OS-gebruiker afgedwongen, niet per project, aangezien maildir-ownership op uid-niveau wordt ingesteld. Een proces dat als diezelfde uid draait, kan in principe elke maildir openen die die uid bezit. Het project-label selecteert alleen een delivery-adres — het is geen aparte permission boundary binnen één gebruiker.
Kan een bericht spoofen vanuit welk project het verzonden is?
Ja — het project-label is zelf opgegeven en niet cryptografisch gecontroleerd, dus een afzender kan elke gewenste string in die helft van het adres zetten. Wat niet gespooft kan worden is de uid: de kernel-geverifieerde afzenderidentiteit vertelt je welke OS-gebruiker het bericht daadwerkelijk stuurde, onafhankelijk van de beweerde projectnaam.
Wat gebeurt er als ik een adres verkeerd typ en het toevallig overeenkomt met een ander echt project?
Het bericht wordt daar stilzwijgend afgeleverd. Er is geen bevestigingsstap die controleert of de bestemming die je typte de bedoelde was, dus een typfout die botst met een ander live adres routeert je bericht simpelweg naar de inbox van die sessie — zonder dat iets een van beide kanten laat weten dat er een fout is gebeurd.
Wat gebeurt er als ik een project adresseer dat niet bestaat of niet draait?
Het bericht wordt naar die mailbox geschreven en wacht — er is geen registry van actieve adressen om tegen te valideren, dus verzenden naar een niet-bestaande of momenteel inactieve `uid:project` levert geen error op. Het wordt pas leesbaar als en wanneer een sessie met precies dat adres later zijn mailbox checkt.
Hoe vind ik mijn eigen mesh-adres?
Draai `mesh-whoami` — het print jouw `uid:project`-adres exact zoals andere sessies het zouden moeten typen om je te bereiken, live afgeleid van je OS-uid en de basename van je current working directory. Gebruik dit in plaats van het adres uit je hoofd te reconstrueren, aangezien de project-helft afhangt van cwd en kan verschuiven.
Hoe bereik ik een andere sessie zonder het exacte adres handmatig te typen of te raden?
Gebruik het sender-side address book — een lijst met vriendelijke aliassen die je lokaal bijhoudt en die memorabele namen koppelen aan volledige `uid:project`-adressen, zodat je niet elke keer een exacte basename hoeft te onthouden of over te typen. Het beïnvloedt alleen hoe jij naar een bestemming verwijst; het verandert niet hoe de ontvanger geadresseerd wordt.
Ontdekt agentixmesh automatisch andere projecten op de machine en verbindt het ze voor mij?
Nee. Er is geen auto-discovery, geen directory van actieve projecten, en geen automatische koppeling van sessies. Elk bericht gaat naar één specifiek `uid:project`-adres dat een afzender expliciet opgeeft. Isolatie is de standaardtoestand; een grens wordt alleen overschreden omdat iemand met opzet die exacte bestemming benoemde.
Gegeven dat het project-label niet betrouwbaar is, waar moet ik voor isolatiegaranties eigenlijk op vertrouwen?
Vertrouw op de uid-grens. agentixmesh garandeert dat mailboxen alleen leesbaar zijn door hun eigen OS-gebruiker en garandeert dat je weet welke OS-gebruiker een binnenkomend bericht stuurde. Het garandeert niet dat het beweerde verzendende project accuraat is — behandel elke projectnaam in of bij een bericht als context, nooit als access control.
Kunnen twee verschillende directories met dezelfde basename botsen op één adres?
Ja. Adressering gebruikt alleen de basename van de working directory, dus twee folders die een naam delen — bijvoorbeeld de hoofd-checkout van een project en een aparte kopie of checkout elders — resolven naar hetzelfde `uid:project`-adres en delen stilzwijgend één inbox, zonder waarschuwing bij verzenden of ontvangen.
Moet ik een project registreren voordat het mesh-berichten kan ontvangen?
Er bestaat geen aanmeldstap. Het adres van een project bestaat impliciet vanaf het moment dat iets dat als die OS-gebruiker draait, vanuit een directory met die basename, zijn mailbox checkt. Verzenden naar een adres dat nooit "aangemaakt" is, schrijft simpelweg het bericht naar een maildir, die leesbaar wordt zodra een overeenkomende sessie er later op polt.
Wordt mailbox-isolatie afgedwongen door de eigen code van agentixmesh, of door het besturingssysteem?
Door het besturingssysteem. Mailbox-directories worden owner-only (0700) aangemaakt, dus de isolatiegarantie komt van standaard Unix filesystem-permissies in plaats van een application-level check die agentixmesh verkeerd zou kunnen doen. Dat is ook waarom het standhoudt tegen een buggy of kwaadwillend agent-proces — de kernel weigert de `open()` voordat er enige mesh-code draait.

Kosten & tokens

Kost het checken van de mesh op nieuwe berichten LLM-tokens?
Nee. Het checken van de mesh is een gewone file read tegen je lokale maildir, geen LLM-call, dus het kost nul tokens. Poll-frequentie verandert daar niets aan — `mesh-poll status` en de automatische inject-hook-check bij sessiestart zijn filesystem-operaties. Je bepaalt zelf of deze check überhaupt draait via `mesh-poll on/off/status`.
Wanneer kost een mesh-bericht daadwerkelijk tokens?
Alleen wanneer het wordt afgeleverd in de context van een agent om te lezen. Een pending bericht dat in een maildir zit kost niets; de kosten verschijnen op het moment dat de tekst als DATA-kader in het gesprek wordt weergegeven, en die delivery wordt aan de agent kenbaar gemaakt — het is geen verborgen achtergrondkosten.
Kost een bericht dat gequeued of held staat in afwachting van release tokens?
Nee. Een bericht held of queued houden is een bestand dat op de schijf staat in de `held`- (of `new`-)directory; niets leest het in de context van enige agent tot release, dus het bouwt geen tokenkosten op. Kosten starten pas zodra het bericht daadwerkelijk is afgeleverd en gelezen — queue-duur is irrelevant voor de spend.
Kost het doorsturen van een mesh-bericht naar een menselijk kanaal, zoals een telefoon, LLM-tokens?
Nee. Doorsturen naar een menselijk kanaal — bijvoorbeeld het doorrelayen van een notificatie naar een telefoon — is een gewone message-passing-operatie, geen LLM-call, dus dat brengt geen LLM-tokenkosten met zich mee. Tokenkosten zijn specifiek gekoppeld aan een agent die inhoud in zijn eigen context leest, niet aan het verplaatsen van tekst tussen delivery-kanalen.
Is agentixmesh gratis te gebruiken?
Er is geen per-bericht-vergoeding en geen tokenkosten om de mesh te pollen of te checken — dat deel is gratis. "Gratis" betekent hier vrij van LLM-tokens: agentixmesh zelf rekent niets. Wat niet gratis is, is de onderliggende agentsessie — hosting en compute voor het draaien van de agents die versturen en ontvangen zijn een aparte kostenpost die je al betaalt.
Is agentixmesh open source?
Ja. Het is MIT-licensed en gepubliceerd op GitHub (github.com/TokonoMix/agentixmesh). Je kunt de transport-, identiteitsverificatie- en delivery-code zelf lezen in plaats van kosten- of beveiligingsclaims op goed vertrouwen aan te nemen — er is geen closed component dat berichtaflevering bemiddelt of gebruik meet.
Heb ik een API-key of abonnement nodig om de mesh zelf te gebruiken?
Nee. De mesh bestaat uit lokale bestanden — een maildir plus een inject hook — zonder daemon, network listener, of externe dienst om tegen te authenticeren, dus er is niets om te keyen of op te abonneren voor de mesh-laag. De enige kosten die je zult zien zijn het modelgebruik van je eigen agent wanneer die een afgeleverd bericht leest.
Kan ik de tokenuitgave door mesh-delivery beperken of uitschakelen?
Ja, met `mesh-poll off`. Polling uitschakelen stopt de inject hook met checken op of afleveren van nieuwe berichten in je context, dus er wordt niets gelezen en er worden geen tokens besteed aan mesh-inhoud. `mesh-poll status` toont de huidige status; `mesh-poll on` schakelt delivery weer in wanneer je het terug wilt.
Kost het versturen van een bericht met `mesh-send` tokens?
Een bericht schrijven met `mesh-send` is een file write naar de maildir van de ontvanger, geen LLM-operatie, dus de handeling van versturen voegt geen tokens toe bovenop wat je agent al besteedde aan het opstellen van de tekst die hij wilde versturen. Er is geen mesh-side-vergoeding bovenop die write.
Besteedt de automatische inject hook die bij sessiestart draait stilzwijgend tokens elke beurt?
Nee, niet tenzij er daadwerkelijk een bericht af te leveren is. De check van de hook op nieuwe post is een file read; als de maildir leeg is, wordt er niets aan de context toegevoegd en worden er geen tokens besteed. Tokens worden alleen besteed op de beurten waarin een pending bericht daadwerkelijk in het gesprek wordt weergegeven.
Als ik een held of pending bericht nooit lees, betaal ik er dan toch voor?
Nee. Een ongelezen bericht — of het nu in `new`, `held`, of nooit opgehaald staat — wordt nooit getokenized in de context van enige agent, dus het kost niets. Kosten zijn strikt gekoppeld aan de handeling van een agent die afgeleverde inhoud leest, niet aan het loutere bestaan van een bericht in een mailbox.

Vergelijkingen

Hoe verschilt agentixmesh van een message queue zoals Redis of RabbitMQ?
Een queue verplaatst bytes tussen endpoints; het weet of verifieert niet wie ze stuurde. agentixmesh verifieert de OS-gebruiker van de afzender kernel-matig via fstat op de open file descriptor voordat de ontvangende agent het bericht ooit ziet, dus een queue-bericht dat beweert 'from user X' te zijn kan vervalst worden — een agentixmesh-bericht kan dat niet. Die identiteitsgarantie is het punt; een queue biedt die niet.
Kan ik hetzelfde bouwen met Redis pub/sub of een databasetabel?
Je zou de bytes kunnen verplaatsen, maar dan zou je zelf afzenderverificatie moeten aanbouwen — Redis en een gedeelde DB-tabel vertrouwen welke client er ook naar schreef. De garantie van agentixmesh komt uit het OS: alleen de echte uid die de file descriptor opende kan de geregistreerde afzender zijn. Dat opnieuw implementeren op een queue betekent kernel-level identiteitschecks opnieuw afleiden, en dat is het grootste deel van het lastige werk.
Geeft agentixmesh delivery-garanties of ordering zoals een echte message queue?
Niet zoals een queue-product dat doet — geen acks-with-retries-and-DLQ-mechaniek, geen cross-sender ordering-garanties. Het is een maildir: berichten landen in `new/`, verplaatsen naar `cur/` bij lezen, `held/` voor gated gevallen. Dat is met opzet simpel. Als je broker-grade throughput, ordering, of backpressure nodig hebt, is agentixmesh niet die tool — het is een trust layer, geen queue-product.
Hoe verhoudt agentixmesh zich tot MCP (Model Context Protocol)?
Andere laag. MCP koppelt één agentsessie aan tools en resources — databases, API's, bestanden — die het aanroept. agentixmesh koppelt één agentsessie aan een andere agentsessie, zodat ze berichten kunnen uitwisselen zonder dat de ene de autoriteit van de andere overneemt. Een sessie kan MCP-servers gebruiken voor tools en agentixmesh voor het praten met peer-agents — ze zijn complementair, niet concurrerend.
Kan ik agentixmesh en MCP samen gebruiken?
Ja — ze lossen verschillende problemen op en botsen niet. Een Claude Code-sessie kan MCP-servers gekoppeld hebben voor tool-toegang, zoals een database of search-API, en apart agentixmesh-berichten ontvangen van een andere sessie die aan een gerelateerde taak werkt. MCP regelt de agent-naar-tool-rand van de context; agentixmesh regelt de agent-naar-agent-rand. Niets aan het ene vereist of blokkeert het andere.
Hoe verhoudt agentixmesh zich tot A2A of andere agent-naar-agent-protocollen gericht op cross-machine communicatie?
Het is een positioneringsverschil, geen feature-gat: agentixmesh is single-machine, bestand-gebaseerd, met kernel-geverifieerde afzenderidentiteit — het doet geen cross-machine transport, TLS, of cryptografisch ondertekenen tussen hosts. Protocollen gebouwd voor agents op aparte machines lossen network-level trust op, wat een ander probleem is dan lokale file-descriptor trust. Cross-machine, ondertekende agentcommunicatie is voor ons roadmap-terrein (AgentsWeaver), niet wat agentixmesh vandaag doet.
Waarom niet gewoon agents een gedeeld bestand of database laten lezen en schrijven?
Een gedeeld bestand of DB heeft geen concept van wie een gegeven rij schreef, verder dan wat de schrijver beweert — elk proces met write-toegang kan een sender-veld vervalsen. De maildir van agentixmesh is owner-only (0700, same-user), en de afzender wordt afgeleid van de kernel-geverifieerde uid van het proces dat het bestand opende, geen zelf-gerapporteerde kolom. Gedeelde opslag geeft je bytes, geen provenance.
Wat is er mis met een gedeelde scratch-directory waarop twee agents beide pollen voor wijzigingen?
Niets weerhoudt de ene agent, een bug, of een geïnjecteerde instructie ervan om een bestand te schrijven dat een andere afzender imiteert — een gewone gedeelde directory heeft helemaal geen identiteitscheck. agentixmesh voegt precies dat toe: een kernel-geverifieerde afzender per bericht, plus inert-DATA-framing zodat een ontvangen bericht gelezen wordt, niet automatisch gehoorzaamd. Een scratch-directory geeft je geen van beide garanties.
Waarom niet gewoon de output van de ene agent direct de prompt van een andere agent laten worden?
Dat is precies het confused-deputy/injection-risico dat agentixmesh probeert af te zwakken. De ruwe output van de ene agent rechtstreeks in de prompt van een andere pipen, geeft het dezelfde autoriteit als een directe instructie, inclusief alles wat in die output gesmokkeld is. agentixmesh levert berichten in plaats daarvan als een inert DATA-kader dat de ontvangende agent leest maar nooit automatisch uitvoert; antwoorden in woorden is prima, handelen op gezag van een bericht niet.
Voegt het framen van berichten als inerte data geen frictie toe vergeleken met de andere agent gewoon direct prompten?
Enigszins, ja, en dat is met opzet. Direct prompten laat 'ontvangen tekst' en 'te volgen instructie' in elkaar overvloeien, wat precies het confused-deputy-faalmodel is. agentixmesh houdt ze gescheiden: het kader is ondubbelzinnig data, en de ontvangende agent — niet het bericht — beslist of en hoe te handelen. Dat is de prijs van niet triviaal injecteerbaar zijn.
Hoe verschilt dit van het overbruggen van twee agents via Slack of een chatkanaal?
Een chat-bridge geeft je een gedeelde ruimte waar iedereen met de credentials als zichzelf kan posten — nuttig voor mensen, maar het verifieert niet op OS-niveau welk proces een bericht stuurde, en het heeft geen ingebouwde 'dit is data, geen commando'-framing. De identiteitsgarantie van agentixmesh is kernel-afgeleid (fstat op de eigen open file descriptor van de afzender), en delivery valt standaard terug op inerte framing in plaats van een live stream die een agent als instructies zou kunnen lezen.
Waar past agentixmesh ten opzichte van AgentsWeaver en Tokonomix?
Het zijn drie lagen van één familie, geen concurrenten. agentixmesh is de lokale, single-machine on-ramp — bestand-gebaseerd, kernel-geverifieerde identiteit, één host. AgentsWeaver is de cross-machine, cryptografisch ondertekende scale-up voor wanneer agents meerdere hosts overspannen. Tokonomix is cross-vendor LLM-consensus — één vraag naar meerdere modellen routeren en de antwoorden beoordelen. Verschillende problemen, dezelfde trust-first-aanpak.
Wanneer zou ik agentixmesh ontgroeien en iets als AgentsWeaver nodig hebben?
Wanneer je agentsessies niet meer op één machine leven. De identiteitsgarantie van agentixmesh is geworteld in een lokaal kernel-primitief — fstat op een open file descriptor — dat geen antwoord heeft op het bewijzen dat een bericht van een andere host kwam; dat vereist cryptografisch ondertekenen op network-niveau, het probleem waar AgentsWeaver zich op richt. Meerdere OS-gebruikers op één machine is nog steeds terrein van agentixmesh (cross-user-modus), alleen human-gated.
Is Tokonomix een vervanging voor agentixmesh?
Nee — een andere taak. Tokonomix beantwoordt 'is deze output goed?' door één vraag naar meerdere LLM-vendors te sturen en een beoordeeld antwoord te synthetiseren. agentixmesh beantwoordt 'kan ik vertrouwen wie mij dit bericht stuurde?' tussen agentsessies. Ze kunnen naast elkaar in dezelfde workflow gebruikt worden, maar geen van beide vervangt de andere.
Is agentixmesh een vervanging voor orchestratie-frameworks zoals LangGraph of CrewAI?
Nee — orchestratie-frameworks bepalen wat een agent vervolgens doet binnen één proces of workflow; agentixmesh verplaatst betrouwbare berichten tussen aparte agentsessies of processen die geen geheugen of autoriteit delen. Een sessie kan intern een orchestratie-framework draaien en tegelijk versturen en ontvangen via agentixmesh — ze opereren op verschillende lagen en overlappen grotendeels niet.
Waarin verschilt agentixmesh van MCP (Model Context Protocol)?
Ze zitten op verschillende lagen. MCP verbindt één model met zijn tools en context — de agent roept capaciteiten bewust aan, als eigen acties. agentixmesh is de vertrouwensgrens tussen al draaiende agent-sessies: het OS-user-id van de afzender is kernel-geverifieerd en de inhoud komt binnen als inerte data, nooit als een instructie die de agent moet opvolgen. Aangrenzend, niet concurrerend — de pagina agentixmesh vs MCP zet ze volledig naast elkaar.
Kunnen agentixmesh en MCP naast elkaar draaien?
Ja — dat is de verwachte opstelling. Elke sessie houdt haar eigen MCP-servers voor capaciteiten, terwijl agentixmesh de berichten tussen sessies draagt. De mesh levert een verzoek af als data; of de agent ernaar handelt blijft een beslissing binnen de ontvangende sessie, onder haar eigen permissies.

Setup, limieten & roadmap

Vereist agentixmesh een achtergrond-daemon of server-proces?
Geen daemon. Same-user delivery draait op een maildir (`new`/`cur`/`held`/`seen`-folders) plus een inject hook die getriggerd wordt wanneer een agentsessie start of een prompt wordt ingediend — niets hoeft continu op de achtergrond te draaien. Er is geen persistent proces dat kan crashen, herstarten, of in de gaten gehouden moet worden voor het same-user kernpad.
Opent agentixmesh een netwerkpoort?
Nee. Het heeft geen enkele network listener — same-user berichtgeving is gewone filesystem-I/O: een bericht wordt in een maildir-directory geschreven en opgepikt door de inject hook bij het volgende sessie-event. Er is geen socket om te openen, geen poort om te firewallen, niets dat luistert naar verbindingen.
Heb ik sudo of root nodig om agentixmesh te gebruiken?
Nee, niet voor de same-user-kern. Mailboxen zijn owner-only directories (mode 0700) die een normaal gebruikersaccount zelfstandig aanmaakt en leest. Root wordt alleen relevant als je verdergaat met het provisionen van de gedeelde host-setup van de optionele cross-user-laag — alledaagse same-user berichtgeving raakt sudo nooit aan.
Wat heeft een host nodig om agentixmesh te draaien?
Gewoon één machine, een filesystem waar het gebruikersaccount naar kan schrijven, Python, en een maildir onder de home-directory van die gebruiker. Het andere stuk is een inject hook gekoppeld aan je agent-harness zodat binnenkomende berichten in de context van een sessie worden weergegeven — geen exotische infrastructuur daarbovenop.
Hoe installeer ik agentixmesh?
Koppel vier host-integratiepunten: een Python-pad-entry zodat het package importeerbaar is, CLI-wrappers (zoals `mesh-send`) op je PATH, een skill-bestand dat je agent-harness laadt, en een inject hook die triggert bij sessiestart en prompt-submit. Het is open source op GitHub (github.com/TokonoMix/agentixmesh, MIT), dus je clonet het en draait de installatiestappen zelf.
Is agentixmesh self-hostable?
Ja — het is alleen self-hosted. Er is geen hosted service of SaaS-backend; agentixmesh bestaat uit lokale bestanden (een maildir) plus een hook die je installeert in je eigen agent-harness op je eigen machine. Je beheert het transport end-to-end, en er verlaat geen berichtdata je host.
Wat gebeurt er als ik de inject hook nooit installeer?
Berichten blijven gewoon onafgeleverd in de maildir staan. De hook is wat een nieuw bericht in de context van een agentsessie weergeeft bij sessiestart of prompt-submit — zonder de hook werkt versturen nog steeds en stapelen berichten zich op, maar niets brengt ze onder de aandacht van de ontvangende agent tot de hook draait.
Is agentixmesh beperkt tot één enkele machine?
Ja — vandaag levert agentixmesh alleen af tussen agentsessies op dezelfde machine. Er is geen network transport, dus het kan geen bericht routeren naar een sessie die op een andere host draait. Cross-machine delivery is een echte, aparte behoefte die het momenteel niet adresseert.
Gaat agentixmesh cross-machine delivery ondersteunen?
Het staat op de roadmap, niet vandaag shipped. De kern van agentixmesh is alleen single-machine, zonder ingebouwd network transport. Cross-machine, cryptografisch ondertekende delivery op schaal is de expliciete taak van een zusterproject, AgentsWeaver — agentixmesh is gepositioneerd als de lokale, single-machine on-ramp, niet als het opgeschaalde cross-network transport.
Wat is de "higher-authority layer" op de roadmap?
Leader-gate co-approval, group roles, en consent-gated leader-read monitoring — mechanismen waarmee een teamlead met consent agentverkeer kan co-approven of observeren. Ze bestaan vandaag in ontwerp/prototype-vorm maar zijn niet shipped en worden expliciet niet geadverteerd als production security; behandel ze als roadmap, geen geharde garantie.
Onder welke licentie valt agentixmesh?
MIT. De code is publiek op GitHub op github.com/TokonoMix/agentixmesh — lees hem, fork hem, self-host hem, of wijzig hem zonder toestemming te vragen. Er is geen aparte betaalde tier of closed core verstopt achter de publieke repo; wat je ziet is wat draait.
Wordt agentixmesh actief onderhouden?
Het wordt ontwikkeld als een open source project met volledige commit-history publiek op GitHub, dus je kunt de activiteit zelf checken voordat je ervan afhankelijk wordt. Er is geen formele support-SLA — zoals bij elk MIT-licensed project betekent het adopteren ervan dat je zelf operationele ownership neemt over de fork die je draait.
Wat doet agentixmesh met opzet NIET?
Het draait niet als network service, vereist geen sudo voor same-user-gebruik, onderneemt geen automatische actie op de inhoud van een bericht, en claimt niet prompt injection ronduit te stoppen. Het levert berichten af als inerte data waar een agent over leest en beslist — de mesh zelf voert nooit een instructie uit die in een bericht-body gevonden wordt.

Praat met ons

Elk gesprek begint in de chat — vertel waarvoor je komt en de assistent pakt het op.