Google SAM ahora es Agent Mesh: MCP entre equipos

Google SAM ahora es Agent Mesh

Sovereign Agent Mesh (SAM), ahora llamado Agent Mesh, es una capa de red de código abierto para agentes de IA. Permite que un agente descubra e invoque herramientas autorizadas en otras máquinas a través de un nodo local. El repositorio ha pasado de google/sam a google/agentmesh. Su README actual confirma el cambio de nombre y el estado del proyecto: licencia Apache-2.0, versión anterior a la 1.0 y sin soporte oficial de Google como producto.

El problema práctico resulta familiar. Tu asistente de programación funciona en un portátil. Un agente revisor se ejecuta junto a un servidor de compilación. Una herramienta de búsqueda interna vive en un clúster privado. Cada uno aporta capacidades útiles, pero compartirlas exige endpoints accesibles y decidir quién puede invocar cada herramienta.

Agent Mesh proporciona esa capa de conexión y autorización. Mantienes las herramientas en sus respectivos entornos y publicas determinadas capacidades para los nodos registrados.

Nota de versión, comprobada el 12 de octubre de 2026: este artículo sigue el código del commit 273e6fba y sus nombres agentmesh-*. La última versión que figura publicada, v0.1.0-rc.9, del 7 de octubre, todavía utiliza los nombres sam-*. Al evaluarla, utiliza comandos y documentación de la misma versión.

Un nodo local permite acceder a herramientas remotas

El agente se comunica con agentmesh-node en su propia máquina. Ese nodo se conecta a la malla y comprueba a qué servicios remotos puede acceder. Un nodo proveedor publica únicamente los backends que su operador ha configurado.

El plano de control admite miembros y emite credenciales. Los routers ayudan a los nodos a encontrarse y retransmiten el tráfico cifrado cuando no hay una conexión directa disponible. agentmesh-one reúne un plano de control, un router y una consola para despliegues pequeños. La documentación de arquitectura describe estas responsabilidades.

Si ya tienes una infraestructura de agentes, conviene distinguir sus capas:

Nuestra guía sobre comunicación entre agentes y Band aborda la coordinación en un sentido más amplio. La aportación específica de SAM es la red sobre la que se producen esas interacciones.

El descubrimiento automático evita configurar cada conexión por separado

Cuando un nodo se incorpora a la malla, obtiene información sobre los routers y descubre los servicios publicados a través de su directorio distribuido. Las conexiones pueden seguir una ruta directa o utilizar una retransmisión cifrada. La guía de red explica el descubrimiento, las retransmisiones y la recuperación de conexiones.

Esto puede ahorrarte mantener una lista de direcciones distinta para cada asistente. Un servicio conserva su nombre cuando su proveedor cambia de red. Los resultados del descubrimiento identifican proveedores candidatos; las comprobaciones de conexión y credenciales determinan si una solicitud puede continuar.

Los operadores siguen teniendo que elegir un plano de control, registrar a los miembros y conceder acceso. También configuran cada backend publicado. Llamar a este proceso «configuración cero» oculta decisiones que determinan a qué pueden acceder tus agentes.

El nodo local expone un endpoint MCP con transporte Streamable HTTP. La guía de integración de clientes incluye ejemplos de Claude Code y Google Antigravity, además de otros clientes MCP. Su skill enseña a un asistente a descubrir, describir e invocar herramientas remotas. El registro y la configuración de MCP siguen siendo pasos independientes.

Para Codex o Hermes, comprueba el transporte MCP y las opciones de autenticación que admite el cliente antes de prometer una integración funcional. Este artículo no establece una matriz de compatibilidad probada para esos clientes.

La identidad acompaña al nodo cuando cambia de red

Cada nodo genera su propio par de claves Ed25519. Su identificador de par deriva de la clave pública. Un inicio de sesión con OpenID Connect o un token de registro inicial lo incorpora a un plano de control, que emite una credencial Biscuit firmada. Esa credencial contiene la identidad y los permisos que otros nodos pueden verificar.

La credencial está vinculada a la clave del nodo. Copiar únicamente la credencial no proporciona esa clave. Los nodos autentican la conexión y evalúan el servicio solicitado frente a las facultades del invocante. La especificación de identidad y registro también explica la caducidad y la renovación.

