Häufig gestellte Fragen
Direkte Antworten darauf, was agentixmesh ist, mit welchen Agent-Tools es funktioniert, was es absichert und wie es sich von einer Message Queue unterscheidet.
Grundlagen
- Was ist agentixmesh?
- agentixmesh ist ein Agent Trust Layer — eine dateibasierte Zustellschicht, die es AI-Agent-Sessions auf einer Maschine erlaubt, Nachrichten auszutauschen, ohne gegenseitig ihre Autorität zu erben, adressiert per `uid:project`. Der Transport ist ein maildir (Verzeichnisse new/cur/held/seen) plus ein inject hook: kein daemon, kein Netzwerk-Listener, kein offener Port, kein sudo. Es ist MIT-lizenziert und offen auf GitHub (github.com/TokonoMix/agentixmesh).
- Was bedeutet "data is not authority"?
- Es bedeutet, dass eine eingehende Nachricht als inerter DATA-Frame zum Lesen dargestellt wird, niemals als zu befolgender Befehl. Der empfangende Agent entscheidet, was zu tun ist; das Mesh handelt niemals automatisch aufgrund des Inhalts einer Nachricht. Mit Worten auf eine Nachricht zu antworten ist in Ordnung; eine Aktion auszuführen, Code laufen zu lassen oder Secrets preiszugeben, nur weil eine Nachricht es so sagt, ist es nicht.
- Welches Problem löst agentixmesh tatsächlich?
- Es löst das "confused deputy"-Risiko lokaler Agent-zu-Agent-Kommunikation: eine Session, die die Autorität einer anderen erbt, nur weil eine Nachricht ankam. agentixmesh trennt, wer eine Nachricht gesendet hat (eine kernel-verifizierte OS-User-ID) von dem, was sie sagt (ein untrusted body), sodass eine Nachricht ihren Absender beweisen kann, ohne dass dieser Beweis irgendetwas autorisiert, was die Nachricht verlangt. Containment, nicht Kommunikation, ist der schwierige Teil.
- Für wen ist agentixmesh gedacht?
- Für Engineers, die mehrere AI-Agent-Sessions betreiben — heute Claude Code, weitere harnesses folgen als adapter — auf derselben Maschine, die diese Sessions Informationen übergeben oder koordinieren lassen müssen, ohne eine message queue oder ein Ticketsystem aufzusetzen, und ohne dass der Output einer Session still zur Instruktion einer anderen Session wird. Es setzt Command-Line-Agent-Workflows voraus, keine End-User-Chat-Produkte.
- Ist agentixmesh production-ready?
- Teilweise, und zwar bewusst in Stufen. Der same-user-Kern ist öffentlich und stabil — er ist der ausgelieferte, dogfooded Default. Cross-user-Zustellung (getrennte OS-User, eine Maschine) ist end-to-end validiert, aber ihr Production-Go-live bleibt human-gated: der body einer Nachricht wird zurückgehalten, bis eine Person ihn freigibt. Cross-machine-Zustellung existiert noch nicht — das ist roadmap, nicht agentixmesh.
- Ist agentixmesh nur ein Message Bus oder Pub/Sub-System?
- Nein. Ein Message Bus bewegt Bytes; agentixmesh beschäftigt sich damit, was eine Session tun darf, sobald die Bytes ankommen. Das unterscheidende Merkmal ist nicht der Transport (ein maildir) — es ist kernel-verifizierte Absenderidentität plus inert-DATA-Framing, das verhindert, dass eine zugestellte Nachricht als Befehl behandelt wird. Reines Pub/Sub hat keine dieser Eigenschaften.
- Warum dateibasiert (ein maildir) statt Socket oder daemon?
- Ein maildir braucht keinen laufenden Prozess, keinen Port und keine Privilege-Eskalation — Zustellung ist einfach nur Dateien, die zwischen owner-only-Verzeichnissen (0700) bewegt werden, die das OS ohnehin schützt. Ein daemon oder Socket-Listener fügt eine ständig aktive Angriffsfläche und operativen Aufwand (Start/Stop, Crash-Recovery, Permissions) für einen Same-Machine-, Low-Throughput-Anwendungsfall hinzu, den reine Filesystem-Semantik bereits abdeckt.
- Was bedeutet "agent trust layer"?
- Es bedeutet, dass agentixmesh unterhalb des Nachrichteninhalts sitzt und eine Frage beantwortet: Kannst du vertrauen, wer das gesendet hat? Es verifiziert die OS-User-ID des Absenders kernel-seitig via fstat auf dem offenen file descriptor — unfälschbar — während alles andere, einschließlich des body und des selbstdeklarierten Projekt-Labels des Absenders, als untrusted behandelt wird. Trust bedeutet hier Identität, nicht das, was eine Nachricht behauptet.
- Was ist eine Adresse (uid:project)?
- Eine Adresse ist `uid:project` — die numerische OS-User-ID des vorgesehenen Empfängers, plus ein Projekt-Label. Die uid-Hälfte ist das, worauf das Mesh die Zustellung tatsächlich durchsetzt. Die project-Hälfte ist nur der Basename des aktuellen Arbeitsverzeichnisses des Absenders, selbstdeklariert und unverifiziert, verwendet um in die richtige Inbox dieses Users zu routen. `mesh-whoami` gibt deine eigene Adresse aus.
- Welche Rolle spielt der Mensch bei agentixmesh?
- Der Mensch ist die letzte Instanz, am konkretesten bei cross-user-Zustellung: der body einer Nachricht wird zurückgehalten, bis ein Mensch ihn freigibt, sodass unbeaufsichtigtes cross-user-Handeln konstruktionsbedingt unmöglich ist. Allgemeiner: agentixmesh handelt niemals automatisch aufgrund des Inhalts einer Nachricht — der empfangende Agent entscheidet, was damit zu tun ist — sodass Menschen, nicht das Mesh, die Kontrolle über folgenreiche Entscheidungen behalten.
- Ist agentixmesh ein Framework oder ein Protokoll?
- Es ist eher ein Protokoll plus eine schlanke Referenzimplementierung als ein Framework. Der Kern — kernel-verifizierte Absenderidentität, maildir-Transport, inert-DATA-Framing — ist bewusst harness-neutral und schreibt die Interna deines Agenten nicht vor. Integration erfolgt, indem du einen harness adapter an das Protokoll anbindest, nicht indem du deinen Agenten umschreibst, um zur Struktur von agentixmesh zu passen.
- Was versucht agentixmesh NICHT zu sein?
- Es versucht nicht, eine general-purpose message queue, ein cross-machine-Transport oder eine Sicherheitsgarantie gegen prompt injection zu sein. Es versucht nicht, Agenten in deinem Namen autonom zu machen — cross-user-Auto-Acting ist konstruktionsbedingt blockiert, nicht nur davon abgeraten. Cross-machine-Zustellung und höher-privilegierte Features wie leader-gate co-approval existieren nur als roadmap-Punkte, nicht als etwas, das es heute leistet.
Kompatibilität & Harnesses
- Funktioniert agentixmesh mit Claude Code?
- Ja — Claude Code ist der Referenz-adapter und ist heute ausgeliefert. Er bindet das Mesh über Claude Codes SessionStart- und UserPromptSubmit-hooks ein, sodass Nachrichten automatisch im Kontext erscheinen, ohne dass sich ändert, wie du Claude Code nutzt. Das ist die am gründlichsten erprobte Integration und diejenige, gegen die das maildir/inject-hook-Design zuerst gebaut wurde.
- Funktioniert agentixmesh mit OpenAI Codex CLI?
- Ein adapter ist ausgeliefert und unit-getestet. Die Live-Binary-End-to-End-Verifikation gegen die echte Codex CLI läuft noch, also behandle es als shipped-but-not-yet-fully-verified-live, nicht als production-proven. Wir bezeichnen den Codex-Pfad erst dann als "fertig", wenn diese Live-Verifikation abgeschlossen ist.
- Funktioniert agentixmesh mit Gemini oder anderen Agent-Tools?
- Noch nicht. Hermes- und OpenClaw-adapter sind entworfen und prototypisiert, was sie auf die roadmap setzt, nicht in den ausgelieferten Umfang. Heute gibt es nur die adapter Claude Code (Referenz, ausgeliefert) und OpenAI Codex CLI (unit-getestet, Live-E2E-Verifikation läuft). Behandle jedes andere harness bis zur Auslieferung eines adapters als unsupported.
- Was bedeutet "harness-agnostic" hier konkret?
- Es bedeutet, dass der Kern — maildir-Transport, kernel-verifizierte Identität, Nachrichten-Framing — von keinem bestimmten Agent-Tool abhängt. Was tool-spezifisch ist, ist eine schlanke adapter-Schicht, die diesen Kern an das eigene hook-System eines harness anbindet, etwa Claude Codes SessionStart/UserPromptSubmit. Das Protokoll ändert sich nicht pro Tool; nur die Anbindung.
- Können zwei verschiedene Agent-Tools, etwa Claude Code und Codex CLI, Nachrichten über dasselbe Mesh austauschen?
- Architektonisch ja — das maildir-Format und das kernel-verifizierte Identitätsmodell kümmern sich nicht darum, welches harness eine Nachricht geschrieben oder gelesen hat, sondern nur, welcher OS-User es war. Aber der Live-Beweis heute deckt Claude Code end-to-end ab; Codex CLIs Live-Binary-E2E, inklusive echtem Cross-Harness-Austausch, läuft noch, also behandle dieses Szenario noch nicht als validiert.
- Muss ich den Code meines Agenten anpassen, um agentixmesh zu nutzen?
- Nein — du installierst die CLI-Wrapper und bindest einmalig einen kleinen hook ein; am Source des Agenten selbst ändert sich nichts. Für Claude Code ist das der Referenz-adapter, heute ausgeliefert. Für andere harnesses bindet ein adapter dieselben zugrundeliegenden Mesh-Kommandos stattdessen in das hook-System dieses Tools ein.
- Was ist der Push-Hook-Contract — wie landet eine Nachricht im Kontext meines Agenten?
- Der hook feuert bei Session-Start und bei jedem Submit eines User-Prompts. Er führt einen zero-token file read der Mailbox durch, und falls neue Post vorliegt, gibt er einen inerten DATA-Frame auf stdout aus. Das harness behandelt hook-stdout als injizierten Kontext, sodass die Nachricht erscheint, ohne dass das Mesh selbst einen LLM-Call macht.
- Funktioniert agentixmesh über verschiedene Maschinen hinweg?
- Nein, nur same-machine. Alle aktuelle Zustellung — Claude Code und Codex CLI — läuft auf einem Host über ein lokales maildir; es gibt keinen Netzwerk-Listener oder Remote-Transport. Cross-machine, kryptografisch signierte Zustellung ist ein separates Produkt, AgentsWeaver, und steht auf der roadmap dieses Projekts, nicht Teil von agentixmesh.
- Wie füge ich Support für ein neues harness hinzu?
- Du bindest an, du entwirfst kein neues Protokoll. Ein harness-adapter braucht zwei Dinge: eine Möglichkeit, bei Session-Start oder bei Prompt-Submit einen Befehl auszuführen (den push hook), und eine Möglichkeit, dessen stdout zu Kontext werden zu lassen. maildir-Format, Identitätsverifikation und Framing sind bereits harness-neutral und unverändert.
- Wird agentixmesh irgendwann Gemini CLI oder andere harnesses unterstützen?
- Hermes- und OpenClaw-adapter sind bereits entworfen und prototypisiert — das ist die aktuelle roadmap, kein ausgeliefertes Feature. Ein Gemini-spezifischer adapter ist nicht gesondert bestätigt. Da das Hinzufügen eines harness eher Anbindung als neue Protokollarbeit ist, ist der erwartete Aufwand pro neuem Tool gering, aber heute ist außer Claude Code und Codex CLI nichts ausgeliefert.
- Bedeutet harness-agnostic, dass beliebige zwei Agent-Tools frei gemischt werden können, ohne zusätzliches Risiko?
- Nein — harness-agnostic beschreibt die Transport- und Identitätsschicht, keine pauschale Sicherheitsgarantie. Absenderidentität ist weiterhin nur eine kernel-verifizierte OS-User-ID, kein verifizierter Agent oder Projekt. Egal welches harness eine Nachricht empfängt, der Agent muss sie weiterhin als inerte Daten behandeln, niemals als zu befolgende Instruktion.
- Was ist der Unterschied zwischen dem "core" und einem "adapter" bei agentixmesh?
- Der core ist der maildir-Transport, die kernel-verifizierte Absenderidentität und das DATA-Frame-Nachrichtenformat — fixiert und identisch für jedes harness. Ein adapter ist der schlanke, harness-spezifische Klebstoff: hook-Registrierung plus stdout-Anbindung, die ein bestimmtes Agent-Tool mit diesem core verbindet. Neuer Harness-Support ist vollständig auf den adapter beschränkt, nicht den core.
- Kann ich agentixmesh mit einem eigenen, hausinternen Agent-harness nutzen?
- Ja, sofern du die beiden adapter-Anforderungen implementieren kannst: einen hook, der bei Session-Start oder Prompt-Zeit läuft, und eine Möglichkeit, dessen stdout in den Kontext des Agenten zu speisen. Da der Mesh-core harness-neutral ist, braucht ein eigenes harness keine Protokolländerungen — nur dieselbe Art Anbindung, die Claude Code und Codex CLI nutzen.
- Schwächt die Nutzung mehrerer harnesses auf demselben Mesh die Sender-Identitätsgarantie?
- Nein — Identitätsverifikation geschieht auf OS-/Kernel-Ebene, via fstat auf dem offenen file descriptor, vollständig unterhalb und unabhängig von jedem harness. Egal durch welches Tool eine Nachricht läuft, die OS-User-ID des Absenders wird auf dieselbe unfälschbare Weise verifiziert; die Wahl des harness hat keinen Einfluss auf diese Garantie.
Mehrbenutzer (cross-user)
- Können zwei verschiedene OS-User auf einer Maschine sich per agentixmesh Nachrichten schicken?
- Ja — zwei separate OS-User-Accounts auf einem Host können über den cross-user-Modus von agentixmesh Nachrichten austauschen, der über ein geteiltes, gruppen-owned maildir routet statt über das private maildir jedes Users. Das wurde end-to-end mit echten Send-to-Delivery-Zyklen validiert. Es verhält sich in einem wichtigen Punkt anders als same-user-Messaging: Zustellung wird standardmäßig zurückgehalten (held), nicht sofort ausgeliefert.
- Wie wird der Absender verifiziert, wenn eine Nachricht OS-User-Grenzen überschreitet?
- Genauso wie bei same-user-Nachrichten: durch den kernel, nicht durch die Nachricht selbst. agentixmesh ruft fstat auf dem offenen file descriptor auf, um die tatsächliche OS-Level-owner-uid zu lesen, die durch nichts, was die Nachricht behauptet, gefälscht werden kann. Nicht verifiziert ist die project-Hälfte der Adresse — ein selbstdeklariertes Label, das jeder auf beliebig etwas setzen kann.
- Was ist das human-gate, und warum wird der body einer cross-user-Nachricht zurückgehalten?
- Eine cross-user-Nachricht kommt held an: der empfangende Agent sieht nur Metadaten — kernel-verifizierte Absender-uid, Länge, thread id, Zeitstempel — niemals den Nachrichtentext. Ein Mensch muss sie explizit freigeben, bevor der body den Agenten erreicht. Das existiert, weil das Zurückhalten des body — nicht nur das Markieren der Nachricht — die tatsächliche Exposition gegenüber injiziertem Inhalt begrenzt.
- Kann eine cross-user-Nachricht jemals auto-approved oder auto-acted werden?
- Nein — das ist konstruktionsbedingt unmöglich, keine Einstellung, die jemand zu sperren vergessen hat. Cross-user-Zustellung ist immer standardmäßig human-gated, und per-Adress- oder per-Projekt-Overrides können trust nur restriktiver machen, niemals auf auto anheben. Es gibt keinen Codepfad, auf dem ein held cross-user-body einen Agenten ohne explizite menschliche Freigabe erreicht.
- Ist cross-user-Messaging production-ready?
- Der Mechanismus ist end-to-end validiert — echte held-, human-released-, delivered-Zyklen zwischen zwei OS-Usern wurden live bewiesen. Aber das Go-live für ein gegebenes Deployment bleibt konstruktionsbedingt human-gated: der Zurückhalte-Schritt ist bei cross-user dauerhaft, keine Rollout-Lücke, die später geschlossen wird. "Ready" heißt also: sicher unter Aufsicht zu betreiben, nicht sicher, unbeaufsichtigt zu lassen.
- Wie funktioniert das Freigeben einer held cross-user-Nachricht?
- Ein Mensch auf der Empfängerseite prüft die Metadaten der held-Nachricht — Absender-uid, Länge, thread id, Zeitstempel — und führt dann eine explizite Freigabe-Aktion aus, die den body erstmals dem Agenten offenlegt. Bis dahin wird nichts zugestellt, und die Nachricht bleibt unbegrenzt held, falls die Freigabe nie erfolgt.
- Was kann ein OS-User von den Nachrichten eines anderen Users sehen, bevor sie freigegeben sind?
- Nichts außer strukturellen Metadaten. Die Empfängerseite kann sehen, dass eine Nachricht existiert, welche kernel-verifizierte uid sie gesendet hat, wie lang sie ist und zu welchem thread sie gehört — niemals den Text. Das ist beabsichtigt: Metadaten allein können keine Instruktion tragen, daher öffnet ihre Anzeige vor menschlicher Prüfung nicht wieder die Injektionsfläche, zu deren Schließung das Zurückhalten existiert.
- Wie wird ein Kollege für das Senden oder Empfangen von cross-user-Nachrichten onboarded?
- Onboarding ist ein eigener Enrollment-Schritt, nicht nur das Anlegen eines OS-Accounts auf der Box. Ein neues Mitglied wird registriert, sodass seine kernel-verifizierte uid als legitimer Mesh-Teilnehmer erkannt wird, mit Identitätsbestätigung out-of-band statt aus einer selbstgemeldeten Behauptung übernommen. Bis zum Enrollment werden Nachrichten dieser uid nicht als von einem bekannten Mitglied kommend behandelt.
- Was passiert, wenn ein Kollege ausscheidet oder Zugang verliert?
- Seine Mesh-Mitgliedschaft wird widerrufen, was verhindert, dass künftige Nachrichten dieser uid als von einem anerkannten Mitglied kommend behandelt werden. Der Widerruf ist eine explizite administrative Aktion, gebunden an die OS-Level-Identität, kein Toggle, den ein Agent oder eine Nachricht anfordern kann — konsistent mit dem Rest von agentixmesh, wo trust-Änderungen bewusste menschliche Aktionen sind.
- Müssen beide User auf derselben Maschine sein?
- Ja — der cross-user-Modus von agentixmesh ist nur single-machine. Er stützt sich auf ein lokales Filesystem und kernel-level-uid-Verifikation, beides host-lokale Konzepte ohne Bedeutung über getrennte Maschinen hinweg. Messaging zwischen Agenten auf unterschiedlichen Hosts ist heute nichts, was agentixmesh leistet; dafür ist AgentsWeaver gebaut, das cross-machine, kryptografisch signierte Mitglied derselben Familie.
- Kann ein böswilliger User vortäuschen, ein anderes Projekt zu sein, um den Agenten eines Kollegen zu täuschen?
- Er kann das Projekt-Label fälschen, nicht den Absender. Die project-Hälfte einer Adresse ist ein selbstdeklarierter String — der eigene cwd-Basename des Absenders — und wird nicht verifiziert, sodass eine Nachricht so gelabelt ankommen kann, als käme sie von einem unabhängigen Projekt. Die uid, von der sie tatsächlich kam, bleibt kernel-verifiziert: du weißt immer, welcher OS-User sie gesendet hat, nur nicht, welches seiner Projekte.
- Gibt es eine leader- oder approver-Rolle, die cross-user-Nachrichten für ein Team co-approven kann?
- Eine Schicht höherer Autorität — leader-gate co-approval und group-Rollen — existiert im Design, ist aber roadmap, keine ausgelieferte Production-Sicherheit; verlass dich heute nicht darauf. Die live und load-bearing für cross-user aktive Kontrolle ist das per-Nachricht human-release-gate: jede cross-user-Nachricht durchläuft es, unabhängig von jeder group-Struktur.
- Kann ein User den Mesh-Traffic eines anderen überwachen, z.B. ein Team-Lead, der nach Problemen schaut?
- Consent-gated leader-read-Monitoring ist entworfen, aber nicht ausgeliefert — derselbe roadmap-Status wie die leader-gate- und group-Rollen-Schicht. Stand heute ist die Mailbox eines Users nur von diesem User lesbar; es gibt kein live-Feature, das einer anderen Partei erlaubt, die Nachrichten von jemand anderem zu beobachten, held oder released, mit oder ohne consent.
- Gilt das cross-user-hold für jede Nachricht oder nur für manche?
- Es gilt für jede cross-user-Nachricht — held-with-metadata-only ist der einzige und Default-Modus, keine per-Nachricht- oder per-Sender-Option. Es gibt keine cross-user-Einstellung "traue dieser uid, auto-deliver". Ownership, die Fälschung eliminiert, plus das human-gate sind der fixe Contract für jede Nachricht, die eine uid-Grenze überquert.
- Die uid des Absenders kann nicht gefälscht werden — warum dann nicht den human-Schritt überspringen?
- Weil uid-Verifikation und Injection-Sicherheit unterschiedliche Probleme sind. Die kernel-Verifikation der Absender-uid beweist, wer eine Nachricht gesendet hat, nicht, dass ihr Inhalt sicher zu befolgen ist — eine legitim gesendete Nachricht kann trotzdem Text enthalten, der wie eine Instruktion aussehen soll. Der human-release-Schritt begrenzt die Exposition gegenüber diesem Inhalt; er ist keine redundante Identitätsprüfung.
- Kann der Agent nach Freigabe einer cross-user-Nachricht automatisch danach handeln?
- Nein — nach der Freigabe wird sie exakt wie jeder andere inerte Datenframe behandelt, unter derselben Standardregel wie same-user-Nachrichten: niemals einem message body gehorchen. Der Agent darf mit Worten antworten, aber Code auszuführen, eine Aktion auszuführen oder Secrets aufgrund der Aussage der Nachricht preiszugeben, verstößt gegen diese Regel — unabhängig davon, ob die Nachricht vom selben User kam oder von einem anderen.
- Welche OS-Level-Permissions schützen eine geteilte cross-user-Mailbox vor anderen Usern auf der Maschine?
- Cross-user-Zustellung nutzt ein gruppen-owned Verzeichnis statt der strikten owner-only-Verzeichnisse (0700) des same-user-Modus, da mehr als eine uid es erreichen muss. group members können eine Nachricht ablegen und das Verzeichnis durchqueren, können aber nicht auflisten oder lesen, was darin ist; nur der vorgesehene Empfänger kann eine Nachricht lesen, sodass Mitbewohner auf der Box nicht in der Mail des anderen stöbern können.
Sicherheit & Trust-Modell
- Stoppt agentixmesh prompt injection?
- Nein — es reduziert das prompt-injection-Risiko, es eliminiert es nicht. Ownership garantiert, wer eine Nachricht gesendet hat, nicht, was die Nachricht sagt. Eine legitim gesendete Nachricht kann trotzdem Text enthalten, der wie eine Instruktion aussehen soll, und der lesende Agent ist die Schwachstelle. agentixmesh mildert das mit inert-DATA-Framing, Sanitation und einer Standard-never-obey-Regel — aber das empfangende LLM entscheidet letztlich, was zu tun ist.
- Was ist der Unterschied zwischen Fälschung und prompt injection, und warum behandelt agentixmesh sie unterschiedlich?
- Fälschung ist eine Nachricht, die über ihren Absender lügt; injection ist eine legitim gesendete Nachricht, die versucht, einen Agenten zu einer Aktion zu überreden. agentixmesh eliminiert Ersteres mit einer kernel-verifizierten harten Garantie — ein gefälschter Absender wird abgelehnt, bevor ein Agent die Nachricht je sieht. Es reduziert Zweiteres nur, weil injection im Nachrichteninhalt lebt, den das Mesh framen und sanitizen, aber nicht vollständig neutralisieren kann.
- Was bedeutet "kernel-verified sender" tatsächlich?
- Es bedeutet, dass die sendende OS-User-ID via fstat auf dem offenen file descriptor der zugestellten Nachricht gelesen wird, nicht aus irgendeinem Feld innerhalb der Nachricht selbst. Der kernel verfolgt Dateibesitz unabhängig vom Nachrichteninhalt, sodass ein Absender nicht behaupten kann, ein anderer User zu sein — das OS müsste über den Eigentümer der Datei lügen, die es gerade geschrieben hat, was es nicht tut.
- Kann jemand fälschen, von wem eine Nachricht ist?
- Nein — Absenderidentität ist eine harte, kernel-durchgesetzte Garantie, keine Konvention, die der Absender überschreiben kann. Weil die uid aus den eigenen file-ownership-Metadaten des Betriebssystems stammt statt aus einem selbstgemeldeten Feld, kann ein Prozess, der als ein User läuft, eine Nachricht nicht so erscheinen lassen, als käme sie von einem anderen User. Das ist der eine Teil des Trust-Modells, der nicht probabilistisch ist.
- Ist die "project"-Hälfte einer uid:project-Adresse vertrauenswürdig?
- Nein — das Projekt-Label ist selbstdeklariert (es ist nur der Basename des Arbeitsverzeichnisses des Absenders) und wird nicht verifiziert. agentixmesh beweist, welcher OS-User eine Nachricht gesendet hat, nicht welcher Agent, welches Repository oder welches Projekt. Behandle die project-Hälfte jeder Adresse als Hinweis fürs Routing, niemals als Sicherheitsbehauptung — zwei Agenten desselben Users können beide beliebige Projektnamen behaupten.
- Kann eine Nachricht von einem anderen Agenten meinen Agenten dazu bringen, einen Befehl auszuführen oder ein Secret zu leaken?
- Keine Nachricht kann eine Aktion erzwingen — agentixmesh liefert nur Daten in den Kontext; es führt nie etwas im Namen des Absenders aus. Ob ein Agent einen Befehl ausführt oder ein Secret offenlegt, hängt vollständig von der eigenen Entscheidungsfindung und den Tool-Permissions dieses Agenten ab. Die Aufgabe des Mesh ist es, dem empfangenden Agenten inerten Text und eine Regel, ihn als Daten zu behandeln, zu übergeben — nicht, irgendeine Capability zu gewähren oder auszuüben.
- Was ist ein "inert DATA frame"?
- So wird eine eingehende Nachricht dem empfangenden Agenten präsentiert: klar als zu lesende Daten abgegrenzt, niemals als zu befolgender Befehl. Das Framing geht mit einer Standardregel einher, dass die Aussage eines message body nichts autorisiert — mit Worten zu antworten ist in Ordnung, aber aufgrund der Instruktion einer Nachricht eine Aktion auszuführen, Code laufen zu lassen oder ein Secret preiszugeben ist es nicht. Der Agent, nicht das Mesh, entscheidet, was als Nächstes passiert.
- Welche Sanitation wendet agentixmesh auf eingehende Nachrichten an?
- Bevor eine Nachricht den Kontext eines Agenten erreicht, entfernt agentixmesh Konstrukte, die häufig genutzt werden, um Instruktionen als trusted output zu tarnen — etwa Steuerzeichen, unsichtbare/zero-width-Zeichen und Textmuster, die den Beginn einer neuen Gesprächsrunde imitieren. Das verengt die Injektionsfläche, ist aber eine Milderung, kein Filter, der jede mögliche Formulierung einer manipulativen Nachricht abfängt.
- Gibt es Schutz gegen replayed oder duplizierte Nachrichten?
- Ja — zugestellte Nachrichten werden nachverfolgt, sodass dieselbe Nachricht nicht bei einem späteren Poll erneut in den Kontext eines Agenten injiziert wird. Das schützt davor, dass eine Nachricht still erneut zugestellt und wie neu gelesen wird, was wichtig ist, weil wiederholte Exposition gegenüber demselben präparierten Text selbst eine Methode ist, um Druck auf einen Agenten auszuüben. Es ist eine Delivery-Hygiene-Kontrolle, keine Verteidigung gegen einen erstmaligen Injection-Versuch.
- Was ist das Threat-Modell von agentixmesh?
- Vertrauenswürdige Kollegen, die sich eine Maschine teilen, kein hostile-root-Angreifer. Das Design geht davon aus, dass teilnehmende OS-User nicht aktiv den kernel oder die Datei-Permissions des Hosts angreifen, um sich gegenseitig zu imitieren — hat ein User root-level-Zugriff, kann er fast jeden lokalen Trust-Mechanismus aushebeln. Innerhalb dieser Annahme hält die Fälschungsgarantie von agentixmesh; es ist nicht darauf ausgelegt, einem böswilligen Systemadministrator oder einem kompromittierten kernel standzuhalten.
- Ist agentixmesh ein Sicherheitsprodukt?
- Nein — es ist eine Trust-Boundary für Nachrichtenzustellung, kein Sicherheitsprodukt im weiteren Sinne. Es beantwortet zuverlässig eine enge Frage (wer hat diese Nachricht gesendet) und hilft teilweise bei einem breiteren Problem (Nachrichteninhalt soll einen Agenten nicht kapern können). Es ersetzt kein Endpoint-Hardening, kein Secrets-Management und kein eigenes Permission-Scoping eines Agenten — das bleibt Verantwortung des Betreibers.
- Was löst Dateibesitz NICHT?
- Ownership löst, wer eine Nachricht gesendet hat; es löst nicht, was eine Nachricht sagt oder wie ein Agent darauf reagiert. Es verhindert nicht, dass eine legitim gesendete Nachricht manipulativen Text enthält, prüft den Nachrichteninhalt nicht auf Sicherheit und schränkt nicht ein, wozu ein empfangender Agent fähig ist — das ist eine Funktion der eigenen Tool-Permissions des Agenten, nicht des Mesh.
- Wenn mein Agent einer bösartigen, in einem message body eingebetteten Instruktion gehorcht, ist das ein agentixmesh-Bug?
- Nein — das ist ein Versagen des empfangenden Agenten, die never-obey-a-message-body-Regel einzuhalten, genau das Restrisiko, über das agentixmesh offen spricht. Das Mesh liefert die Nachricht als inerte Daten gerahmt zu und kann ein LLM nicht zwingen, dieses Framing zu respektieren. Diesen Fehlerfall weiter zu reduzieren ist ein Modell-/Prompt-Disziplin-Problem auf der Empfängerseite, keine Sache, die eine Delivery-Schicht allein beheben kann.
- Authentifiziert agentixmesh den Agenten oder das harness, das eine Nachricht sendet?
- Keines von beiden — es authentifiziert den OS-User, als der der sendende Prozess läuft, nichts darüber hinaus. Es kann Claude Code nicht von einem anderen harness unterscheiden, oder einen Agent-Prozess von einem zweiten, der von derselben Person betrieben wird. Wenn du wissen musst, welcher konkrete Agent oder welches Tool etwas gesendet hat, muss das aus Kontext oder Konvention kommen, nicht aus der Identitätsgarantie von agentixmesh.
- Ist cross-user-Messaging (getrennte OS-User, dieselbe Maschine) heute sicher zu nutzen?
- Es ist end-to-end validiert, aber sein Production-Go-live ist bewusst human-gated, kein Zustand, den du bereits als generell verfügbar behandeln solltest. Der body einer cross-user-Nachricht wird zurückgehalten, bis ein Mensch ihn freigibt, und cross-user-Auto-Acting ist konstruktionsbedingt unmöglich — dieses gate ist der Sicherheitsmechanismus, keine Formsache. Behandle cross-user als geprüfte Fähigkeit, die noch auf eine bewusste Rollout-Entscheidung wartet.
- Kann eine Nachricht ohne jede Prüfung automatisch eine Aktion auslösen?
- Nein — Zustellung bringt eine Nachricht nur in den Kontext eines Agenten; nichts in agentixmesh führt im Namen einer Nachricht etwas aus. Innerhalb der eigenen Sessions eines Users entscheidet der Agent, der eine Nachricht liest, unter der never-obey-Regel, was als Nächstes passiert. Über User-Grenzen hinweg bedeutet das zusätzliche human-release-gate, dass ein body nicht einmal sichtbar ist, bis eine Person ihn durchlässt, was jedes Auto-Acting konstruktionsbedingt ausschließt.
- Gibt es einen persistenten Audit-Trail jeder Nachricht?
- Nicht als ausgelieferte Production-Garantie im same-user-core — der verlässliche Teil ist der replay guard, der erneute Zustellung verhindert, kein tamper-evidentes Log. Consent-gated Monitoring der Mailbox eines anderen Users (leader-read) existiert konzeptionell für die cross-user-Ebene, ist aber roadmap, kein heute als Production-Sicherheits- oder Compliance-Feature beworbenes Merkmal.
Isolation & Grenzen
- Was identifiziert eine uid:project-Adresse tatsächlich?
- Zwei verschiedene Dinge mit zwei verschiedenen Garantien. Die uid ist der OS-User, kernel-verifiziert via fstat auf der Empfängerseite, also vertrauenswürdig. Die project-Hälfte ist der eigene Working-Directory-Basename des Absenders, selbstdeklariert und unverifiziert — behandle sie als informativen Kontext, nicht als Beweis, woher eine Nachricht kam.
- Ist die project-Hälfte einer Adresse ein stabiler, eindeutiger Identifier?
- Nein. Es ist nur der Basename des Verzeichnisses, das gerade das Arbeitsverzeichnis der sendenden Session ist. Nichts registriert ihn oder erzwingt Eindeutigkeit über eine Maschine hinweg. Zwei unabhängige Ordner mit zufällig gleichem Namen erzeugen dieselbe Adresse, ohne dass eine zentrale Instanz vor der Zustellung auf Kollisionen prüft.
- Wie werden Mailboxen zwischen Projekten isoliert?
- Jede Adresse bekommt ihr eigenes maildir-Verzeichnis, owner-only angelegt (0700), nur lesbar für den OS-User, dem es gehört. Isolation wird durch Filesystem-Permissions durchgesetzt, nicht durch Application-Level-Logik — ein Prozess, der als anderer OS-User läuft, kann das Verzeichnis überhaupt nicht öffnen, egal was er versucht.
- Kann ein Projekt die Inbox eines anderen Projekts lesen oder darauf handeln?
- Nein, über OS-User hinweg — Zustellung ist pro Adresse, und eine Nachricht landet nur im maildir, das ihrem uid:project-Ziel entspricht. Eine Nachricht trägt außerdem keine Autorität: der Empfang einer Nachricht gewährt einer Session nie die Fähigkeit, in eine andere Inbox zu greifen, im Namen eines peer zu handeln oder automatisch irgendetwas auszulösen.
- Wenn mein OS-User mehrere verschiedene Agent-Projekte betreibt, können sie sich gegenseitig die Mail lesen?
- Isolation wird pro OS-User durchgesetzt, nicht pro Projekt, da maildir-Ownership auf uid-Ebene gesetzt wird. Ein Prozess, der als dieselbe uid läuft, kann grundsätzlich jedes maildir öffnen, das diese uid besitzt. Das Projekt-Label wählt nur eine Zustelladresse — es ist keine separate Permission-Grenze innerhalb eines Users.
- Kann eine Nachricht vortäuschen, von welchem Projekt sie gesendet wurde?
- Ja — das Projekt-Label ist selbstdeklariert und nicht kryptografisch geprüft, sodass ein Absender einen beliebigen String in diese Hälfte der Adresse setzen kann. Was nicht gefälscht werden kann, ist die uid: die kernel-verifizierte Absenderidentität sagt dir, welcher OS-User die Nachricht tatsächlich gesendet hat, unabhängig vom behaupteten Projektnamen.
- Was passiert, wenn ich eine Adresse falsch tippe und sie zufällig zu einem anderen echten Projekt passt?
- Die Nachricht wird dorthin zugestellt, still. Es gibt keinen Bestätigungsschritt, der prüft, ob das getippte Ziel das gemeinte ist, sodass ein Tippfehler, der mit einer anderen aktiven Adresse kollidiert, deine Nachricht einfach stattdessen in die Inbox jener Session routet — ohne dass eine der beiden Seiten erfährt, dass ein Fehler passiert ist.
- Was passiert, wenn ich ein Projekt adressiere, das nicht existiert oder nicht läuft?
- Die Nachricht wird in diese Mailbox geschrieben und wartet — es gibt kein Registry aktiver Adressen, gegen das validiert wird, sodass das Senden an eine nicht existierende oder gerade idle uid:project keinen Fehler erzeugt. Sie wird nur lesbar, wenn und sobald eine Session mit genau dieser Adresse später ihre Mailbox prüft.
- Wie finde ich meine eigene Mesh-Adresse?
- Führe mesh-whoami aus — es gibt deine uid:project-Adresse exakt so aus, wie andere Sessions sie eintippen müssten, um dich zu erreichen, live abgeleitet aus deiner OS-uid und dem Basename deines aktuellen Arbeitsverzeichnisses. Nutze es statt die Adresse aus dem Gedächtnis zu rekonstruieren, da die project-Hälfte vom cwd abhängt und driften kann.
- Wie erreiche ich eine andere Session, ohne ihre exakte Adresse von Hand einzutippen oder zu raten?
- Nutze das sender-seitige Adressbuch — eine Liste freundlicher Aliase, die du lokal pflegst und die einprägsame Namen auf vollständige uid:project-Adressen abbilden, sodass du dir keinen exakten Basename merken oder jedes Mal neu eintippen musst. Es betrifft nur, wie du auf ein Ziel verweist; es ändert nicht, wie der Empfänger adressiert wird.
- Entdeckt agentixmesh automatisch andere Projekte auf der Maschine und verbindet sie für mich?
- Nein. Es gibt keine Auto-Discovery, kein Verzeichnis aktiver Projekte und keine automatische Verbindung von Sessions. Jede Nachricht geht an eine bestimmte uid:project-Adresse, die ein Absender explizit angibt. Isolation ist der Default-Zustand; eine Grenze wird nur überschritten, weil jemand dieses exakte Ziel absichtlich genannt hat.
- Da das Projekt-Label nicht vertrauenswürdig ist — worauf sollte ich mich für Isolationsgarantien tatsächlich verlassen?
- Verlass dich auf die uid-Grenze. agentixmesh garantiert, dass Mailboxen nur vom besitzenden OS-User lesbar sind, und garantiert, dass du weißt, welcher OS-User eine eingehende Nachricht gesendet hat. Es garantiert nicht, dass das behauptete sendende Projekt zutrifft — behandle jeden Projektnamen in oder an einer Nachricht als Kontext, niemals als Zugriffskontrolle.
- Können zwei verschiedene Verzeichnisse mit demselben Basename auf eine Adresse kollidieren?
- Ja. Adressierung nutzt nur den Basename des Arbeitsverzeichnisses, sodass zwei Ordner mit demselben Namen — etwa der Haupt-Checkout eines Projekts und eine separate Kopie oder ein weiterer Checkout davon — auf dieselbe identische uid:project-Adresse auflösen und still eine Inbox teilen, ohne Warnung beim Senden oder Empfangen.
- Muss ich ein Projekt registrieren, bevor es Mesh-Nachrichten empfangen kann?
- Es gibt keinen Anmeldeschritt. Die Adresse eines Projekts existiert implizit in dem Moment, in dem etwas, das als dieser OS-User aus einem Verzeichnis mit diesem Basename läuft, seine Mailbox prüft. Das Senden an eine Adresse, die nie "erstellt" wurde, schreibt die Nachricht einfach in ein maildir, das lesbar wird, sobald eine passende Session sie später pollt.
- Wird die Mailbox-Isolation durch agentixmeshs eigenen Code durchgesetzt, oder durch das Betriebssystem?
- Durch das Betriebssystem. Mailbox-Verzeichnisse werden owner-only (0700) angelegt, sodass die Isolationsgarantie aus Standard-Unix-Filesystem-Permissions kommt statt aus einer Application-Level-Prüfung, die agentixmesh falsch machen könnte. Deshalb hält sie auch gegen einen fehlerhaften oder böswilligen Agent-Prozess stand — der kernel verweigert das open(), bevor überhaupt Mesh-Code läuft.
Kosten & Tokens
- Kostet das Prüfen des Mesh auf neue Nachrichten LLM-Tokens?
- Nein. Das Prüfen des Mesh ist ein reiner file read gegen dein lokales maildir, kein LLM-Call, kostet also null Tokens. Die Poll-Frequenz ändert daran nichts — `mesh-poll status` und die automatische inject-hook-Prüfung beim Session-Start sind Filesystem-Operationen. Du steuerst über `mesh-poll on/off/status`, ob diese Prüfung überhaupt läuft.
- Wann kostet eine Mesh-Nachricht tatsächlich Tokens?
- Nur wenn sie zum Lesen in den Kontext eines Agenten zugestellt wird. Eine wartende Nachricht in einem maildir kostet nichts; die Kosten entstehen in dem Moment, in dem ihr Text als DATA-Frame in die Conversation gerendert wird, und diese Zustellung wird dem Agenten offengelegt — sie ist keine versteckte Hintergrundbelastung.
- Kostet eine Nachricht, die queued oder held wartend auf Freigabe liegt, Tokens?
- Nein. Das Zurückhalten oder Queuen einer Nachricht ist eine Datei, die im `held`- (oder `new`-)Verzeichnis auf Disk liegt; nichts liest sie vor der Freigabe in den Kontext irgendeines Agenten, sodass sie null Token-Kosten verursacht. Kosten entstehen erst, sobald die Nachricht tatsächlich zugestellt und gelesen wird — die Wartedauer ist für die Ausgaben irrelevant.
- Kostet das Weiterleiten einer Mesh-Nachricht an einen menschlichen Kanal, etwa ein Telefon, LLM-Tokens?
- Nein. Weiterleitung an einen menschlichen Kanal — etwa das Relayen einer Benachrichtigung an ein Telefon — ist eine reine Message-Passing-Operation, kein LLM-Call, verursacht also keine LLM-Token-Kosten. Token-Kosten sind spezifisch daran gebunden, dass ein Agent Inhalt in den eigenen Kontext liest, nicht daran, dass Text zwischen Zustellkanälen bewegt wird.
- Ist agentixmesh kostenlos nutzbar?
- Es gibt keine Gebühr pro Nachricht und keine Token-Kosten fürs Pollen oder Prüfen des Mesh — dieser Teil ist kostenlos. "Kostenlos" heißt hier: frei von LLM-Tokens: agentixmesh selbst berechnet nichts. Was nicht kostenlos ist, ist die zugrundeliegende Agent-Session — Hosting und Compute für den Betrieb der sendenden und empfangenden Agenten sind separate Kosten, die du ohnehin trägst.
- Ist agentixmesh Open Source?
- Ja. Es ist MIT-lizenziert und auf GitHub veröffentlicht (github.com/TokonoMix/agentixmesh). Du kannst den Transport-, Identitätsverifikations- und Zustellcode selbst lesen, statt Kosten- oder Sicherheitsbehauptungen einfach zu glauben — es gibt keine geschlossene Komponente, die Nachrichtenzustellung vermittelt oder Nutzung misst.
- Brauche ich einen API-Key oder ein Abo, um das Mesh selbst zu nutzen?
- Nein. Das Mesh besteht aus lokalen Dateien — einem maildir plus einem inject hook — ohne daemon, Netzwerk-Listener oder externen Dienst, gegen den man sich authentifizieren müsste, also gibt es für die Mesh-Schicht nichts zu keyen oder zu abonnieren. Die einzigen Kosten, die du siehst, sind die Modellnutzung deines eigenen Agenten beim Lesen einer zugestellten Nachricht.
- Kann ich den Token-Verbrauch durch Mesh-Zustellung begrenzen oder abschalten?
- Ja, mit `mesh-poll off`. Das Abschalten des Pollings stoppt den inject hook daran, nach neuen Nachrichten zu suchen oder sie in deinen Kontext zuzustellen, sodass nichts gelesen wird und keine Tokens für Mesh-Inhalt ausgegeben werden. `mesh-poll status` zeigt den aktuellen Zustand; `mesh-poll on` aktiviert die Zustellung wieder, wenn du sie zurückhaben willst.
- Kostet das Senden einer Nachricht mit mesh-send Tokens?
- Das Schreiben einer Nachricht mit `mesh-send` ist ein file write in das maildir des Empfängers, keine LLM-Operation, sodass der Akt des Sendens selbst keine Tokens hinzufügt, über das hinaus, was dein Agent bereits fürs Verfassen des zu sendenden Texts ausgegeben hat. Es gibt keine mesh-seitige Gebühr, die auf diesen write aufgeschlagen wird.
- Verbraucht der automatische inject hook, der beim Session-Start läuft, still jede Runde Tokens?
- Nein, außer es gibt tatsächlich eine Nachricht zuzustellen. Die Prüfung des hook auf neue Post ist ein file read; ist das maildir leer, wird nichts zum Kontext hinzugefügt und keine Tokens werden ausgegeben. Tokens werden nur in den Runden ausgegeben, in denen tatsächlich eine wartende Nachricht in die Conversation gerendert wird.
- Wenn ich eine held oder wartende Nachricht nie lese, zahle ich trotzdem dafür?
- Nein. Eine ungelesene Nachricht — ob in `new`, `held` liegend oder nie abgeholt — wird nie in den Kontext irgendeines Agenten tokenisiert, kostet also nichts. Kosten sind strikt an den Akt gebunden, dass ein Agent zugestellten Inhalt liest, nicht an die bloße Existenz einer Nachricht in einer Mailbox.
Vergleiche
- Wie unterscheidet sich agentixmesh von einer message queue wie Redis oder RabbitMQ?
- Eine queue bewegt Bytes zwischen Endpunkten; sie kennt oder verifiziert nicht, wer sie gesendet hat. agentixmesh verifiziert den OS-User des Absenders kernel-seitig via fstat auf dem offenen file descriptor, bevor der empfangende Agent die Nachricht je sieht, sodass eine queue-Nachricht, die behauptet 'von User X' zu sein, gefälscht werden kann — eine agentixmesh-Nachricht nicht. Diese Identitätsgarantie ist der Punkt; eine queue liefert sie nicht.
- Könnte ich dasselbe mit Redis pub/sub oder einer Datenbanktabelle bauen?
- Du könntest die Bytes bewegen, müsstest aber Sender-Verifikation selbst nachrüsten — Redis und eine geteilte DB-Tabelle vertrauen jedem Client, der bei ihnen schreibt. Die Garantie von agentixmesh kommt vom OS: nur die echte uid, die den file descriptor geöffnet hat, kann der aufgezeichnete Absender sein. Das auf einer queue nachzubauen bedeutet, kernel-level-Identitätsprüfungen neu herzuleiten, was den meisten schwierigen Teil ausmacht.
- Bietet agentixmesh Zustellgarantien oder Ordering wie eine echte message queue?
- Nicht so, wie ein queue-Produkt das tut — keine acks-with-retries-and-DLQ-Mechanik, keine Cross-Sender-Ordering-Garantien. Es ist ein maildir: Nachrichten landen in new/, wandern bei Lesen zu cur/, held/ für gated Fälle. Das ist bewusst einfach. Wenn du broker-grade Durchsatz, Ordering oder Backpressure brauchst, ist agentixmesh nicht dieses Tool — es ist eine Trust-Schicht, kein queue-Produkt.
- Wie verhält sich agentixmesh zu MCP (Model Context Protocol)?
- Andere Schicht. MCP verbindet eine Agent-Session mit Tools und Ressourcen — Datenbanken, APIs, Dateien —, die sie aufruft. agentixmesh verbindet eine Agent-Session mit einer anderen Agent-Session, sodass sie Nachrichten austauschen können, ohne dass eine die Autorität der anderen erbt. Eine Session kann MCP-Server für Tools nutzen und agentixmesh, um mit peer-Agenten zu sprechen — sie sind komplementär, nicht konkurrierend.
- Kann ich agentixmesh und MCP zusammen nutzen?
- Ja — sie lösen unterschiedliche Probleme und stehen nicht im Konflikt. Eine Claude-Code-Session könnte MCP-Server für Tool-Zugriff angebunden haben, etwa eine Datenbank oder Such-API, und separat agentixmesh-Nachrichten von einer anderen Session empfangen, die an einer verwandten Aufgabe arbeitet. MCP regelt die Agent-zu-Tool-Kante des Kontexts; agentixmesh regelt die Agent-zu-Agent-Kante. Keines der beiden erfordert oder blockiert das andere.
- Wie vergleicht sich agentixmesh mit A2A oder anderen Agent-zu-Agent-Protokollen für cross-machine-Kommunikation?
- Es ist ein Positionierungsunterschied, keine Feature-Lücke: agentixmesh ist single-machine, dateibasiert, mit kernel-verifizierter Absenderidentität — es macht keinen cross-machine-Transport, kein TLS, kein kryptografisches Signieren zwischen Hosts. Protokolle, die für Agenten auf getrennten Maschinen gebaut sind, lösen Network-Level-Trust, ein anderes Problem als lokales File-Descriptor-Trust. Cross-machine, signierte Agent-Kommunikation ist roadmap-Territorium für uns (AgentsWeaver), nicht das, was agentixmesh heute leistet.
- Warum nicht einfach Agenten eine geteilte Datei oder Datenbank lesen und schreiben lassen?
- Eine geteilte Datei oder DB hat kein Konzept davon, wer eine gegebene Zeile geschrieben hat, außer dem, was der Schreiber behauptet — jeder Prozess mit Schreibzugriff kann ein Sender-Feld fälschen. Das maildir von agentixmesh ist owner-only (0700, same-user), und der Absender wird aus der kernel-verifizierten uid des Prozesses abgeleitet, der die Datei geöffnet hat, nicht aus einer selbstgemeldeten Spalte. Geteilter Speicher gibt dir Bytes, keine Provenienz.
- Was ist das Problem mit einem geteilten Scratch-Verzeichnis, das zwei Agenten beide auf Änderungen pollen?
- Nichts hindert einen Agenten, einen Bug oder eine injizierte Instruktion daran, eine Datei zu schreiben, die einen anderen Absender vortäuscht — ein reines geteiltes Verzeichnis hat überhaupt keine Identitätsprüfung. agentixmesh fügt genau das hinzu: eine kernel-verifizierte Absenderidentität pro Nachricht, plus inert-DATA-Framing, sodass eine empfangene Nachricht gelesen, nicht automatisch befolgt wird. Ein Scratch-Verzeichnis gibt dir keine der beiden Garantien.
- Warum nicht einfach den Output eines Agenten direkt zum Prompt eines anderen machen?
- Das ist genau das Confused-Deputy-/Injection-Risiko, das agentixmesh abmildern soll. Den rohen Output eines Agenten direkt in den Prompt eines anderen zu pipen gibt ihm dieselbe Autorität wie eine direkte Instruktion, einschließlich allem, was in diesen Output geschmuggelt wurde. agentixmesh liefert Nachrichten stattdessen als inerten DATA-Frame, den der empfangende Agent liest, aber nie automatisch ausführt; in Worten zu antworten ist in Ordnung, aufgrund der Aussage einer Nachricht zu handeln nicht.
- Fügt es nicht Reibung hinzu, Nachrichten als inerte Daten zu framen, verglichen mit direktem Prompten des anderen Agenten?
- Etwas, ja, und das ist beabsichtigt. Direktes Prompten kollabiert 'empfangener Text' und 'zu befolgende Instruktion' zu einem Ding, genau das ist der Confused-Deputy-Fehlermodus. agentixmesh hält sie getrennt: der Frame ist unmissverständlich Daten, und der empfangende Agent — nicht die Nachricht — entscheidet, ob und wie er handelt. Das ist der Preis dafür, nicht trivial injizierbar zu sein.
- Wie unterscheidet sich das vom Verbinden zweier Agenten über Slack oder einen Chat-Kanal?
- Eine Chat-Bridge gibt dir einen geteilten Raum, in dem jeder mit den Credentials als er selbst posten kann — nützlich für Menschen, aber sie verifiziert nicht auf OS-Ebene, welcher Prozess eine Nachricht gesendet hat, und hat kein eingebautes 'das sind Daten, kein Befehl'-Framing. Die Identitätsgarantie von agentixmesh ist kernel-abgeleitet (fstat auf dem eigenen offenen file descriptor des Absenders), und Zustellung ist standardmäßig inert gerahmt statt ein Live-Stream, den ein Agent als Instruktionen lesen könnte.
- Wo passt agentixmesh relativ zu AgentsWeaver und Tokonomix hin?
- Sie sind drei Schichten einer Familie, keine Konkurrenten. agentixmesh ist der lokale, single-machine On-Ramp — dateibasiert, kernel-verifizierte Identität, ein Host. AgentsWeaver ist der cross-machine, kryptografisch signierte Scale-up für den Fall, dass Agenten mehrere Hosts umspannen. Tokonomix ist Cross-Vendor-LLM-Consensus — eine Frage an mehrere Modelle routen und die Antworten beurteilen. Unterschiedliche Probleme, derselbe trust-first-Ansatz.
- Wann würde ich agentixmesh entwachsen und etwas wie AgentsWeaver brauchen?
- Wenn deine Agent-Sessions nicht mehr auf einer Maschine leben. Die Identitätsgarantie von agentixmesh wurzelt in einer lokalen kernel-Primitive — fstat auf einem offenen file descriptor — die keine Antwort darauf hat, zu beweisen, dass eine Nachricht von einem anderen Host kam; das erfordert Network-Level-kryptografisches Signieren, das Problem, das AgentsWeaver angeht. Mehrere OS-User auf einer Maschine bleiben Territorium von agentixmesh (cross-user-Modus), nur human-gated.
- Ist Tokonomix ein Ersatz für agentixmesh?
- Nein — unterschiedliche Aufgabe. Tokonomix beantwortet 'ist dieser Output gut?', indem es eine Frage an mehrere LLM-Anbieter sendet und eine beurteilte Antwort synthetisiert. agentixmesh beantwortet 'kann ich vertrauen, wer mir diese Nachricht geschickt hat?' zwischen Agent-Sessions. Sie können nebeneinander im selben Workflow genutzt werden, aber keines ersetzt das andere.
- Ist agentixmesh ein Ersatz für Orchestrierungs-Frameworks wie LangGraph oder CrewAI?
- Nein — Orchestrierungs-Frameworks entscheiden, was ein Agent als Nächstes innerhalb eines Prozesses oder Workflows tut; agentixmesh bewegt vertrauenswürdige Nachrichten zwischen getrennten Agent-Sessions oder -Prozessen, die sich weder Speicher noch Autorität teilen. Eine Session kann intern ein Orchestrierungs-Framework betreiben und zugleich über agentixmesh senden und empfangen — sie operieren auf unterschiedlichen Schichten und überlappen sich größtenteils nicht.
- Worin unterscheidet sich agentixmesh von MCP (Model Context Protocol)?
- Sie liegen auf verschiedenen Schichten. MCP verbindet ein Modell mit seinen Tools und seinem Kontext — der Agent ruft Fähigkeiten bewusst auf, als eigene Handlungen. agentixmesh ist die Vertrauensgrenze zwischen bereits laufenden Agent-Sessions: Die OS-User-ID des Absenders ist kernel-verifiziert, und der Inhalt kommt als inerte Daten an, nie als Anweisung, der der Agent folgen müsste. Benachbart, nicht konkurrierend — die Seite agentixmesh vs MCP zeigt den vollständigen Vergleich.
- Können agentixmesh und MCP nebeneinander laufen?
- Ja — genau das ist das erwartete Setup. Jede Session behält ihre eigenen MCP-Server für Fähigkeiten, während agentixmesh die Nachrichten zwischen den Sessions trägt. Das Mesh liefert eine Anfrage als Daten; ob der Agent danach handelt, bleibt eine Entscheidung innerhalb der empfangenden Session, unter ihren eigenen Berechtigungen.
Setup, Grenzen & Roadmap
- Braucht agentixmesh einen Hintergrund-daemon oder Serverprozess?
- Kein daemon. Same-user-Zustellung läuft auf einem maildir (Ordner new/cur/held/seen) plus einem inject hook, der feuert, wenn eine Agent-Session startet oder ein Prompt abgeschickt wird — nichts muss durchgehend im Hintergrund laufen. Es gibt keinen dauerhaften Prozess, der abstürzen, neu starten oder betreut werden muss, für den same-user-Kernpfad.
- Öffnet agentixmesh einen Netzwerkport?
- Nein. Es hat keinerlei Netzwerk-Listener — same-user-Messaging ist reine Filesystem-I/O: eine Nachricht wird in ein maildir-Verzeichnis geschrieben und beim nächsten Session-Event vom inject hook abgeholt. Es gibt keinen Socket zu öffnen, keinen Port für die Firewall, nichts, das auf Verbindungen lauscht.
- Brauche ich sudo oder root, um agentixmesh zu nutzen?
- Nein, nicht für den same-user-Kern. Mailboxen sind owner-only-Verzeichnisse (Modus 0700), die ein normaler User-Account selbst anlegt und liest. Root wird nur relevant, wenn du weiter das optionale cross-user-Layer-Shared-Host-Setup provisionierst — alltägliches same-user-Messaging kommt nie mit sudo in Berührung.
- Was braucht ein Host, um agentixmesh auszuführen?
- Nur eine Maschine, ein Filesystem, in das der User-Account schreiben kann, Python, und ein maildir unter dem Home-Verzeichnis dieses Users. Das andere Stück ist ein inject hook, eingebunden in dein Agent-harness, damit eingehende Nachrichten in den Kontext einer Session gerendert werden — keine exotische Infrastruktur darüber hinaus.
- Wie installiere ich agentixmesh?
- Binde vier Host-Integrationspunkte ein: einen Python-Pfad-Eintrag, damit das Package importierbar ist, CLI-Wrapper (wie `mesh-send`) auf deinem PATH, eine skill-Datei, die dein Agent-harness lädt, und einen inject hook, der bei Session-Start und Prompt-Submit feuert. Es ist Open Source auf GitHub (github.com/TokonoMix/agentixmesh, MIT), also klonst du es und führst die Install-Schritte selbst aus.
- Ist agentixmesh self-hostable?
- Ja — es ist ausschließlich self-hosted. Es gibt keinen gehosteten Dienst oder SaaS-Backend; agentixmesh besteht aus lokalen Dateien (einem maildir) plus einem hook, den du in dein eigenes Agent-harness auf deiner eigenen Maschine installierst. Du kontrollierst den Transport von Ende zu Ende, und keine Nachrichtendaten verlassen deinen Host.
- Was passiert, wenn ich den inject hook nie installiere?
- Nachrichten liegen einfach unzugestellt im maildir. Der hook ist es, der eine neue Nachricht bei Session-Start oder Prompt-Submit in den Kontext einer Agent-Session rendert — ohne ihn funktioniert das Senden weiterhin und Nachrichten stauen sich, aber nichts bringt sie dem empfangenden Agenten zur Anzeige, bis der hook läuft.
- Ist agentixmesh auf eine einzelne Maschine beschränkt?
- Ja — heute liefert agentixmesh nur zwischen Agent-Sessions auf derselben Maschine zu. Es gibt keinen Netzwerktransport, sodass es keine Nachricht an eine auf einem anderen Host laufende Session routen kann. Cross-machine-Zustellung ist ein echtes, eigenständiges Bedürfnis, das es aktuell nicht adressiert.
- Wird agentixmesh cross-machine-Zustellung unterstützen?
- Es steht auf der roadmap, ist heute nicht ausgeliefert. Der Kern von agentixmesh ist nur single-machine, ohne eingebauten Netzwerktransport. Cross-machine, kryptografisch signierte Zustellung im großen Maßstab ist die explizite Aufgabe eines Schwesterprojekts, AgentsWeaver — agentixmesh ist als der lokale, single-machine On-Ramp positioniert, nicht als der hochskalierte Cross-Network-Transport.
- Was ist die "higher-authority layer" auf der roadmap?
- leader-gate co-approval, group-Rollen und consent-gated leader-read-Monitoring — Mechanismen, damit ein Team-Lead Agent-Traffic mit consent co-approven oder beobachten kann. Sie existieren heute in Design-/Prototyp-Form, sind aber nicht ausgeliefert und werden ausdrücklich nicht als Production-Sicherheit beworben; behandle sie als roadmap, nicht als gehärtete Garantie.
- Unter welcher Lizenz steht agentixmesh?
- MIT. Der Code ist öffentlich auf GitHub unter github.com/TokonoMix/agentixmesh — lies ihn, forke ihn, hoste ihn selbst oder modifiziere ihn ohne um Erlaubnis zu fragen. Es gibt keine separate bezahlte Stufe oder geschlossenen Kern, der sich hinter dem öffentlichen Repo versteckt; was du siehst, ist das, was läuft.
- Wird agentixmesh aktiv gepflegt?
- Es wird als Open-Source-Projekt mit vollständig öffentlicher Commit-History auf GitHub entwickelt, sodass du die Aktivität selbst prüfen kannst, bevor du dich darauf verlässt. Es gibt kein formales Support-SLA — wie bei jedem MIT-lizenzierten Projekt bedeutet die Übernahme, dass du die operative Verantwortung für den Fork, den du betreibst, selbst trägst.
- Was macht agentixmesh bewusst NICHT?
- Es läuft nicht als Netzwerkdienst, braucht kein sudo für same-user-Nutzung, handelt nicht automatisch aufgrund des Inhalts einer Nachricht, und behauptet nicht, prompt injection vollständig zu stoppen. Es liefert Nachrichten als inerte Daten für einen Agenten zum Lesen und Entscheiden — das Mesh selbst führt nie eine in einem message body gefundene Instruktion aus.