Distribución de Herramientas: La Bat-Familia como Sistema Multi-Agente

Principio de menor privilegio en tool distribution, herramientas compartidas vs. especializadas, distribución de servidores MCP por agente, reasoning overload, y versioning.

Batman no le da los códigos nucleares a Robin

Batman no le da a Robin los códigos de override nuclear. No porque no confíe en él. Sino porque Robin no los necesita. Su rol es operaciones de campo — combate, evidencia, patrulla. Los códigos nucleares nunca van a ser relevantes para ninguna de sus misiones. Dárselos no agrega capacidad útil — agrega riesgo y confusión.

Oracle no tiene herramientas de combate físico. No porque no pueda usarlas — puede. Sino porque opera desde la Baticueva, de forma remota. Darle un grapple gun a un agente que nunca va al campo es literalmente ruido en su contexto.

Tool distribution: decidir qué herramientas recibe cada agente en función de su rol específico. Ni más, ni menos. Y cuando tenés cinco agentes distintos y veinte herramientas posibles, esa decisión se convierte en la parte más importante del diseño del sistema.

En M2V1 aprendiste a diseñar buenas herramientas. En M2V2 viste cómo compartirlas con MCP. En M2V4 aprendés a distribuirlas correctamente en un sistema multi-agente. Es la diferencia entre un sistema que funciona y uno que escala.

Principio de menor privilegio: la tabla de la Bat-Familia

La Bat-Familia tiene cinco miembros activos. Cada uno tiene un rol específico. Y cada uno recibe exactamente las herramientas que necesita para ese rol — ni una más.

Mirá la columna de 'Lo que NO tiene y por qué'. Esa columna es tan importante como la de lo que tiene. La ausencia de una herramienta no es un olvido — es una decisión de diseño.

Robin no tiene override_nuclear porque ese nivel de acceso está reservado para el coordinador. No tiene hackear_sistema porque Oracle ya cumple ese rol — duplicar la capacidad en otro agente no suma valor, suma complejidad. No tiene wayne_enterprises_db porque sus decisiones operativas no dependen de datos corporativos.

Dos beneficios del menor privilegio que el examen separa

El examen hace preguntas sobre los dos beneficios del principio de menor privilegio, y los trata por separado.

Primero: seguridad. Si un sub-agente es comprometido o produce una respuesta inesperada, el daño está acotado al scope de sus herramientas. Robin generando una acción incorrecta con su kit forense es contenible. Robin con acceso a sistemas nucleares no lo es.

Segundo: calidad de razonamiento. Cuando el modelo recibe veinte herramientas y solo cinco son relevantes para la tarea actual, parte de su capacidad de razonamiento se gasta en descartar las quince irrelevantes. Si el sub-agente solo recibe las cinco que necesita, todo el razonamiento va a la tarea. Mejor calidad, menor latencia, menor costo.

💡 EXAMEN: El principio de menor privilegio en tool distribution tiene DOBLE beneficio — seguridad (daño acotado si el agente es comprometido) y calidad de razonamiento (menos ruido = mejor foco). El examen pregunta sobre ambos por separado.

Herramientas compartidas vs. especializadas

Hay una pregunta de arquitectura que aparece en cada sistema multi-agente: ¿esta herramienta tiene que ser un MCP server compartido o puede vivir como tool directa en el agente que la usa?

La respuesta depende de una sola cosa: ¿cuántos agentes la necesitan?

consultar_gcpd la usan Oracle, Robin, y Batman como coordinador. Si cada uno tiene su propia implementación, hay tres lugares donde mantener el código, tres lugares donde actualizar cuando la API de la GCPD cambia, tres lugares donde puede haber bugs distintos. Con un MCP server centralizado: una sola implementación, un solo lugar de mantenimiento, todos los clientes reciben la actualización automáticamente.

escrima_sticks la usa solo Nightwing. Exponerla como MCP server compartido sería overhead sin beneficio. Nadie más se va a conectar a ese servidor. Mejor mantenerla como tool directa en el agente de Nightwing — más simple, más rápido, menos infraestructura.

Regla práctica: si más de un agente usa la herramienta hoy, o si es probable que más agentes la necesiten en el futuro → MCP server centralizado. Si es exclusiva de un solo agente y no hay planes de expansión → tool directa.

Distribución de MCP servers: quién se conecta a qué

Cuatro MCP servers para la Bat-Familia. La pregunta no es solo qué tools tiene cada agente — es qué servidor se conecta a qué agente.

Batman como coordinador se conecta a baticueva_core — acceso completo — pero también a gcpd_server y wayne_tech_server para tener visibilidad de lo que sus sub-agentes están usando. No porque Batman vaya a usar esas tools directamente, sino porque el coordinador necesita saber qué capabilities tiene cada parte del sistema para delegar correctamente.

Nightwing no se conecta a baticueva_core. Opera autónomo. Si hay una emergencia que requiere acceso al hub central, Nightwing contacta a Batman — que actúa como intermediario. Eso limita la superficie de ataque: comprometer a Nightwing no compromete la Baticueva.

⚠️  EXAMEN: Cuando el examen pregunta 'quién debería tener acceso a qué servidor MCP', la respuesta correcta siempre deriva del principio de menor privilegio + el rol del agente. Un agente que no usa directamente las tools de un servidor no debería estar conectado a él, aunque 'podría necesitarlas eventualmente'.