Así puedes conceder acceso a un servicio por su nombre sin vincular la regla a la dirección IP actual de un portátil. La credencial sigue perteneciendo a la malla que la emitió. Trasladar una carga de trabajo a otra nube e incorporarla a un plano de control independiente son operaciones distintas.

Una malla dedicada te da el control de miembros y claves

Operar tu propio plano de control te permite decidir qué identidades se incorporan y qué servicios pueden utilizar. Tu despliegue posee las claves de firma de credenciales y la política administrativa. Proteger su base de datos y el acceso de administración forma parte de mantener ese límite de confianza.

La documentación sobre los límites de control y datos describe el autoalojamiento en infraestructura privada, incluida una red aislada del exterior. Un despliegue aislado también necesita que sus servicios de identidad, herramientas y modelos estén disponibles dentro de ese entorno.

Las solicitudes a herramientas viajan entre nodos; el plano de control gestiona los miembros y las políticas fuera de esa ruta de datos. Un relay transporta tráfico cifrado y puede observar metadatos de conexión.

Las redes públicas de prueba compartidas son útiles para experimentar con datos sintéticos. Sus operadores controlan los miembros y las políticas, y no garantizan la disponibilidad. Un perímetro propio de la empresa empieza por un despliegue dedicado y decisiones de infraestructura verificadas.

Las etiquetas UE restringen la selección de proveedores

Agent Mesh puede exigir que un proveedor tenga una etiqueta firmada, como jurisdiction=eu. El nodo declara sus etiquetas durante el registro. El plano de control firma únicamente las que permite su rol mediante allowed_labels.

En un nodo consumidor, el operador puede fijar este requisito mínimo:

version: "v1alpha1"
egress:
  require_labels:
    jurisdiction: eu

La referencia de configuración del nodo define esta condición mínima. Quien realiza la llamada puede añadir requisitos para el proveedor, pero no eliminar el fijado por el operador. El control comprueba los atributos de la credencial firmada antes de reenviar una solicitud.

La firma demuestra que la autoridad de la malla ha aceptado una etiqueta. Su significado físico depende de los controles de tu despliegue. Una máquina con una etiqueta UE podría ejecutar un backend que reenvíe los prompts a una API de modelos externa.

Comprueba toda la ruta de procesamiento: la ubicación real del proveedor, dónde están los relays, las API posteriores, los registros y las copias de seguridad. Las conexiones salientes ordinarias de la aplicación también necesitan controles adecuados. Una etiqueta en un nodo de la malla no puede acreditar todos esos hechos.

Nuestra guía de residencia de datos en la UE para aplicaciones de IA cubre ese perímetro más amplio. Aquí, el mecanismo útil es una selección con controles efectivos entre proveedores cuyas etiquetas has justificado de forma independiente.

El proveedor puede rechazar una llamada autorizada de forma central

Una máquina que aloja una herramienta sensible puede imponer sus propias comprobaciones. Por ejemplo, su operador puede exigir una etiqueta acreditada del invocante o denegar un servicio concreto a un grupo. Una comprobación local fallida o una política de denegación aplicable pueden bloquear el acceso aunque la malla lo conceda.

La especificación de autorización describe esa aplicación local de las reglas. También admite credenciales de tarea con permisos más restringidos para el trabajo delegado.

Esto da al propietario de la herramienta un veto práctico. Las decisiones específicas de la aplicación, como qué registros de clientes puede devolver una consulta, siguen correspondiendo al servicio que conoce esos registros. Nuestro artículo sobre control de acceso a los datos con MCP explica esa siguiente capa.

Evalúa SAM con dos nodos y una herramienta aritmética

Empieza por una capacidad cuyas entradas y resultado sean fáciles de inspeccionar. Un servidor MCP que solo sume permite hacer una prueba útil sin utilizar datos de negocio. Esta guía se deriva de la documentación; Wavect no ha ejecutado este despliegue ni ha medido el rendimiento de SAM para este artículo.

Utiliza un plano de control dedicado a pruebas y binarios que correspondan al código o a la versión publicada que elijas. Los nombres de los comandos siguientes coinciden con el código actual examinado. Sustituye mesh.example.com por la dirección HTTPS de tu propio plano de control.

1. Publica un proveedor con un alcance deliberadamente pequeño

En la máquina A, ejecuta tu servidor MCP de prueba en la interfaz de loopback, en el puerto 7779. Debe ofrecer Streamable HTTP en /mcp. Guarda lo siguiente como provider.yaml:

