¿Para qué sirve un agente si ya tienes skills y comandos en Claude Code?
Cuando las skills ya encapsulan toda la lógica, ¿qué aporta definir un agente por separado? La respuesta está en el modelo de ejecución futuro y en cómo se orquestan los subagentes especializados.
El punto de confusión
Si ya tienes una skill que encapsula toda la información necesaria para ejecutar una tarea — los pasos, el contexto, las reglas — la pregunta es legítima: ¿qué añade definir un agente por separado? ¿No es simplemente overhead burocrático?
La respuesta corta es: en el presente, puede parecer overhead. En el contexto de una arquitectura agéntica, es la diferencia entre tener herramientas sueltas y tener un sistema que puede operar de forma autónoma y coordinada.
El error conceptual de fondo: confundir la herramienta con el agente que la usa. Una skill es lo que el agente puede hacer. El agente es quien decide cuándo y cómo hacerlo, con qué prioridad y en qué contexto.
La analogía del carpintero
La forma más clara de entender la diferencia entre skills, comandos y agentes es a través de una analogía de oficio:
| Concepto SDD | Analogía |
|---|---|
| Skill | Herramienta |
| Comando | Receta |
| Agente | Carpintero |
El carpintero no es el martillo. Conoce qué martillo usar, cuándo cambiar a la sierra y cómo combinar ambas herramientas para construir algo que ninguna herramienta podría producir sola. Eso es exactamente lo que hace el agente en un sistema SDD.
Qué aporta definir el agente explícitamente
Hilo de ejecución independiente
El agente corre en un contexto separado del hilo principal. Puede ejecutarse en background, pausarse, reintentarse y auditarse de forma aislada. Las skills no tienen ese ciclo de vida.
Orquestación entre agentes especializados
En un sistema multi-agente, cada agente tiene un dominio: backend-agent, testing-agent, review-agent. Un orquestador les asigna tareas y gestiona sus dependencias. Sin agentes definidos, no hay piezas que orquestar.
Contexto y memoria propios
El agente puede tener su propio CLAUDE.md, sus propias reglas y su propia capa de memoria. Esto permite especialización real: el backend-agent conoce el esquema de base de datos, el testing-agent conoce la suite de tests.
Preparación para Claude 4 y modelos agénticos
Anthropic y otros proveedores están avanzando hacia modelos diseñados para ejecutarse como agentes persistentes. Definir hoy los límites de responsabilidad de cada agente es la inversión que pagará dividendos cuando esa capacidad sea estable.
Por qué esto importa más de lo que parece hoy
Hoy, Claude Code opera principalmente de forma interactiva: el desarrollador da instrucciones y el modelo responde. El modelo agéntico que se está construyendo es diferente: agentes especializados que reciben tickets, los procesan de forma autónoma, se comunican entre sí y devuelven resultados — sin intervención humana en cada paso.
En ese modelo, la definición del agente no es un fichero de configuración opcional. Es la unidad fundamental de composición del sistema. Un agente bien definido tiene:
- Un dominio claro de responsabilidad (qué puede y qué no puede hacer)
- Sus propias reglas en .claude/agents/<nombre>.md
- Skills específicas montadas sobre él
- Un punto de entrada bien definido para el orquestador
Conclusión práctica: definir el agente hoy, aunque parezca overhead, es la inversión de arquitectura que hace que el sistema sea extensible mañana. Las skills son el "qué"; el agente es el "quién" y el "cuándo". Sin un "quién" claro, las skills son solo fragmentos de lógica flotando sin estructura de ejecución.
Cuándo no merece la pena definirlo todavía
No todo flujo de trabajo necesita un agente con fichero propio de configuración. Las señales de que todavía es prematuro:
El flujo es puntual y no se repetirá
Una tarea de migración única no merece arquitectura agéntica.
No hay un segundo agente con quien coordinarse
Si solo hay un agente, el overhead de definirlo formalmente es escaso pero real.
El equipo no ha adoptado SDD todavía
Añadir agentes sin tener specs claras solo amplifica el ruido. Primero los cimientos.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.