Preguntas frecuentes
Respuestas directas sobre qué es agentixmesh, con qué herramientas de agentes funciona, qué asegura y en qué se diferencia de una message queue.
Fundamentos
- ¿Qué es agentixmesh?
- agentixmesh es una capa de confianza para agentes (agent trust layer): una capa de entrega basada en archivos que permite que sesiones de agentes de IA en una misma máquina intercambien mensajes sin heredar la autoridad de la otra, direccionadas como `uid:project`. El transporte es un maildir (directorios new/cur/held/seen) más un inject hook: sin daemon, sin listener de red, sin puerto abierto, sin sudo. Tiene licencia MIT y es de código abierto en GitHub (github.com/TokonoMix/agentixmesh).
- ¿Qué significa "los datos no son autoridad"?
- Significa que un mensaje entrante se presenta como un marco de DATA inerte para leer, nunca como una orden a obedecer. El agente receptor decide qué hacer; el mesh nunca actúa automáticamente sobre el contenido de un mensaje. Responder con palabras a un mensaje está bien; realizar una acción, ejecutar código o revelar secretos únicamente porque el cuerpo de un mensaje lo dice, no.
- ¿Qué problema resuelve realmente agentixmesh?
- Resuelve el riesgo de "confused deputy" (delegado confundido) en la mensajería local agente-a-agente: que una sesión herede la autoridad de otra simplemente porque llegó un mensaje. agentixmesh separa quién envió un mensaje (un id de usuario del SO verificado por el kernel) de lo que dice (un cuerpo no confiable), de modo que un mensaje puede demostrar su remitente sin que esa prueba autorice nada de lo que el mensaje pida. La contención, no la comunicación, es la parte difícil.
- ¿Para quién es agentixmesh?
- Para ingenieros que ejecutan múltiples sesiones de agentes de IA —Claude Code hoy, otros harnesses a medida que se publiquen adapters— en la misma máquina, que necesitan que esas sesiones se traspasen información o se coordinen sin montar una message queue o un sistema de tickets, y sin que la salida de una sesión se convierta silenciosamente en instrucciones para otra sesión. Asume flujos de trabajo de agentes de línea de comandos, no productos de chat para usuario final.
- ¿Está agentixmesh listo para producción?
- Parcialmente, y por diseño, en etapas. El núcleo same-user es público y estable: es el valor por defecto publicado y validado mediante dogfooding. La entrega cross-user (usuarios de SO distintos, una máquina) está validada de extremo a extremo, pero su puesta en producción sigue human-gated: el cuerpo de un mensaje se retiene hasta que una persona lo libera. La entrega entre máquinas todavía no existe: eso es roadmap, no agentixmesh.
- ¿Es agentixmesh solo un message bus o un sistema pub/sub?
- No. Un message bus mueve bytes; a agentixmesh le importa qué puede hacer una sesión una vez que llegan esos bytes. La pieza distintiva no es el transporte (un maildir): es la identidad del remitente kernel-verified junto con el framing de DATA inerte, que evita que un mensaje entregado se trate como una orden. Un pub/sub plano no tiene ninguna de las dos propiedades.
- ¿Por qué basado en archivos (un maildir) en vez de un socket o un daemon?
- Un maildir no necesita ningún proceso en ejecución, ningún puerto ni escalada de privilegios: la entrega es simplemente archivos que se mueven entre directorios owner-only (0700) que el SO ya protege. Un daemon o un listener de socket añade una superficie de ataque siempre activa y una carga operativa (arrancar/parar, recuperación de caídas, permisos) para un caso de uso de una sola máquina y bajo throughput que la semántica normal del sistema de archivos ya cubre.
- ¿Qué significa "agent trust layer"?
- Significa que agentixmesh se sitúa por debajo del contenido del mensaje y responde a una sola pregunta: ¿puedes confiar en quién envió esto? Verifica mediante el kernel el id de usuario del SO del remitente vía fstat sobre el file descriptor abierto —infalsificable— mientras trata todo lo demás, incluido el cuerpo y la etiqueta de proyecto autodeclarada del remitente, como no confiable. Aquí la confianza es sobre la identidad, no sobre lo que un mensaje afirma.
- ¿Qué es una dirección (uid:project)?
- Una dirección es `uid:project`: el id numérico de usuario del SO del destinatario previsto, más una etiqueta de proyecto. La mitad uid es sobre lo que el mesh realmente hace cumplir la entrega. La mitad project es solo el basename del directorio de trabajo actual del remitente, autodeclarado y no verificado, usado para enrutar hacia el inbox correcto de ese usuario. `mesh-whoami` imprime tu propia dirección.
- ¿Cuál es el papel del humano en agentixmesh?
- El humano es la autoridad final, de forma más concreta en la entrega cross-user: el cuerpo de un mensaje se retiene hasta que un humano lo libera, de modo que una acción cross-user sin supervisión es imposible por construcción. De forma más general, agentixmesh nunca actúa automáticamente sobre el contenido de un mensaje —el agente receptor decide qué hacer con él—, dejando a las personas, no al mesh, en control de las decisiones con consecuencias.
- ¿Es agentixmesh un framework o un protocolo?
- Está más cerca de ser un protocolo más una implementación de referencia delgada que un framework. El núcleo —identidad del remitente kernel-verified, transporte maildir, framing de DATA inerte— es harness-neutral por diseño y no dicta el funcionamiento interno de tu agente. Te integras conectando un adapter de harness al protocolo, no reescribiendo tu agente para encajar en la estructura de agentixmesh.
- ¿Qué NO intenta ser agentixmesh?
- No intenta ser una message queue de propósito general, un transporte entre máquinas ni una garantía de seguridad contra la inyección de prompts (prompt injection). No intenta hacer que los agentes actúen de forma autónoma en tu nombre: la actuación automática cross-user está bloqueada por diseño, no simplemente desaconsejada. La entrega entre máquinas y funciones de mayor autoridad como la co-aprobación leader-gate existen solo como elementos de roadmap, no como algo que afirme hacer hoy.
Compatibilidad y harnesses
- ¿Funciona agentixmesh con Claude Code?
- Sí. Claude Code es el adapter de referencia y ya está disponible hoy. Conecta el mesh a través de los hooks SessionStart y UserPromptSubmit de Claude Code, de modo que los mensajes aparecen en el contexto automáticamente sin cambiar cómo usas Claude Code. Es la integración más probada en la práctica y la primera contra la que se construyó el diseño maildir/inject hook.
- ¿Funciona agentixmesh con OpenAI Codex CLI?
- Hay un adapter disponible con tests unitarios. La verificación end-to-end contra el binario real de Codex CLI en vivo sigue en curso, así que trátalo como publicado-pero-todavía-no-verificado-en-vivo-por-completo, en lugar de probado en producción. No describiremos la ruta de Codex como "terminada" hasta que esa verificación en vivo se complete.
- ¿Funciona agentixmesh con Gemini u otras herramientas de agentes?
- Todavía no. Los adapters de Hermes y OpenClaw están diseñados y prototipados, lo que los sitúa en el roadmap, no en el conjunto ya publicado. Hoy los únicos adapters son Claude Code (de referencia, publicado) y OpenAI Codex CLI (con tests unitarios, verificación e2e en vivo en curso). Trata cualquier otro harness como no soportado hasta que se publique un adapter.
- ¿Qué significa realmente "harness-agnostic" aquí?
- Significa que el núcleo —transporte maildir, identidad kernel-verified, framing de mensajes— no depende de ninguna herramienta de agente en particular. Lo específico de cada herramienta es una capa de adapter delgada que conecta ese núcleo al propio sistema de hooks del harness, como SessionStart/UserPromptSubmit de Claude Code. El protocolo no cambia según la herramienta; solo cambia el cableado.
- ¿Pueden dos herramientas de agentes distintas, como Claude Code y Codex CLI, intercambiar mensajes en el mismo mesh?
- Arquitectónicamente sí: al formato maildir y al modelo de identidad kernel-verified no les importa qué harness escribió o lee un mensaje, solo qué usuario del SO lo hizo. Pero la prueba en vivo de hoy cubre Claude Code de extremo a extremo; el e2e en vivo de Codex CLI, incluido un intercambio real cross-harness, sigue en curso, así que no trates ese escenario como validado todavía.
- ¿Necesito modificar el código de mi agente para usar agentixmesh?
- No. Instalas los CLI wrappers y conectas un hook pequeño una sola vez; no hay cambios en el código fuente del propio agente. Para Claude Code este es el adapter de referencia, publicado hoy. Para otros harnesses, un adapter conecta los mismos comandos subyacentes del mesh al sistema de hooks de esa herramienta.
- ¿Qué es el contrato de push-hook? ¿Cómo termina un mensaje en el contexto de mi agente?
- El hook se dispara al iniciar la sesión y en cada envío de prompt del usuario. Hace una lectura de archivo del mailbox con coste cero en tokens, y si hay correo nuevo, imprime un marco de DATA inerte en stdout. El harness trata el stdout del hook como contexto inyectado, así que el mensaje aparece sin que el propio mesh haga ninguna llamada a un LLM.
- ¿Funciona agentixmesh entre máquinas distintas?
- No, solo en la misma máquina. Toda la entrega actual —Claude Code y Codex CLI— se ejecuta en un único host a través de un maildir local; no hay listener de red ni transporte remoto. La entrega entre máquinas, firmada criptográficamente, es un producto aparte, AgentsWeaver, y está en el roadmap de ese proyecto, no forma parte de agentixmesh.
- ¿Cómo añado soporte para un harness nuevo?
- Conectas, no diseñas un protocolo nuevo. Un adapter de harness necesita dos cosas: una forma de ejecutar un comando al iniciar la sesión o al enviar un prompt (el push hook), y una forma de que el stdout de ese comando se convierta en contexto. El formato maildir, la verificación de identidad y el framing ya son harness-neutral y no cambian.
- ¿Dará agentixmesh soporte a Gemini CLI u otros harnesses eventualmente?
- Los adapters de Hermes y OpenClaw ya están diseñados y prototipados: eso es el roadmap actual, no una función publicada. Un adapter específico para Gemini no está confirmado por separado. Como añadir un harness es cableado y no trabajo de protocolo nuevo, el esfuerzo esperado por cada herramienta nueva es pequeño, pero hoy no se publica nada más allá de Claude Code y Codex CLI.
- ¿Significa harness-agnostic que dos herramientas de agentes cualesquiera pueden mezclarse libremente sin riesgo añadido?
- No. Harness-agnostic describe la capa de transporte e identidad, no una garantía de seguridad generalizada. La identidad del remitente sigue siendo solo un id de usuario del SO kernel-verified, no un agente o proyecto verificado. Sea cual sea el harness que reciba un mensaje, el agente debe seguir tratándolo como datos inertes, nunca como una instrucción a obedecer.
- ¿Cuál es la diferencia entre el "core" y un "adapter" en agentixmesh?
- El core es el transporte maildir, la identidad del remitente kernel-verified y el formato de mensaje en marco DATA: fijo e idéntico para todos los harnesses. Un adapter es el pegamento delgado y específico del harness: el registro de hooks más el cableado del stdout que conecta una herramienta de agente concreta a ese core. El soporte de un harness nuevo se limita por completo al adapter, no al core.
- ¿Puedo usar agentixmesh con un harness de agente propio, hecho a medida?
- Sí, si puedes implementar los dos requisitos del adapter: un hook que se ejecute al iniciar la sesión o al enviar un prompt, y una forma de introducir el stdout de ese hook en el contexto del agente. Como el core del mesh es harness-neutral, un harness a medida no necesita cambios de protocolo, solo el mismo tipo de cableado que usan Claude Code y Codex CLI.
- ¿Usar varios harnesses en el mismo mesh debilita la garantía de identidad del remitente?
- No. La verificación de identidad ocurre a nivel del SO/kernel, mediante fstat sobre el file descriptor abierto, completamente por debajo de cualquier harness e independiente de él. Sea cual sea la herramienta por la que pase un mensaje, el id de usuario del SO del remitente se verifica de la misma manera infalsificable; la elección de harness no afecta a esa garantía.
Multiusuario (cross-user)
- ¿Pueden dos usuarios de SO distintos en una misma máquina enviarse mensajes con agentixmesh?
- Sí. Dos cuentas de usuario de SO distintas en un mismo host pueden intercambiar mensajes a través del modo cross-user de agentixmesh, que enruta a través de un maildir compartido y propiedad de un grupo, en lugar del maildir privado de cada usuario. Esto se ha validado de extremo a extremo con ciclos reales de envío a entrega. Se comporta de forma distinta a la mensajería same-user en un aspecto clave: la entrega se retiene (held) por defecto, no es inmediata.
- ¿Cómo se verifica al remitente cuando un mensaje cruza los límites entre usuarios del SO?
- De la misma forma que los mensajes same-user: el kernel, no el mensaje en sí. agentixmesh llama a fstat sobre el file descriptor abierto para leer el uid propietario real a nivel de SO, que no puede falsificarse con nada que el mensaje afirme. Lo que no se verifica es la mitad project de la dirección: una etiqueta autodeclarada que cualquiera puede fijar a lo que quiera.
- ¿Qué es el human-gate, y por qué se retiene el cuerpo de un mensaje cross-user?
- Un mensaje cross-user llega retenido (held): el agente receptor solo ve metadatos —uid del remitente kernel-verified, longitud, id de hilo, timestamp— nunca el texto del cuerpo. Un humano debe liberarlo (release) explícitamente antes de que el cuerpo llegue al agente. Esto existe porque retener el cuerpo, y no simplemente marcar el mensaje, es lo que realmente limita la exposición a contenido inyectado.
- ¿Puede un mensaje cross-user llegar a aprobarse automáticamente o a actuarse automáticamente sobre él?
- No. Esto es imposible por construcción, no un ajuste que alguien olvidó bloquear. La entrega cross-user siempre tiene por defecto human-gated, y las anulaciones por dirección o por proyecto solo pueden hacer la confianza más restrictiva, nunca elevarla a auto. No existe ninguna ruta de código en la que un cuerpo cross-user retenido llegue a un agente sin una liberación humana explícita.
- ¿Está la mensajería cross-user lista para producción?
- El mecanismo está validado de extremo a extremo: se han probado en vivo ciclos reales de retención, liberación humana y entrega entre dos usuarios del SO. Pero la puesta en producción de un despliegue concreto sigue siendo human-gated por diseño: el paso de retención es permanente para cross-user, no una carencia de despliegue que se vaya a cerrar más adelante. Así que "listo" significa seguro para ejecutar bajo supervisión, no seguro para dejar sin supervisión.
- ¿Cómo funciona liberar un mensaje cross-user retenido?
- Un humano en el lado receptor revisa los metadatos del mensaje retenido —uid del remitente, longitud, id de hilo, timestamp— y luego realiza una acción de liberación explícita que revela el cuerpo al agente por primera vez. Nada se entrega antes de ese paso, y el mensaje permanece retenido indefinidamente si la liberación nunca ocurre.
- ¿Qué puede ver un usuario del SO de los mensajes de otro usuario antes de que se liberen?
- Nada más que metadatos estructurales. El lado receptor puede ver que un mensaje existe, qué uid kernel-verified lo envió, cuánto mide y a qué hilo pertenece, nunca el texto. Esto es deliberado: los metadatos por sí solos no pueden transportar una instrucción, así que mostrarlos antes de la revisión humana no reabre la superficie de inyección que el hold existe para cerrar.
- ¿Cómo se da de alta (onboard) a un colega para enviar o recibir mensajes cross-user?
- El onboarding es un paso de enrollment dedicado, no solo crear una cuenta de SO en la máquina. Se registra a un nuevo miembro para que su uid kernel-verified se reconozca como un participante legítimo del mesh, con la identidad confirmada fuera de banda (out-of-band) en lugar de tomarla de una afirmación autodeclarada. Hasta que está enrolled, los mensajes de ese uid no se tratan como provenientes de un miembro conocido.
- ¿Qué ocurre cuando un colega se va o pierde el acceso?
- Se revoca su membresía en el mesh, lo que hace que los mensajes futuros de ese uid dejen de tratarse como provenientes de un miembro reconocido. La revocación es una acción administrativa explícita ligada a la identidad a nivel de SO, no un interruptor que cualquier agente o mensaje pueda solicitar, en consonancia con el resto de agentixmesh, donde los cambios de confianza son acciones humanas deliberadas.
- ¿Ambos usuarios tienen que estar en la misma máquina?
- Sí. El modo cross-user de agentixmesh es solo de una única máquina. Depende de un sistema de archivos local y de la verificación de uid a nivel de kernel, ambos conceptos locales al host y sin sentido entre máquinas distintas. La mensajería entre agentes en hosts distintos no es algo que agentixmesh haga hoy; para eso está construido AgentsWeaver, el miembro de la misma familia entre máquinas y firmado criptográficamente.
- ¿Puede un usuario malicioso fingir ser un proyecto distinto para engañar al agente de un colega?
- Puede falsificar la etiqueta de proyecto, no al remitente. La mitad project de una dirección es una cadena autodeclarada —el basename del cwd del propio remitente— y no se verifica, así que un mensaje puede llegar etiquetado como si viniera de un proyecto sin relación. El uid del que realmente provino sigue siendo kernel-verified: siempre sabes qué usuario del SO lo envió, solo no cuál de sus proyectos.
- ¿Existe un rol de líder o aprobador que pueda co-aprobar mensajes cross-user para un equipo?
- Existe una capa de mayor autoridad —co-aprobación leader-gate y roles de grupo— en el diseño, pero es roadmap, no seguridad de producción publicada; no confíes en ella hoy. El control que está en vivo y es load-bearing para cross-user es el gate de liberación humana por mensaje: todo mensaje cross-user pasa por él independientemente de cualquier estructura de grupo.
- ¿Puede un usuario monitorizar el tráfico del mesh de otro usuario, por ejemplo un líder de equipo vigilando problemas?
- La monitorización leader-read con consent-gate está diseñada pero no publicada: el mismo estado de roadmap que la capa de leader-gate y roles de grupo. Tal como están las cosas, el mailbox de un usuario solo puede leerlo ese usuario; no existe ninguna función en vivo que permita a otra parte observar los mensajes de otra persona, retenidos o liberados, con o sin consentimiento.
- ¿El hold cross-user se aplica a todos los mensajes, o solo a algunos?
- Se aplica a todo mensaje cross-user: retenido-con-solo-metadatos es el modo por defecto y único, no una opción por mensaje o por remitente. No existe ningún ajuste cross-user de "confía en este uid, entrega automáticamente". La propiedad de archivo eliminando la falsificación más el gate humano es el contrato fijo para cualquier mensaje que cruce un límite de uid.
- El uid del remitente no se puede falsificar, entonces ¿por qué no saltarse el paso humano?
- Porque la verificación del uid y la seguridad frente a inyección son problemas distintos. Verificar mediante el kernel el uid del remitente demuestra quién envió un mensaje, no que su contenido sea seguro para actuar sobre él: un mensaje enviado legítimamente aún puede contener texto elaborado para parecer una instrucción. El paso de liberación humana limita la exposición a ese contenido; no es una comprobación de identidad redundante.
- Una vez que se libera un mensaje cross-user, ¿puede el agente actuar sobre él automáticamente?
- No. Una vez liberado, se maneja exactamente como cualquier otro marco de datos inertes, bajo la misma regla permanente que los mensajes same-user: nunca obedecer el cuerpo de un mensaje. El agente puede responder con palabras, pero ejecutar código, realizar una acción o revelar secretos porque el mensaje lo diga va contra esa regla, sin importar si el mensaje vino del mismo usuario o de otro distinto.
- ¿Qué permisos a nivel de SO protegen un mailbox compartido cross-user de otros usuarios de la máquina?
- La entrega cross-user usa un directorio propiedad de un grupo en lugar de los directorios estrictamente owner-only (0700) del modo same-user, ya que más de un uid necesita alcanzarlo. Los miembros del grupo pueden depositar un mensaje y atravesar el directorio, pero no pueden listar ni leer lo que hay dentro; solo el receptor previsto puede leer un mensaje, así que los co-inquilinos de la máquina no pueden hojear el correo de los demás.
Seguridad y modelo de confianza
- ¿Detiene agentixmesh la inyección de prompts (prompt injection)?
- No: reduce el riesgo de prompt injection, no lo elimina. La propiedad del archivo garantiza quién envió un mensaje, no lo que el mensaje dice. Un mensaje enviado legítimamente aún puede contener texto elaborado para parecer una instrucción, y el agente que lo lee es el punto débil. agentixmesh mitiga esto con framing de DATA inerte, sanitización y una regla permanente de nunca-obedecer, pero en última instancia el LLM receptor decide qué hacer.
- ¿Cuál es la diferencia entre falsificación (forgery) e inyección de prompts, y por qué agentixmesh las trata de forma distinta?
- La falsificación es un mensaje que miente sobre quién lo envió; la inyección es un mensaje enviado legítimamente que intenta convencer a un agente de realizar una acción. agentixmesh elimina la primera con una garantía dura kernel-verified: un remitente falsificado se rechaza antes de que un agente llegue siquiera a ver el mensaje. Solo reduce la segunda, porque la inyección vive en el contenido del mensaje, que el mesh puede enmarcar y sanitizar, pero no neutralizar por completo.
- ¿Qué significa realmente "kernel-verified sender"?
- Significa que el id de usuario del SO remitente se lee mediante fstat sobre el file descriptor abierto del mensaje entregado, no de ningún campo dentro del propio mensaje. El kernel rastrea la propiedad de los archivos con independencia del contenido del mensaje, así que un remitente no puede afirmar ser otro usuario: el SO tendría que mentir sobre quién es dueño del archivo que acaba de escribir, y eso no lo hace.
- ¿Puede alguien falsificar de quién es un mensaje?
- No. La identidad del remitente es una garantía dura, impuesta por el kernel, no una convención que el remitente pueda anular. Como el uid proviene de los propios metadatos de propiedad de archivo del sistema operativo, y no de un campo autodeclarado, un proceso que se ejecuta como un usuario no puede hacer que un mensaje parezca venir de otro usuario. Es la única parte del modelo de confianza que no es probabilística.
- ¿Es fiable la mitad "project" de una dirección uid:project?
- No. La etiqueta project es autodeclarada (es solo el basename del directorio de trabajo del remitente) y no se verifica. agentixmesh demuestra qué usuario del SO envió un mensaje, no qué agente, repositorio o proyecto lo envió. Trata la mitad project de cualquier dirección como una pista de enrutamiento, nunca como una afirmación de seguridad: dos agentes ejecutados por el mismo usuario pueden reclamar el nombre de proyecto que quieran.
- ¿Puede un mensaje de otro agente hacer que mi agente ejecute un comando o filtre un secreto?
- Ningún mensaje puede forzar una acción: agentixmesh solo entrega datos al contexto; nunca ejecuta nada en nombre del remitente. Que un agente ejecute un comando o revele un secreto depende por completo de la propia toma de decisiones y de los permisos de herramientas de ese agente. El trabajo del mesh es entregar al agente receptor texto inerte y una regla para tratarlo como datos, no conceder ni ejercer ninguna capacidad.
- ¿Qué es un "marco de DATA inerte" (inert DATA frame)?
- Es la forma en que un mensaje entrante se presenta al agente receptor: claramente delimitado como datos para leer, nunca como una orden a obedecer. El framing va emparejado con una regla permanente según la cual lo que diga el cuerpo de un mensaje no autoriza nada: responder con palabras está bien, pero realizar una acción, ejecutar código o revelar un secreto por instrucción de un mensaje, no. El agente, no el mesh, decide qué pasa después.
- ¿Qué sanitización aplica agentixmesh a los mensajes entrantes?
- Antes de que un mensaje llegue al contexto de un agente, agentixmesh elimina construcciones usadas habitualmente para disfrazar instrucciones como salida de confianza —cosas como caracteres de control, caracteres invisibles/zero-width, y patrones de texto que imitan el inicio de un nuevo turno conversacional. Esto reduce la superficie de inyección, pero es una mitigación, no un filtro capaz de detectar cualquier posible formulación de un mensaje manipulador.
- ¿Existe protección contra mensajes repetidos (replay) o duplicados?
- Sí. Se hace seguimiento de los mensajes entregados para que el mismo mensaje no se reinyecte en el contexto de un agente en un poll posterior. Esto protege contra que un mensaje se vuelva a entregar y a leer silenciosamente como si fuera nuevo, lo cual importa porque la exposición repetida al mismo texto elaborado es en sí misma una forma de presionar a un agente. Es un control de higiene de entrega, no una defensa contra un primer intento de inyección.
- ¿Cuál es el modelo de amenazas de agentixmesh?
- Colegas de confianza compartiendo una máquina, no un adversario hostil con acceso root. El diseño asume que los usuarios del SO participantes no están atacando activamente el kernel del host ni los permisos de archivos para suplantarse entre sí; si un usuario tiene acceso a nivel root, puede vencer casi cualquier mecanismo de confianza local. Dentro de ese supuesto, la garantía anti-falsificación de agentixmesh se sostiene; no está diseñada para sobrevivir a un administrador de sistemas malicioso o a un kernel comprometido.
- ¿Es agentixmesh un producto de seguridad?
- No. Es un límite de confianza (trust boundary) para la entrega de mensajes, no un producto de seguridad en el sentido amplio. Responde de forma fiable a una pregunta acotada (quién envió este mensaje) y ayuda parcialmente con un problema más amplio (que el contenido de un mensaje no secuestre a un agente). No sustituye el hardening de endpoints, la gestión de secretos ni el propio scoping de permisos de un agente: eso sigue siendo responsabilidad del operador.
- ¿Qué NO resuelve la propiedad de archivos (file ownership)?
- La propiedad de archivo resuelve quién envió un mensaje; no resuelve lo que el mensaje dice ni cómo reacciona un agente ante él. No impide que un mensaje enviado legítimamente contenga texto manipulador, no valora la seguridad del contenido del mensaje, y no restringe lo que un agente receptor es capaz de hacer: eso es función de los propios permisos de herramientas del agente, no del mesh.
- Si mi agente obedece una instrucción maliciosa incrustada en el cuerpo de un mensaje, ¿es eso un bug de agentixmesh?
- No. Eso es que el agente receptor no respeta la regla de nunca-obedecer-el-cuerpo-de-un-mensaje, que es exactamente el riesgo residual del que agentixmesh es transparente. El mesh entrega el mensaje enmarcado como datos inertes y no puede forzar a un LLM a respetar ese framing. Reducir aún más este modo de fallo es un problema de disciplina de modelo/prompt en el lado receptor, no algo que una capa de entrega pueda arreglar por sí sola.
- ¿Autentica agentixmesh al agente o al harness que envía un mensaje?
- Ninguno de los dos: autentica al usuario del SO como el que se ejecuta el proceso emisor, nada más allá de eso. No puede distinguir Claude Code de otro harness, ni un proceso de agente de un segundo ejecutado por la misma persona. Si necesitas saber qué agente o herramienta concretos enviaron algo, eso debe venir del contexto o de una convención, no de la garantía de identidad de agentixmesh.
- ¿Es seguro usar hoy la mensajería cross-user (usuarios de SO distintos, misma máquina)?
- Está validada de extremo a extremo, pero su puesta en producción es intencionadamente human-gated, no algo que debas tratar todavía como disponible con carácter general. El cuerpo de un mensaje cross-user se retiene hasta que un humano lo libera, y la actuación automática cross-user es imposible por construcción: ese gate es el mecanismo de seguridad, no una formalidad. Trata cross-user como una capacidad revisada que aún espera una decisión deliberada de despliegue.
- ¿Puede un mensaje disparar automáticamente una acción sin ninguna revisión?
- No. La entrega solo pone un mensaje en el contexto de un agente; nada en agentixmesh ejecuta en nombre de un mensaje. Dentro de las propias sesiones de un mismo usuario, el agente que lee un mensaje decide qué hacer a continuación bajo la regla de nunca-obedecer. Entre usuarios, el gate adicional de liberación humana implica que un cuerpo ni siquiera es visible hasta que una persona lo deja pasar, lo que descarta cualquier actuación automática por construcción.
- ¿Existe un rastro de auditoría persistente de cada mensaje?
- No como garantía publicada y de producción en el núcleo same-user: la parte fiable es el replay guard que evita la reentrega, no un log a prueba de manipulaciones (tamper-evident). La monitorización con consent-gate del mailbox de otro usuario (leader-read) existe por diseño para el nivel cross-user, pero es roadmap, no algo que se anuncie hoy como función de seguridad o cumplimiento de producción.
Aislamiento y límites
- ¿Qué identifica realmente una dirección uid:project?
- Dos cosas distintas con dos garantías distintas. El uid es el usuario del SO, verificado por el kernel mediante fstat en el lado receptor, así que se puede confiar en él. La mitad project es el basename del propio directorio de trabajo del remitente, autodeclarado y no verificado: trátalo como contexto informativo, no como prueba de dónde vino un mensaje.
- ¿Es la mitad project de una dirección un identificador estable y único?
- No. Es solo el basename del directorio que resulte ser el directorio de trabajo de la sesión emisora. Nada lo registra ni impone unicidad en toda la máquina. Dos carpetas sin relación que coincidan en el nombre producen la dirección idéntica, sin ninguna autoridad central que compruebe colisiones antes de la entrega.
- ¿Cómo se aíslan los mailboxes entre proyectos?
- Cada dirección obtiene su propio directorio maildir creado owner-only (0700), legible solo por el usuario del SO que es su propietario. El aislamiento lo impone los permisos del sistema de archivos, no lógica a nivel de aplicación: un proceso que se ejecuta como un usuario del SO distinto no puede abrir el directorio en absoluto, sin importar lo que intente.
- ¿Puede un proyecto leer o actuar sobre el inbox de otro proyecto?
- No, entre usuarios del SO: la entrega es por dirección, y un mensaje aterriza solo en el maildir que coincide con su destino uid:project. Además, un mensaje no lleva ninguna autoridad: recibir uno nunca otorga a una sesión la capacidad de acceder a otro inbox, actuar en nombre de un par, o disparar nada automáticamente.
- Si mi usuario del SO ejecuta varios proyectos de agentes distintos, ¿pueden leerse el correo entre ellos?
- El aislamiento se impone por usuario del SO, no por proyecto, ya que la propiedad del maildir se fija a nivel de uid. Un proceso que se ejecuta como ese mismo uid puede, en principio, abrir cualquier maildir del que ese uid sea propietario. La etiqueta project solo selecciona una dirección de entrega; no es un límite de permisos independiente dentro de un mismo usuario.
- ¿Puede un mensaje falsificar desde qué proyecto se envió?
- Sí. La etiqueta project es autodeclarada y no se comprueba criptográficamente, así que un remitente puede poner en esa mitad de la dirección la cadena que quiera. Lo que no se puede falsificar es el uid: la identidad del remitente kernel-verified te dice qué usuario del SO envió realmente el mensaje, con independencia del nombre de proyecto declarado.
- ¿Qué pasa si escribo mal una dirección y resulta que coincide con otro proyecto real?
- El mensaje se entrega ahí, silenciosamente. No hay ningún paso de confirmación que compruebe si el destino que escribiste es el que querías, así que una errata que coincide con otra dirección activa simplemente enruta tu mensaje al inbox de esa otra sesión, sin que nada le indique a ninguna de las dos partes que ha ocurrido un error.
- ¿Qué pasa si direcciono a un proyecto que no existe o no está en ejecución?
- El mensaje se escribe en ese mailbox y espera; no hay ningún registro de direcciones activas contra el que validar, así que enviar a un uid:project inexistente o actualmente inactivo no produce ningún error. Se vuelve legible solo si, y cuando, una sesión con exactamente esa dirección revisa más tarde su mailbox.
- ¿Cómo encuentro mi propia dirección de mesh?
- Ejecuta mesh-whoami: imprime tu dirección uid:project exactamente como otras sesiones necesitarían escribirla para alcanzarte, derivada en vivo de tu uid del SO y del basename de tu directorio de trabajo actual. Úsalo en lugar de reconstruir la dirección de memoria, ya que la mitad project depende del cwd y puede cambiar.
- ¿Cómo alcanzo a otra sesión sin escribir a mano o adivinar su dirección exacta?
- Usa la libreta de direcciones del lado emisor: una lista de alias amigables que mantienes localmente y que mapean nombres memorables a direcciones uid:project completas, para que no tengas que recordar o volver a escribir un basename exacto cada vez. Solo afecta a cómo te refieres a un destino; no cambia cómo se direcciona al destinatario.
- ¿Descubre agentixmesh automáticamente otros proyectos en la máquina y los conecta por mí?
- No. No hay auto-discovery, ni directorio de proyectos activos, ni conexión automática de sesiones. Todo mensaje va a una dirección uid:project específica que un remitente indica explícitamente. El aislamiento es el estado por defecto; un límite solo se cruza porque alguien nombró ese destino exacto a propósito.
- Dado que la etiqueta project no es fiable, ¿en qué debería confiar realmente para las garantías de aislamiento?
- Confía en el límite del uid. agentixmesh garantiza que los mailboxes solo son legibles por el usuario del SO propietario y garantiza que sabes qué usuario del SO envió un mensaje entrante. No garantiza que el proyecto emisor declarado sea exacto: trata cualquier nombre de proyecto dentro o adjunto a un mensaje como contexto, nunca como control de acceso.
- ¿Pueden dos directorios distintos con el mismo basename colisionar en una única dirección?
- Sí. El direccionamiento usa solo el basename del directorio de trabajo, así que dos carpetas cualesquiera que compartan nombre —por ejemplo el checkout principal de un proyecto y una copia o checkout aparte de él en otro lugar— se resuelven en la dirección uid:project idéntica y comparten silenciosamente un inbox, sin ninguna advertencia en el momento de enviar o recibir.
- ¿Necesito registrar un proyecto antes de que pueda recibir mensajes de mesh?
- No existe ningún paso de registro. La dirección de un proyecto existe implícitamente en el momento en que algo que se ejecuta como ese usuario del SO, desde un directorio con ese basename, revisa su mailbox. Enviar a una dirección que nunca se ha "creado" simplemente escribe el mensaje en un maildir, que se vuelve legible en cuanto una sesión coincidente lo consulta (poll) más adelante.
- ¿El aislamiento de mailbox lo impone el propio código de agentixmesh, o el sistema operativo?
- Por el sistema operativo. Los directorios de mailbox se crean owner-only (0700), así que la garantía de aislamiento proviene de los permisos estándar del sistema de archivos Unix, no de una comprobación a nivel de aplicación que agentixmesh pudiera hacer mal. Por eso también se sostiene frente a un proceso de agente con bugs o malicioso: el kernel rechaza el open() antes de que se ejecute ningún código del mesh.
Coste y tokens
- ¿Comprobar el mesh en busca de mensajes nuevos cuesta tokens de LLM?
- No. Comprobar el mesh es una simple lectura de archivo contra tu maildir local, no una llamada a un LLM, así que cuesta cero tokens. La frecuencia de polling no cambia eso: `mesh-poll status` y la comprobación automática del inject hook al iniciar sesión son operaciones del sistema de archivos. Tú controlas si esta comprobación se ejecuta siquiera mediante `mesh-poll on/off/status`.
- ¿Cuándo cuesta realmente tokens un mensaje de mesh?
- Solo cuando se entrega en el contexto de un agente para que lo lea. Un mensaje pendiente que reposa en un maildir no cuesta nada; el coste aparece en el momento en que su texto se renderiza como un marco de DATA en la conversación, y esa entrega se le comunica al agente: no es un cargo oculto en segundo plano.
- ¿Cuesta tokens un mensaje que está en cola o retenido mientras espera la liberación?
- No. Retener o encolar un mensaje es un archivo que reposa en disco en el directorio `held` (o `new`); nada lo lee hacia el contexto de ningún agente hasta la liberación, así que no acumula ningún coste en tokens. El coste solo empieza una vez que el mensaje realmente se entrega y se lee; la duración en cola es irrelevante para el gasto.
- ¿Cuesta tokens de LLM reenviar un mensaje de mesh a un canal humano, como un teléfono?
- No. Reenviar a un canal humano —por ejemplo, retransmitir una notificación a un teléfono— es una simple operación de paso de mensajes, no una llamada a un LLM, así que no genera ningún coste en tokens de LLM. El coste en tokens está ligado específicamente a que un agente lea contenido hacia su propio contexto, no a mover texto entre canales de entrega.
- ¿Es gratis usar agentixmesh?
- No hay ninguna tarifa por mensaje ni coste en tokens por hacer poll o comprobar el mesh: esa parte es gratis. "Gratis" aquí significa libre de tokens de LLM: agentixmesh en sí no cobra nada. Lo que no es gratis es la sesión de agente subyacente: el hosting y el cómputo para ejecutar los agentes que envían y reciben son un coste aparte que ya pagas.
- ¿Es agentixmesh de código abierto?
- Sí. Tiene licencia MIT y está publicado en GitHub (github.com/TokonoMix/agentixmesh). Puedes leer tú mismo el código de transporte, verificación de identidad y entrega, en lugar de dar por buenas de fe las afirmaciones de coste o seguridad: no hay ningún componente cerrado mediando la entrega de mensajes o midiendo el uso.
- ¿Necesito una API key o una suscripción para usar el mesh en sí?
- No. El mesh es archivos locales —un maildir más un inject hook— sin daemon, sin listener de red ni servicio externo contra el que autenticarse, así que no hay nada que dar de alta con una key ni a lo que suscribirse para la capa del mesh. El único coste que verás es el uso del modelo de tu propio agente cuando lee un mensaje entregado.
- ¿Puedo limitar o desactivar el gasto en tokens por la entrega del mesh?
- Sí, con `mesh-poll off`. Desactivar el polling hace que el inject hook deje de comprobar o entregar mensajes nuevos en tu contexto, así que no se lee nada y no se gastan tokens en contenido del mesh. `mesh-poll status` muestra el estado actual; `mesh-poll on` reactiva la entrega cuando quieras recuperarla.
- ¿Cuesta tokens enviar un mensaje con mesh-send?
- Escribir un mensaje con `mesh-send` es una escritura de archivo en el maildir del destinatario, no una operación de LLM, así que el acto de enviar no añade tokens más allá de lo que tu agente ya gastó componiendo el texto que quería enviar. No hay ninguna tarifa del lado del mesh añadida sobre esa escritura.
- ¿El inject hook automático que se ejecuta al iniciar sesión gasta tokens silenciosamente en cada turno?
- No, a menos que realmente haya un mensaje que entregar. La comprobación de correo nuevo del hook es una lectura de archivo; si el maildir está vacío, no se añade nada al contexto y no se gastan tokens. Los tokens solo se gastan en los turnos en los que un mensaje pendiente realmente se renderiza en la conversación.
- Si nunca leo un mensaje retenido o pendiente, ¿lo pago igualmente?
- No. Un mensaje no leído —ya esté en `new`, en `held`, o nunca reclamado— nunca se tokeniza en el contexto de ningún agente, así que no cuesta nada. El coste está ligado estrictamente al acto de que un agente lea contenido entregado, no a la mera existencia de un mensaje en un mailbox.
Comparaciones
- ¿En qué se diferencia agentixmesh de una message queue como Redis o RabbitMQ?
- Una queue mueve bytes entre endpoints; no sabe ni verifica quién los envió. agentixmesh verifica mediante el kernel al usuario del SO remitente vía fstat sobre el file descriptor abierto antes de que el agente receptor llegue siquiera a ver el mensaje, así que un mensaje de queue que afirme ser "del usuario X" puede falsificarse; un mensaje de agentixmesh no puede. Esa garantía de identidad es el punto clave; una queue no la proporciona.
- ¿Podría construir lo mismo con Redis pub/sub o una tabla de base de datos?
- Podrías mover los bytes, pero tendrías que añadir tú mismo la verificación del remitente: Redis y una tabla de base de datos compartida confían en cualquier cliente que escriba en ellas. La garantía de agentixmesh proviene del SO: solo el uid real que abrió el file descriptor puede ser el remitente registrado. Reimplementar eso sobre una queue significa rederivar comprobaciones de identidad a nivel de kernel, que es la parte más difícil.
- ¿Ofrece agentixmesh garantías de entrega u ordenación como una message queue de verdad?
- No de la forma en que lo hace un producto de queue: sin mecánicas de acks-con-reintentos-y-DLQ, sin garantías de ordenación entre remitentes distintos. Es un maildir: los mensajes aterrizan en new/, pasan a cur/ al leerse, held/ para los casos con gate. Eso es deliberadamente simple. Si necesitas throughput, ordenación o backpressure de nivel broker, agentixmesh no es esa herramienta: es una capa de confianza, no un producto de queue.
- ¿Cómo se relaciona agentixmesh con MCP (Model Context Protocol)?
- Es otra capa. MCP conecta una sesión de agente con herramientas y recursos —bases de datos, APIs, archivos— que invoca. agentixmesh conecta una sesión de agente con otra sesión de agente, para que puedan intercambiar mensajes sin que una herede la autoridad de la otra. Una sesión puede usar servidores MCP para herramientas y agentixmesh para hablar con agentes pares: son complementarios, no competidores.
- ¿Puedo usar agentixmesh y MCP juntos?
- Sí, resuelven problemas distintos y no entran en conflicto. Una sesión de Claude Code puede tener servidores MCP conectados para acceso a herramientas, como una base de datos o una API de búsqueda, y por separado recibir mensajes de agentixmesh de otra sesión que trabaja en una tarea relacionada. MCP gobierna el borde agente-herramienta del contexto; agentixmesh gobierna el borde agente-agente. Nada en uno requiere o bloquea al otro.
- ¿Cómo se compara agentixmesh con A2A u otros protocolos agente-a-agente orientados a la comunicación entre máquinas?
- Es una diferencia de posicionamiento, no una carencia de funcionalidad: agentixmesh es de una sola máquina, basado en archivos, con identidad del remitente kernel-verified; no hace transporte entre máquinas, TLS ni firma criptográfica entre hosts. Los protocolos construidos para agentes en máquinas distintas resuelven confianza a nivel de red, que es un problema distinto de la confianza local basada en file descriptor. La comunicación de agentes entre máquinas y firmada es terreno de roadmap para nosotros (AgentsWeaver), no lo que agentixmesh hace hoy.
- ¿Por qué no simplemente hacer que los agentes lean y escriban un archivo o base de datos compartidos?
- Un archivo o BD compartidos no tienen ningún concepto de quién escribió una fila dada más allá de lo que el escritor afirme: cualquier proceso con acceso de escritura puede falsificar un campo de remitente. El maildir de agentixmesh es owner-only (0700, same-user), y el remitente se deriva del uid kernel-verified del proceso que abrió el archivo, no de una columna autodeclarada. El almacenamiento compartido te da bytes, no procedencia.
- ¿Qué tiene de malo un directorio scratch compartido que dos agentes consultan (poll) en busca de cambios?
- Nada impide que un agente, un bug o una instrucción inyectada escriba un archivo que suplante a otro remitente: un directorio compartido plano no tiene ninguna comprobación de identidad. agentixmesh añade exactamente eso: un remitente kernel-verified por mensaje, más framing de DATA inerte para que un mensaje recibido se lea, no se obedezca automáticamente. Un directorio scratch no te da ninguna de las dos garantías.
- ¿Por qué no simplemente dejar que la salida de un agente se convierta directamente en el prompt de otro?
- Ese es precisamente el riesgo de confused-deputy/inyección que agentixmesh existe para atenuar. Canalizar la salida en bruto de un agente directamente al prompt de otro le da la misma autoridad que una instrucción directa, incluyendo cualquier cosa colada en esa salida. En cambio, agentixmesh entrega los mensajes como un marco de DATA inerte que el agente receptor lee pero nunca ejecuta automáticamente; responder con palabras está bien, actuar porque el mensaje lo diga no.
- ¿No añade fricción enmarcar los mensajes como datos inertes, comparado con simplemente hacer un prompt directo al otro agente?
- Algo, sí, y es deliberado. El prompting directo colapsa "texto recibido" e "instrucción a seguir" en una sola cosa, que es exactamente el modo de fallo confused-deputy. agentixmesh los mantiene separados: el marco es inequívocamente datos, y el agente receptor —no el mensaje— decide si actuar y cómo. Ese es el coste de no ser trivialmente inyectable.
- ¿En qué se diferencia esto de conectar dos agentes a través de Slack o un canal de chat?
- Un puente de chat te da una sala compartida donde cualquiera que tenga las credenciales puede publicar como sí mismo: útil para humanos, pero no verifica a nivel de SO qué proceso envió un mensaje, y no tiene incorporado ningún framing de "esto es un dato, no una orden". La garantía de identidad de agentixmesh se deriva del kernel (fstat sobre el propio file descriptor abierto del remitente), y la entrega tiene por defecto el framing inerte en lugar de un flujo en vivo que un agente pudiera leer como instrucciones.
- ¿Dónde encaja agentixmesh respecto a AgentsWeaver y Tokonomix?
- Son tres capas de una misma familia, no competidores. agentixmesh es la rampa de entrada local, de una sola máquina: basada en archivos, identidad kernel-verified, un host. AgentsWeaver es la escalada entre máquinas, firmada criptográficamente, para cuando los agentes abarcan varios hosts. Tokonomix es consenso de LLM entre proveedores: enrutar una misma pregunta a varios modelos y evaluar las respuestas. Problemas distintos, mismo enfoque de trust-first.
- ¿Cuándo se me quedaría pequeño agentixmesh y necesitaría algo como AgentsWeaver?
- Cuando tus sesiones de agentes dejen de vivir en una sola máquina. La garantía de identidad de agentixmesh está arraigada en una primitiva de kernel local —fstat sobre un file descriptor abierto— que no tiene respuesta para demostrar que un mensaje vino de otro host; eso requiere firma criptográfica a nivel de red, el problema que aborda AgentsWeaver. Varios usuarios del SO en una misma máquina siguen siendo territorio de agentixmesh (modo cross-user), solo que human-gated.
- ¿Es Tokonomix un sustituto de agentixmesh?
- No: hacen trabajos distintos. Tokonomix responde a "¿es buena esta salida?" enviando una pregunta a varios proveedores de LLM y sintetizando una respuesta evaluada. agentixmesh responde a "¿puedo confiar en quién me envió este mensaje?" entre sesiones de agentes. Pueden usarse en paralelo dentro del mismo flujo de trabajo, pero ninguno sustituye al otro.
- ¿Es agentixmesh un sustituto de frameworks de orquestación como LangGraph o CrewAI?
- No. Los frameworks de orquestación deciden qué hace un agente a continuación dentro de un mismo proceso o flujo de trabajo; agentixmesh mueve mensajes fiables entre sesiones o procesos de agentes independientes que no comparten memoria ni autoridad. Una sesión puede ejecutar un framework de orquestación internamente y también enviar y recibir a través de agentixmesh: operan en capas distintas y en gran medida no se solapan.
- ¿En qué se diferencia agentixmesh de MCP (Model Context Protocol)?
- Se sitúan en capas distintas. MCP conecta un modelo con sus herramientas y su contexto — el agente invoca capacidades deliberadamente, como acciones propias. agentixmesh es la frontera de confianza entre sesiones de agentes ya en ejecución: el identificador de usuario del SO del remitente está verificado por el kernel y el contenido llega como datos inertes, nunca como una instrucción que el agente deba seguir. Adyacentes, no competidores — la página agentixmesh vs MCP muestra la comparación completa.
- ¿Pueden agentixmesh y MCP funcionar en paralelo?
- Sí — esa es la instalación esperada. Cada sesión mantiene sus propios servidores MCP para las capacidades, mientras agentixmesh transporta los mensajes entre sesiones. El mesh entrega una petición como datos; si el agente actúa o no sigue siendo una decisión dentro de la sesión receptora, bajo sus propios permisos.
Instalación, límites y roadmap
- ¿Requiere agentixmesh un daemon en segundo plano o un proceso de servidor?
- Ningún daemon. La entrega same-user funciona sobre un maildir (carpetas new/cur/held/seen) más un inject hook que se dispara cuando se inicia una sesión de agente o se envía un prompt; no hay nada que tenga que ejecutarse continuamente en segundo plano. No hay ningún proceso persistente que pueda caerse, haya que reiniciar o vigilar para la ruta core same-user.
- ¿Abre agentixmesh un puerto de red?
- No. No tiene ningún listener de red de ningún tipo: la mensajería same-user es simple I/O de sistema de archivos: un mensaje se escribe en un directorio maildir y lo recoge el inject hook en el siguiente evento de sesión. No hay ningún socket que abrir, ningún puerto que proteger con firewall, nada escuchando conexiones.
- ¿Necesito sudo o root para usar agentixmesh?
- No, no para el core same-user. Los mailboxes son directorios owner-only (modo 0700) que una cuenta de usuario normal crea y lee por su cuenta. Root solo pasa a ser relevante si además aprovisionas la configuración de host compartida de la capa cross-user opcional; la mensajería same-user del día a día nunca toca sudo.
- ¿Qué necesita un host para ejecutar agentixmesh?
- Solo una máquina, un sistema de archivos en el que la cuenta de usuario pueda escribir, Python, y un maildir alojado bajo el directorio home de ese usuario. La otra pieza es un inject hook conectado a tu harness de agente para que los mensajes entrantes se rendericen en el contexto de una sesión; no hace falta ninguna infraestructura exótica más allá de eso.
- ¿Cómo instalo agentixmesh?
- Conecta cuatro puntos de integración con el host: una entrada en el path de Python para que el paquete sea importable, CLI wrappers (como `mesh-send`) en tu PATH, un archivo skill que cargue tu harness de agente, y un inject hook que se dispare al iniciar sesión y al enviar un prompt. Es de código abierto en GitHub (github.com/TokonoMix/agentixmesh, MIT), así que lo clonas y ejecutas tú mismo los pasos de instalación.
- ¿Es agentixmesh autoalojable (self-hostable)?
- Sí, solo puede ser self-hosted. No existe ningún servicio hospedado ni backend SaaS; agentixmesh son archivos locales (un maildir) más un hook que instalas en tu propio harness de agente en tu propia máquina. Controlas el transporte de extremo a extremo, y ningún dato de mensaje sale de tu host.
- ¿Qué pasa si nunca instalo el inject hook?
- Los mensajes simplemente se quedan sin entregar en el maildir. El hook es lo que renderiza un mensaje nuevo en el contexto de una sesión de agente al iniciar sesión o al enviar un prompt; sin él, el envío sigue funcionando y los mensajes se van encolando, pero nada los hace visibles al agente receptor hasta que el hook se ejecute.
- ¿Está agentixmesh limitado a una sola máquina?
- Sí. Hoy agentixmesh solo entrega mensajes entre sesiones de agentes en la misma máquina. No hay transporte de red, así que no puede enrutar un mensaje a una sesión que se ejecuta en otro host. La entrega entre máquinas es una necesidad real y distinta que actualmente no aborda.
- ¿Dará agentixmesh soporte a la entrega entre máquinas?
- Está en el roadmap, no publicado hoy. El core de agentixmesh es solo de una máquina, sin ningún transporte de red incorporado. La entrega entre máquinas, firmada criptográficamente y a escala, es el trabajo explícito de un proyecto hermano, AgentsWeaver: agentixmesh está posicionado como la rampa de entrada local, de una sola máquina, no como el transporte entre redes ya escalado.
- ¿Qué es la "capa de mayor autoridad" del roadmap?
- Co-aprobación leader-gate, roles de grupo, y monitorización leader-read con consent-gate: mecanismos para que un líder de equipo co-apruebe u observe el tráfico de agentes con consentimiento. Hoy existen en forma de diseño/prototipo, pero no están publicados y explícitamente no se anuncian como seguridad de producción; trátalos como roadmap, no como una garantía endurecida (hardened).
- ¿Bajo qué licencia está agentixmesh?
- MIT. El código es público en GitHub en github.com/TokonoMix/agentixmesh: léelo, haz fork, autoalójalo o modifícalo sin pedir permiso. No hay ningún nivel de pago aparte ni un core cerrado escondido detrás del repositorio público; lo que ves es lo que se ejecuta.
- ¿Se mantiene agentixmesh activamente?
- Se desarrolla como un proyecto de código abierto con el historial de commits completo público en GitHub, así que puedes comprobar tú mismo la actividad antes de depender de él. No hay ningún SLA de soporte formal; como con cualquier proyecto con licencia MIT, adoptarlo significa asumir tu propia responsabilidad operativa sobre el fork que ejecutas.
- ¿Qué es lo que agentixmesh deliberadamente NO hace?
- No se ejecuta como un servicio de red, no requiere sudo para el uso same-user, no actúa automáticamente sobre el contenido de un mensaje, y no afirma detener por completo la inyección de prompts. Entrega los mensajes como datos inertes para que un agente los lea y decida al respecto; el mesh en sí nunca ejecuta una instrucción encontrada dentro del cuerpo de un mensaje.