Casi todos los sistemas multiagente que me han mostrado este año tienen la misma historia detrás. Un agente no hacía bien una tarea, alguien propuso partirla entre tres agentes especializados, y ahora hay tres agentes que tampoco la hacen bien, más un problema nuevo: ponerse de acuerdo entre ellos. El diagrama quedó impresionante y el resultado empeoró.
La respuesta corta: las cuatro formas de extender un agente responden preguntas distintas, no son alternativas ni etapas de madurez. Elegir la equivocada no solo desperdicia trabajo, agrega modos de falla que antes no existían. Y la que más se elige de más, multiagente, es justo la que más los agrega.
¿Qué pregunta responde cada una?
Cuatro preguntas distintas. Si sabes cuál es la tuya, la elección es obvia.
| Extensión | La pregunta que responde | Lo que NO resuelve |
|---|---|---|
| Harness | ¿Cómo actúa el modelo en lugar de solo responder? | Qué debe hacer, y con qué información |
| Skills | ¿Sabe cómo se hace esta tarea aquí? | Llegar a los sistemas donde vive el dato |
| MCP | ¿Puede tocar los sistemas donde está el dato? | Qué hacer una vez que llegó |
| A2A | ¿Puede delegarle a un agente que no es tuyo? | Coordinar los agentes que sí son tuyos |
| Multiagente | ¿Vale la pena repartir el trabajo entre varios? | Que cada parte esté bien resuelta |
La confusión más cara del mercado está entre las filas dos y tres. MCP le da al agente la llave de la bodega. Una Skill le dice qué hacer una vez adentro. Son complementarias, y la mayoría de los sistemas en producción usa ambas.
¿Qué es el harness y por qué casi nadie lo nombra?
Es el bucle que convierte un modelo en un agente. Sin él no hay agente, hay un chat.
Un modelo de lenguaje, por sí solo, recibe texto y devuelve texto. El harness es lo que lo hace actuar: toma la instrucción, deja que el modelo decida, ejecuta la herramienta que pidió, le devuelve el resultado, lo deja decidir otra vez, y persiste el estado entre pasos para que la vuelta siguiente sepa qué pasó en la anterior.
Es el concepto menos discutido de los nueve que circulan en las listas, y el que más determina si el sistema sirve. Un harness malo se nota en síntomas que la gente atribuye al modelo: el agente repite el mismo paso, no reconoce que ya terminó, o pierde a mitad de camino lo que había decidido antes.
No es casualidad que esos tres síntomas aparezcan como modos de falla nombrados en la literatura, y volveremos a ellos más abajo.
¿Cuándo necesitas una Skill?
Casi siempre, y es lo más barato de las cuatro.
Una Skill es una carpeta con instrucciones que le enseña al agente cómo hacer una cosa: el criterio, el orden, el formato de salida, qué revisar antes de entregar. Desde diciembre de 2025 es un estándar abierto basado en archivos, un SKILL.md con instrucciones más los recursos y scripts que necesite [2].
Su mecanismo clave es la divulgación progresiva: al arrancar, el agente solo carga el nombre y la descripción de cada Skill, unos 30 a 50 tokens cada una. Las instrucciones completas se cargan cuando la tarea coincide, y los archivos referenciados solo durante la ejecución [2]. Esto importa por una razón práctica: puedes tener cincuenta Skills disponibles sin gastar contexto en las cuarenta y nueve que no aplican hoy.
Señal de que necesitas una Skill: el agente tiene acceso a todo lo que necesita y aun así entrega en el formato equivocado, se salta un paso de revisión o aplica un criterio que en tu empresa no es el correcto.
Señal de que no es lo que te falta: el agente sabe perfectamente qué hacer y no puede, porque no llega al sistema.
¿Cuándo necesitas MCP?
Cuando el agente tiene que tocar sistemas de verdad, y son más de uno.
MCP resuelve el problema de las integraciones a la medida: un protocolo estándar en lugar de un conector artesanal por cada herramienta. Si tu agente habla con un solo sistema y ya tienes ese conector escrito, MCP no te va a cambiar la vida hoy. Si va a hablar con seis, y esperas que sean nueve el año que viene, la diferencia es estructural.
Señal de que necesitas MCP: estás escribiendo el tercer conector a mano y los tres se parecen sospechosamente.
Señal de que no: tienes un solo sistema, estable, con una API que ya funciona. Adoptar el protocolo ahí es sobrecosto de arquitectura sin retorno.
¿Cuándo necesitas A2A?
Cuando el otro agente no es tuyo. Esa es toda la regla.
A2A existe para que agentes de distintos dueños o proveedores se descubran, intercambien tareas y se deleguen trabajo de forma segura. Es una decisión de interoperabilidad entre organizaciones, no una decisión de arquitectura interna.
Se confunde con multiagente todo el tiempo porque ambos implican más de un agente. La diferencia es la frontera: A2A la cruza, multiagente no.
Señal de que necesitas A2A: vas a integrarte con el agente de un proveedor, un cliente o un socio, y ninguno de los dos controla al otro.
Señal de que no: los agentes son todos tuyos, corren en tu infraestructura y los desplegaste el mismo día. Ahí un protocolo de descubrimiento entre desconocidos es ceremonia.
¿Cuándo necesitas multiagente?
Mucho más tarde de lo que la mayoría cree, y hay evidencia de lo que cuesta llegar antes.
El estudio MAST de UC Berkeley analizó más de 1,600 trazas anotadas de siete frameworks multiagente populares y clasificó 14 modos de falla distintos [1]. Lo relevante no es el conteo, es de dónde vienen.
Datos
| Value | Share | |
|---|---|---|
| Especificación y diseño del sistema | 41.8% | 42% |
| Desalineación entre agentes | 36.9% | 37% |
| Verificación de la tarea | 21.3% | 21% |
Casi el 37% de las fallas es desalineación entre agentes. Ese porcentaje no existe en un sistema de un solo agente: es un costo que aparece el día que decides repartir el trabajo. Y la categoría más grande, especificación y diseño, también crece con el reparto, porque cada frontera nueva entre agentes es una especificación nueva que alguien tiene que escribir bien.
Los modos individuales más frecuentes son igual de reveladores.
Datos
| Modo de falla | Frecuencia |
|---|---|
| Repetir un paso ya ejecutado | 15.7% |
| No reconocer la condición de término | 12.4% |
| Desobedecer la especificación de la tarea | 11.8% |
Repetir un paso, no darse cuenta de que ya terminó, desobedecer la instrucción. Son exactamente los síntomas de un harness pobre, que es la primera capa de la lista y la que casi nadie construyó antes de repartir el trabajo entre tres agentes.
Señal de que necesitas multiagente: tienes subtareas genuinamente paralelas, o que requieren contextos incompatibles entre sí, y ya tienes un agente que resuelve bien cada una por separado.
Señal de que no: un agente hace mal la tarea y la propuesta es partirla. Partir un problema que no entiendes te da varios problemas que tampoco entiendes.
¿En qué orden se construye?
De abajo hacia arriba, y casi nunca se llega hasta el final.
| Paso | Extensión | Cuándo pasar al siguiente |
|---|---|---|
| 1 | Harness | Cuando el agente completa la tarea de punta a punta y sabe cuándo terminó |
| 2 | Skills | Cuando el criterio y el formato salen bien sin que nadie corrija a mano |
| 3 | MCP | Cuando el agente llega a todos los sistemas que necesita |
| 4 | Multiagente | Solo si hay paralelismo real o contextos incompatibles |
| 5 | A2A | Solo si el otro agente es de alguien más |
La mayoría de los proyectos que funcionan se quedan entre el 2 y el 3. Eso no es una limitación, es el resultado esperado: los pasos 4 y 5 resuelven problemas que la mayoría de los sistemas no tiene.
Cómo lo aplicamos en MasterDragon
Preguntamos qué falta antes de preguntar qué agregar.
En la práctica, cuando un agente no rinde, revisamos en este orden: ¿reconoce cuándo terminó? ¿tiene el criterio escrito o se lo estamos suponiendo? ¿llega a los datos? Recién si las tres respuestas son sí y el trabajo sigue sin salir, consideramos repartirlo. En la mayoría de los casos la respuesta está en la segunda pregunta y se resuelve escribiendo bien una instrucción, no desplegando arquitectura.
También construimos con un solo agente por defecto y lo partimos solo cuando podemos nombrar la subtarea que corre en paralelo. Si no la podemos nombrar, no hay paralelismo, hay ganas de tener un diagrama más interesante.
Si estás por comprometerte con una arquitectura de agentes y quieres saber cuál de estas cuatro es la que te falta, habla con nuestros ingenieros. Puedes empezar por cómo construimos tu software y revisar nuestro portafolio de productos AI-native ya lanzados. Las definiciones completas del vocabulario están en el glosario de IA agéntica, lo que hay debajo de un agente que aguanta producción en las 13 capas de un sistema de IA real, y cuánta autonomía darle a cada uno en autonomía por diseño.
Referencias
- Cemri, M., et al. (2025). Why do multi-agent LLM systems fail? UC Berkeley. arXiv:2503.13657. https://arxiv.org/abs/2503.13657
- Anthropic. (2025, diciembre). Agent Skills: formato abierto de empaquetado basado en carpetas (SKILL.md) con divulgación progresiva. https://anthropic.skilljar.com/introduction-to-agent-skills