¡Despierta, Neo! Agentes, skills y subagentes ya estaban en Matrix
Tabla de contenido
Cuando pienso en agentes, skills y subagentes, me viene Matrix a la cabeza. No porque Copilot vaya a desenchufarnos de una cápsula —eso espero—, sino porque la película nos dejó un mapa mental bastante útil: el Arquitecto, Neo, el código de Matrix y programas con objetivos propios.
Y ahora la pregunta práctica: si le pido a Copilot que revise la seguridad de una API, ¿qué debería crear: instrucciones, una skill, un agente o un subagente? La respuesta rápida es «depende». Voy a tirar de la analogía para aclararlo, con una salvedad: Matrix es una metáfora, no un diagrama de arquitectura literal.
Las instrucciones: el código de Matrix #
Las instrucciones son el código de Matrix: las reglas que definen cómo funciona ese mundo. Neo puede moldearlo a su antojo; nosotros, en un proyecto, escribimos las convenciones que Copilot debería respetar: arquitectura, versiones, formato de errores o comandos para ejecutar las pruebas.
En Copilot hay instrucciones generales y otras acotadas a archivos o tareas. Pero ojo: no somos Neo. El entorno decide cuándo se aplican y una instrucción como «no registres datos sensibles» orienta al modelo, pero no sustituye permisos, controles de salida, pruebas ni revisión humana.
El agente principal: el Arquitecto de nuestro pequeño Matrix #
El agente principal hace de Arquitecto: fija el objetivo global y coordina especialistas. Interpreta la tarea, decide los pasos, usa herramientas y ajusta el plan según los resultados:
Objetivo → interpretar → actuar → observar → ajustar → resultado
El agente en ejecución es el sistema que trabaja; un agente personalizado configura su rol y criterios, y puede definir herramientas según el entorno. Su archivo no crea por sí solo un Arquitecto omnisciente con memoria permanente.
Tiene sentido crear un agente personalizado cuando se repite un rol con responsabilidad y criterios reconocibles: implementar una funcionalidad, hacer una revisión de solo lectura o diagnosticar una migración. Si solo necesitas pedir una cosa puntual, empieza con un prompt.
Skill: la descarga de Kung Fu y Jiu-jitsu de Neo #
Cuando a Neo le cargan Kung Fu y Jiu-jitsu, sabe pelear al instante. Una skill se parece a esa descarga: aporta conocimiento y procedimientos reutilizables. En Copilot suele organizarse alrededor de un SKILL.md y puede incluir ejemplos, referencias, plantillas o scripts.
Una skill no reentrena el modelo; carga conocimiento e instrucciones cuando corresponde. Sus scripts tampoco se ejecutan solos: hacen falta herramientas y permisos.
Una skill merece la pena cuando el procedimiento se repite o varios agentes necesitan aplicar los mismos criterios. Por ejemplo, create-api-endpoint podría explicar cómo leer el contrato, añadir pruebas y validar entradas.
Subagentes: Smith, el Keymaker y compañía #
El Keymaker abre puertas; Smith, Brown y Jones tienen sus propios objetivos. Piensa en especialistas: el principal les delega una misión acotada y decide qué integrar.
Pequeña licencia de guion: el Keymaker es un programa, no un agente. «Subagente» describe cómo se ejecuta el trabajo, no una clase distinta de archivo: un agente personalizado puede ser principal o subagente según quién lo invoque.
El encargo debe concretar objetivo, contexto, límites y resultado esperado. «Mira esto» no es una especificación; es improvisar con mucha confianza.
Smith puede ser subagente del Arquitecto y agente principal en otra tarea. Si el harness admite delegación anidada, puede coordinar sus propios subagentes. El papel depende de quién delega; multiplicar trabajadores —como hace Smith— no es lo mismo que delegar.
El contexto separado evita ruido, pero no significa filesystem aislado: dos agentes podrían escribir los mismos archivos. Delegar suma coordinación y latencia; no garantiza calidad ni velocidad.
Cuatro piezas que se combinan #
| Pieza | En Matrix | En el proyecto |
|---|---|---|
| Instrucciones | El código que Neo puede moldear | Reglas estables, como no registrar secretos |
| Skill | La descarga de Kung Fu y Jiu-jitsu | Checklist reutilizable |
| Agente principal | El Arquitecto, que reparte trabajo y mantiene el objetivo | Decide cómo avanzar en el proyecto |
| Subagente | Keymaker, Smith, Brown o Jones, con misiones distintas | Revisa una parte del proyecto y devuelve hallazgos |
No son excluyentes: un agente puede seguir instrucciones, cargar una skill y delegar una revisión.
Tres arquitecturas que sí funcionan #
No hay una única forma correcta. La elección depende del tamaño del repositorio, la variedad de tareas y si el aislamiento compensa la coordinación.
1. Generalista con skills #
Un agente de desarrollo carga skills para tareas repetibles: crear endpoints, añadir telemetría o generar pruebas. Ideal para equipos pequeños y repositorios homogéneos: menos coordinación y conocimiento duplicado.
2. Orquestador con subagentes #
Un agente principal reparte trabajo independiente entre especialistas de investigación, arquitectura, implementación o revisión, y luego integra los resultados. Encaja en cambios transversales si cada misión tiene límites claros.
El paralelismo no sale gratis: añade latencia, coordinación y riesgo de conflictos de escritura. Si hace falta una reunión para coordinar a los agentes, algo hemos modelado mal.
3. Agentes especializados con skills compartidas #
Agentes de arquitectura, implementación y revisión pueden compartir skills. Cada rol mantiene sus criterios y el procedimiento no acaba copiado en tres sitios, dos de ellos desactualizados.
No son fases de madurez. Empieza por el patrón más sencillo y delega solo cuando haya una tarea separable con un resultado claro.
Empieza por lo más sencillo #
- Petición puntual: prompt.
- Reglas recurrentes: instrucciones.
- Procedimiento reutilizable: skill.
- Otro rol o criterio: agente personalizado.
- Tarea separable: subagente.
No es una escalera obligatoria. Si basta una instrucción o un script, para ahí; combina piezas solo cuando aporte valor.
Menos ejército, más criterio #
Un agente para controladores, otro para DTOs, logs y tests parece organizado hasta que toca coordinarlos. Muchas veces basta un agente de implementación, skills compartidas y una revisión delegada cuando aporta otra perspectiva.
En seguridad, comprueba herramientas y permisos reales; revisa scripts y skills externas como dependencias y no incluyas secretos en prompts. Modelo, producto y harness son piezas distintas: usar Claude en Copilot no equivale a ejecutar Claude Code.
Mi regla final, menos vistosa que un organigrama con veinte agentes: identifica reglas, conocimiento, responsabilidades y trabajo delegable. Crea solo lo necesario y comprueba el resultado. La responsabilidad sigue siendo nuestra.