1. Formateador de Notas de Reunion
Despues de una reunion, el usuario invoca /format-notes y pega las notas en bruto. El Command produce un resumen estructurado con decisiones, tareas pendientes, responsables y fechas limite. Este es el sistema minimo viable — sin Agents, sin Workflows. Un Command es un prompt guardado: deterministico, activado por el usuario, mismo comportamiento cada vez.
Workflow
Entidades
| Entidad | Tipo | Proposito |
|---|---|---|
| com-format-notes | Command | Prompt guardado invocado por el usuario. Recibe notas de reunion en bruto, aplica la Rule para estructura consistente y consulta la KB para asociar tareas a miembros del equipo. Deterministico — mismo formato cada vez. |
| rul-output-format | Rule | Impone la estructura del output: Decisiones, Tareas Pendientes (con responsable y fecha limite), Preguntas Abiertas y Proximos Pasos. Se aplica automaticamente — el usuario nunca tiene que pedir el formato. |
| kno-team-roster | Knowledge Base | Nombres, roles y responsabilidades de los miembros del equipo. El Command lo consulta para asignar tareas a las personas correctas y llenar vacios de responsabilidad en las notas en bruto. |
Por que un Command y no un Agent? Un Command es una accion unica y deterministica — un prompt guardado que siempre produce el mismo comportamiento base. Un Agent tendria sentido si el sistema necesitara tomar decisiones, adaptarse al contexto u operar de forma autonoma. Aqui, la tarea es siempre la misma: formatear notas. Command es la opcion correcta.
2. Asistente de Revision de PRs
Un developer invoca directamente el Agent code-reviewer. El Agent analiza el diff actual en busca de bugs, violaciones de estilo y problemas de seguridad. A diferencia del Command del Ejemplo 1, este Agent adapta su comportamiento al contexto — diffs diferentes producen estrategias de analisis diferentes. Usa un Skill para formateo estructurado y consulta la guia de estilo del equipo. No se necesita Workflow: hay un solo Agent, y un solo Agent no requiere orquestacion.
Workflow
Entidades
| Entidad | Tipo | Proposito |
|---|---|---|
| age-spe-code-reviewer | Agent | Trabajador especializado con un dominio: revision de codigo. Tiene su propia identidad y toma decisiones durante la ejecucion (en que enfocarse, evaluacion de severidad). Se ejecuta en una ventana de contexto aislada. Invocado directamente por el usuario o por coincidencia de descripcion. |
| ski-format-report | Skill | Procedimiento de formateo reutilizable — sin identidad propia, sin decisiones. Estructura los hallazgos en bruto del Agent en un reporte limpio con secciones por severidad. Podria ser reutilizado por otros Agents en diferentes workflows. |
| rul-review-standards | Rule | Restringe cada revision: los hallazgos deben tener una severidad (critical / warning / info), una referencia de linea especifica y una sugerencia accionable. Prohibe nitpicks cosmeticos y feedback vago. |
| kno-style-guide | Knowledge Base | Convenciones de codigo del equipo: patrones de nombrado, manejo de errores, expectativas de tests, limites arquitectonicos. El Agent lo consulta para calibrar hallazgos contra los estandares especificos del equipo. |
Por que un Agent y no un Command? El code-reviewer se adapta al contexto — diffs diferentes disparan estrategias de analisis diferentes. Un Command siempre produce el mismo comportamiento base. El Agent toma decisiones: donde profundizar, que tan severo es un problema, que priorizar. Ese razonamiento contextual es lo que distingue un Agent de un Command.
3. Triaje de Soporte al Cliente
El usuario invoca el Workflow support-triage con un ticket entrante. El Workflow coordina dos Agents: un clasificador que determina urgencia y departamento, y un redactor de borradores que genera respuestas para casos urgentes. Este es el primer ejemplo con un Workflow — porque dos Agents con responsabilidades diferentes necesitan coordinacion y transferencia de output entre ellos. El Workflow decide la secuencia y toma decisiones de enrutamiento.
Workflow
Entidades
| Entidad | Tipo | Proposito |
|---|---|---|
| wor-support-triage | Workflow | Coordina la ejecucion: lanza primero al clasificador, lee su output para determinar urgencia, luego lanza condicionalmente al redactor de borradores para tickets urgentes. No ejecuta tareas directamente — solo coordina y transfiere outputs entre Agents. |
| age-spe-classifier | Agent | Determina urgencia (critical, high, normal, low) y departamento (billing, technical, account, general). Usa el Skill sentiment-check para detectar lenguaje frustrado o propenso a escalacion. Devuelve una clasificacion estructurada. |
| age-spe-draft-responder | Agent | Solo se invoca para tickets urgentes. Consulta el Product FAQ para redactar una respuesta precisa y empatica. Ejecuta el Skill sentiment-check para validar el tono antes de devolver el borrador. |
| ski-sentiment-check | Skill | Reutilizable por ambos Agents. Analiza texto en busca de tono emocional, senales de frustracion y riesgo de escalacion. Sin identidad propia — una capacidad tecnica generica que cualquier Agent puede usar. |
| rul-sla-compliance | Rule | Impone umbrales de tiempo de respuesta: tickets criticos en 1 hora, estandar en 24 horas. El Workflow verifica las ventanas de SLA antes de programar la respuesta. |
| kno-product-faq | Knowledge Base | Preguntas frecuentes, problemas conocidos y pasos de resolucion. El redactor de borradores lo consulta para generar respuestas precisas en lugar de inventar soluciones. |
Por que un Workflow y no solo dos Agents? Porque un Agent no puede invocar a otro Agent — eso es un anti-patron. Cuando dos o mas Agents necesitan coordinacion y transferencia de output entre ellos, un Workflow es la entidad correcta. El Workflow decide la secuencia (clasificar primero), toma decisiones de enrutamiento (es urgente?) y transfiere el output del clasificador al redactor de borradores.
4. Generador de Brief de Campana
Un lider de marketing invoca el Workflow campaign-brief con los objetivos de la campana y la audiencia objetivo. El Workflow coordina un Agent estratega y un Agent planificador de contenido para producir un brief completo. Este ejemplo anade un Command (/export-brief) como accion independiente del usuario — no pasa por el Workflow, porque un Command siempre es activado manualmente por el usuario y no tiene sentido como un paso que otra entidad invocaria.
Workflow
Entidades
| Entidad | Tipo | Proposito |
|---|---|---|
| wor-campaign-brief | Workflow | Coordina dos Agents en secuencia: primero el estratega (mensajes + canales), luego el planificador de contenido (calendario). Transfiere el output del estratega al planificador de contenido. No ejecuta tareas directamente. |
| age-spe-strategist | Agent | Desarrolla mensajes clave, propuestas de valor y recomendaciones de canales. Usa el Skill competitor-scan para validar diferenciacion. Consulta las directrices de marca para consistencia de voz. |
| age-spe-content-planner | Agent | Crea un calendario de contenido con fechas, canales, tipos de contenido y temas. Recibe el output del estratega para asegurar alineacion. Consulta las directrices de marca para consistencia. |
| ski-competitor-scan | Skill | Procedimiento reutilizable — analiza el posicionamiento de competidores. Sin identidad propia. Devuelve brechas de diferenciacion y oportunidades de mensajes. Podria ser usado por cualquier Agent en cualquier Workflow. |
| com-export-brief | Command | Accion deterministica invocada por el usuario. Formatea el brief generado en un entregable limpio. Siempre se activa manualmente — ningun Workflow o Agent lo invocaria. Un prompt guardado para exportacion. |
| kno-brand-guidelines | Knowledge Base | Tono de voz, identidad visual, marcos de mensajes aprobados, posicionamiento competitivo. Ambos Agents lo consultan para mantener el brief alineado con la marca. |
5. Pipeline de Planificacion de Sprint
El usuario invoca el Workflow sprint-pipeline al final de un sprint. El Workflow coordina tres Agents en secuencia: analisis retrospectivo, estimacion de velocidad y planificacion del sprint. Este ejemplo usa todos los tipos de entidad: un Workflow orquesta, tres Agents ejecutan, dos Skills aportan capacidades reutilizables, una Rule restringe, una Knowledge Base informa, un Command exporta y un Hook permite activacion automatica como alternativa a la invocacion manual.
Workflow
Entidades
| Entidad | Tipo | Proposito |
|---|---|---|
| wor-sprint-pipeline | Workflow | Coordina tres Agents en secuencia: retro-analyst → velocity-calculator → sprint-planner. Transfiere outputs entre ellos (retro alimenta velocidad, velocidad alimenta planificacion). No ejecuta tareas directamente. |
| age-spe-retro-analyst | Agent | Revisa tickets completados, identifica que salio bien, que no, y bloqueantes recurrentes. Consulta la KB del equipo para responsabilidades y alineacion con OKRs. Devuelve una retrospectiva estructurada. |
| age-spe-velocity-calculator | Agent | Analiza story points completados vs. planificados en los ultimos 3 sprints. Calcula velocidad movil y capacidad ajustada por disponibilidad. Consulta la KB del equipo para datos de headcount y ausencias. |
| age-spe-sprint-planner | Agent | Toma la estimacion de velocidad y el backlog, usa el Skill backlog-scorer para priorizar items y el Skill risk-assessment para marcar los de alto riesgo. Redacta el plan del sprint dentro de las restricciones de capacidad. Consulta la KB del equipo para alineacion con OKRs. |
| ski-backlog-scorer | Skill | Procedimiento reutilizable — puntua items del backlog por valor de negocio, esfuerzo y alineacion con OKRs. Sin identidad propia. Devuelve una lista rankeada. Podria ser usado por cualquier Agent de planificacion. |
| ski-risk-assessment | Skill | Procedimiento reutilizable — evalua riesgo tecnico, riesgo de dependencias y riesgo por gaps de conocimiento. Marca items que necesitan mitigacion. Sin identidad propia — una capacidad generica. |
| rul-capacity-constraints | Rule | Dos limites estrictos: los puntos totales del sprint no pueden exceder la capacidad ajustada por velocidad, y no mas de 2 items de alto riesgo por sprint. Restringe el comportamiento — no ejecuta. |
| kno-team-okrs | Knowledge Base | Miembros del equipo, roles, habilidades, disponibilidad y OKRs actuales. Referencia estatica consultada por los tres Agents para propiedad, capacidad y alineacion. |
| hok-sprint-close | Hook | Trigger basado en eventos que se dispara automaticamente cuando el sprint se marca como cerrado. Invoca el Workflow sin intervencion del usuario. Una alternativa a la invocacion manual — el usuario tambien puede invocar el Workflow directamente. |
Dos caminos de invocacion. El usuario puede invocar el Workflow manualmente, o el Hook puede activarlo automaticamente al cerrar el sprint. Ambos caminos llevan al mismo Workflow. El Command (/publish-plan) siempre es invocado por el usuario — es una accion separada para exportar el plan final despues de que el usuario lo revise.
Que lo hace complejo? Nueve entidades que cubren todos los tipos del sistema. Dependencias secuenciales entre Agents (cada uno necesita el output del anterior). Dos Skills compartidos reutilizables entre workflows. Un Hook para automatizacion. Un Command para la accion del usuario. Un Workflow que lo coordina todo. Asi luce un sistema agentico de nivel produccion.