Arquetipos de agente

Los agentes son los ejecutores especializados que la sesión principal convoca y orquesta para construir el producto.

El principio

Un agente no es un prompt con tareas. Es una perspectiva. La sección Expertise al inicio de cada agente define desde qué punto de vista piensa, qué tecnologías domina y qué criterio de calidad aplica. Esa identidad es lo que produce buenas decisiones ante la ambigüedad.

La separación de agentes por rol no es organizativa — es epistemológica. El implementador que revisa su propio código siempre lo aprueba. El revisor existe como entidad separada porque su identidad es encontrar problemas.

No hay plantillas — hay arquetipos

Versiones anteriores incluían plantillas de agentes listas para copiar. La práctica demostró que era un error: los agentes correctos dependen del proyecto. Una plantilla genérica produce agentes mediocres con la ilusión de estar listos.

Lo que es estable entre proyectos son los arquetipos de rol:

Arquetipo Función
Arquitecto Decisiones técnicas de alto nivel, árbitro
Implementador Dar forma al código siguiendo estándares
Revisor Encontrar problemas en el trabajo de otros
Tester Diseñar y ejecutar pruebas
Documentador Mantener la documentación viva

A estos se suman los agentes de las fases tempranas — PRD (Product Requirements Document) y UX/UI (experiencia / interfaz de usuario) — que también se crean a la medida del proyecto (ver F2.2 y F3.1 del workflow).

Cómo crear los agentes de tu proyecto

Sigue las pautas de Agentes:

  1. Analiza el backlog (o los PRDs, para los agentes tempranos) y decide qué agentes necesita este proyecto — la decisión es trabajo de juicio
  2. Escribe cada agente con su sección Expertise adaptada al stack y contexto reales
  3. Asigna a cada uno el modelo más económico que ejecute bien su tarea (ver Eficiencia)
  4. Declara sus skills/MCPs (Model Context Protocol) y sus reglas de comportamiento — no cuándo invocarlo: el gate, el batch y el reparto por acción viven en las skills que orquestan el ciclo (ver Agentes → Dónde viven las decisiones de invocación)
  5. Extiende los estándares base con los criterios específicos de su dominio