Reasoning overload: el problema silencioso

Imaginá darle a Robin las veinte herramientas de toda la Bat-Familia. El modelo que lo implementa recibe en su contexto veinte definiciones de tools — nombres, descriptions, schemas. En cada paso del agentic loop, tiene que leer y evaluar las veinte antes de decidir cuál usar. Quince de esas veinte no son relevantes para la misión de Robin.

Ese razonamiento extra consume tokens, aumenta la latencia y — lo más crítico — puede llevar al modelo a elegir una herramienta equivocada entre tantas opciones similares.

Reasoning overload no es un problema teórico — es una causa real de degradación de calidad en sistemas multi-agente. Cuando el agente 'elige mal' entre herramientas, la primera pregunta no es '¿el modelo es malo?' sino '¿cuántas herramientas tiene disponibles?'

La solución es la que ya vimos: cada agente recibe solo su subconjunto. Robin recibe cuatro tools. Oracle recibe cuatro. El modelo de cada agente trabaja con un conjunto acotado y relevante — mejor calidad, menor costo.

Versioning: cuando la herramienta cambia

Batman actualiza el Batarang de v1 a v2 — ahora tiene retorno asistido por IA. Robin usa el Batarang. Nightwing también. ¿Qué pasa con sus sistemas cuando la herramienta cambia?

Si el Batarang vive como MCP server centralizado, el servidor se actualiza una vez. Todos los clientes que se conectan reciben la versión nueva automáticamente. El riesgo está en cambios que rompen compatibilidad — si el schema de inputs cambia, los agentes que ya lo usaban pueden fallar.

La solución es versionado semántico: si el cambio es retrocompatible, mismo endpoint. Si rompe compatibilidad, nuevo endpoint paralelo — el viejo sigue funcionando hasta que todos los clientes migran. En MCP eso se implementa con URIs distintas: '/tools/batarang/v1' y '/tools/batarang/v2', corriendo en paralelo durante la transición.

Demo: la Bat-Familia como sistema multi-agente

Veamos el código completo. Batman recibe la misión, Oracle investiga digitalmente con sus tools, Robin investiga en campo con las suyas, y Batman sintetiza. Cada agente solo ve sus herramientas.

Corrés esto y vas a ver que Oracle nunca intentó entrevistar al testigo — porque esa tool no existe en su contexto. Robin nunca intentó hackear las cámaras — hackear_sistema no está en su lista. Dos agentes con contextos limpios, sin ruido. Batman sintetizó lo que ninguno podría haber generado solo. Eso es tool distribution funcionando.

Las 4 trampas del examen sobre tool distribution

Trampa 1: 'Darle más tools a un agente siempre le da más capacidad'

FALSO. Más tools = más reasoning overload. El modelo puede elegir la herramienta equivocada, tarda más en decidir, y consume más tokens. La capacidad de un agente no es proporcional al número de herramientas — es proporcional a que sus herramientas sean las correctas para su rol.

Trampa 2: 'El coordinador no necesita estar conectado a los MCP servers de sus sub-agentes'

FALSO. El coordinador necesita visibilidad de las capabilities disponibles para delegar correctamente. Si Batman no sabe que gcpd_server existe, no puede decidir que Oracle (y no Robin) es quien debe hacer una búsqueda de sospechoso. El coordinador usa los servers para entender qué puede hacer cada parte del sistema, aunque delegue la ejecución.

Trampa 3: 'Un cambio retrocompatible en una tool de MCP siempre requiere notificar a todos los clientes'

FALSO. Si el cambio es retrocompatible (agregar parámetro opcional, mejorar la description sin cambiar el schema), los clientes existentes siguen funcionando sin modificación. Solo los cambios que rompen compatibilidad — cambiar un parámetro requerido, modificar el tipo de un campo, eliminar una tool — requieren manejo especial con versioning paralelo.

Trampa 4: 'El principio de menor privilegio en tools solo beneficia la seguridad'

FALSO. El menor privilegio tiene DOS beneficios distintos que el examen evalúa por separado: seguridad (el daño está acotado si el agente es comprometido) y calidad de razonamiento (menos tools irrelevantes = mejor foco del modelo). La segunda mitad es tan importante como la primera para sistemas bien diseñados.

Lo que te llevás de M2V4

Tool distribution es el arte de armar el cinturón correcto para cada miembro de la Bat-Familia. El principio de menor privilegio no es solo seguridad — es calidad de razonamiento. Las herramientas compartidas van a MCP servers centralizados; las especializadas de un solo agente van como tools directas. El coordinador necesita visibilidad de todos los servers para delegar bien. Y cuando una herramienta cambia, los cambios retrocompatibles se propagan solos; los que rompen compatibilidad necesitan versioning paralelo.

Un sistema multi-agente bien distribuido es más poderoso que cualquier agente único — porque cada parte razona solo con lo que necesita, y el coordinador sintetiza lo que ningún agente podría generar por sí solo.

En M2V5 cerramos el Dominio 2 con error handling estructurado en tools y MCP. Cómo hacer que tus tools fallen de forma útil — y qué hace el agente cuando recibe un error.