version: "v1alpha1"
labels:
  jurisdiction: eu
services:
  - type: mcp
    name: calculator
    description: "Arithmetic tools"
    target_url: "http://127.0.0.1:7779/mcp"

La guía de publicación de servicios documenta esta estructura de configuración. El nodo comprueba el backend antes de anunciarlo. Concede al rol de registro del proveedor permiso para llevar jurisdiction=eu, después de verificar que esa etiqueta corresponde.

2. Registra al proveedor y al consumidor

Crea tokens de registro separados para las dos máquinas. En A, conserva su token en un archivo local y ejecuta:

agentmesh-node join https://mesh.example.com \
  --bootstrap-token-path ./provider-join-token --config ./provider.yaml
agentmesh-node run --config ./provider.yaml

En la máquina B, guarda el ejemplo anterior de egress.require_labels como consumer.yaml. Registra B e inicia su nodo con ese archivo y su propio token. El invocante necesita acceso a mcp://calculator y al descubrimiento mediante system://mesh.catalog. Limita sus permisos a este ejercicio.

3. Descubre la herramienta y después inspecciona su esquema

Conecta un cliente MCP compatible al nodo local de B utilizando el endpoint y la autenticación documentados. Invoca get_mesh_info para comprobar la conectividad y después discover_remote_services para buscar la calculadora. Utiliza find_remote_tools y describe_remote_tool para inspeccionar la herramienta del proveedor seleccionado.

Pasa a call_remote_tool el identificador de par devuelto, el nombre de la herramienta con su espacio de nombres y argumentos que respeten el esquema. Envía los valores sintéticos 2 y 3 a la herramienta de suma y comprueba que devuelve 5. Registra qué proveedor ha respondido. Los nombres de herramientas y parámetros deben proceder del descubrimiento. La referencia de la API del nodo especifica estas interfaces de descubrimiento e invocación de herramientas.

4. Comprueba los casos de rechazo

Repite la prueba contra un proveedor de prueba que no tenga la etiqueta firmada requerida. Verifica que no recibe los datos de la operación aritmética. Después, añade una regla de denegación local en el proveedor y comprueba que se rechaza una llamada que, de otro modo, estaría permitida. Por último, desconecta un nodo y observa el descubrimiento y la reconexión por separado de cualquier reintento de la aplicación.

Registra las llamadas correctas, los rechazos y el comportamiento de recuperación en tu entorno. Utiliza esos resultados para decidir si el siguiente paso es evaluar una herramienta de búsqueda privada o un revisor.

Los grupos de revisores añaden coordinación sobre la malla

El ejemplo de un grupo de agentes ya preparados del proyecto reparte revisiones de código entre trabajadores que ya están en ejecución. Cada trabajador expone una herramienta MCP de revisión. Un gestor descubre los trabajadores y los reserva temporalmente para un orquestador, que distribuye un lote en paralelo.

Esa separación resulta útil. La malla encuentra al trabajador y permite acceder a él. El gestor decide si está disponible. Tu flujo de trabajo determina qué se considera una revisión aceptable.

La recuperación de conectividad puede volver a conectar los nodos tras una interrupción de red. La finalización de las tareas sigue necesitando sus propias reglas. Si una respuesta desaparece después de que una herramienta termine, un reintento puede repetir la operación. Lleva un registro de los identificadores de trabajo y del estado de finalización antes de incorporar herramientas que escriban archivos o desencadenen otras acciones. La recuperación automática de las conexiones de la malla no garantiza que cada tarea se ejecute exactamente una vez.

Centra el piloto en una capacidad compartida

Merece la pena evaluar Agent Mesh cuando hay herramientas útiles en distintas máquinas y varios asistentes necesitan acceder a ellas de forma controlada. Un nodo local da a cada cliente un único punto de entrada; el operador define quién puede acceder a cada servicio.

Mantén en el diseño el aislamiento del host y la autorización de la aplicación. La arquitectura de seguridad del proyecto describe los límites respecto al sandbox y a los servicios externos.

Para un equipo de trabajo que ya conecta un asistente de portátil con infraestructura privada de compilación o búsqueda, la primera decisión es concreta: elige una herramienta, dos nodos registrados y un permiso que puedas comprobar. Amplía el alcance cuando puedas demostrar qué identidad ha invocado la herramienta, qué proveedor ha recibido los datos y cómo se ha bloqueado una llamada prohibida.