F10 — Learn & Evolve

Agent Evolution and Lifecycle

Cómo se introducen, gobiernan, miden y evolucionan agentes en el portfolio

Versión: 5.0.0 | Estado: Activo | Tipo: Core / Phase 10 Framework: AI-First Engineering Framework v6.5

---

1. Propósito

Este documento define el proceso de evolución de agentes una vez que ya existen o están siendo considerados como assets reutilizables del portfolio.

El catálogo de referencia vive en reference/cross_cutting/REF_CROSS_Agent_Catalog.md. Este documento define el operating model para:

• incubar agentes nuevos
• promover agentes a reusable assets
• retirar agentes que ya no aportan valor
• capturar aprendizaje operativo
• gestionar la autonomía progresiva (ver reference/cross_cutting/REF_Progressive_Autonomy_Pattern.md)

---

2. Preguntas que esta fase debe responder

• ¿Este agente sigue aportando valor al negocio?
• ¿Su nivel de autonomía sigue siendo adecuado?
• ¿Su costo y latencia siguen siendo aceptables?
• ¿Sus guardrails siguen siendo suficientes?
• ¿Debe pasar de piloto a approved, o de approved a deprecated?
• ¿Se han cumplido los SLOs operativos definidos en la Agent Card?

---

3. Estados del lifecycle

Proposed → Experimental → Pilot → Recommended → Approved → Deprecated → Retired

Estado	Descripción	Duración típica
Proposed	Idea documentada, sin implementación	1-2 semanas
Experimental	Prototipo funcional en sandbox	1-4 semanas
Pilot	Uso limitado con usuarios reales	2-6 semanas
Recommended	Valor comprobado, disponible para adopción	Indefinido
Approved	Asset organizacional oficial	Indefinido
Deprecated	Marcado para retiro, alternativa disponible	2-4 semanas
Retired	Eliminado del portfolio activo	Terminal

---

4. Criterios de promoción

Proposed → Experimental

• problema claro y documentado
• owner asignado
• Agent Card inicial creada
• tooling identificado
• presupuesto estimado (tokens/mes)

Experimental → Pilot

• evaluación básica superada (golden dataset ≥ 70 % accuracy)
• caso de uso real identificado
• riesgo acotado y documentado en risk register
• guardrails mínimos implementados

Pilot → Recommended

• evidencia de valor medible (métricas de negocio)
• métricas estables durante ≥ 2 semanas
• feedback positivo de usuarios o equipos
• costo dentro del budget aprobado
• latencia P95 dentro del SLO

Recommended → Approved

• reuse comprobado en ≥ 2 contextos
• documentación completa (Agent Card, runbook, incident playbook)
• observabilidad y control suficientes (traces, dashboards)
• aprobación de la AI Factory
• security review completado (OWASP Agentic checklist)

Approved → Deprecated

• aparición de mejor alternativa
• costo o complejidad injustificados
• cambios de arquitectura o riesgo
• notificación a consumidores con ≥ 2 semanas de anticipación

---

5. Métricas operativas del agente

Cada agente activo debe reportar las siguientes métricas:

Métrica	Umbral mínimo	Frecuencia
Task success rate	≥ 85 %	Diario
Grounded response rate	≥ 90 %	Diario
P95 latency	≤ SLO definido	Diario
Token cost / task	≤ budget aprobado	Semanal
Human override rate	< 15 %	Semanal
Incident count	0 critical, < 3 minor/mes	Mensual
User satisfaction (CSAT)	≥ 4.0 / 5.0	Mensual

---

6. Señales de revisión obligatoria

• aumento sostenido de overrides humanos (> 20 % por 2 semanas)
• caída de grounded response rate (< 85 %)
• incremento de incidentes (≥ 2 critical en 30 días)
• cambios regulatorios que afecten al agente
• cambio de modelo base (nueva versión major)
• cambio de tooling o permisos
• exceso de budget > 20 % por 2 semanas consecutivas
• nueva vulnerabilidad OWASP que aplique

---

7. Artefactos mínimos

Artefacto	Descripción	Template
Agent Card	Identidad, capabilities, permisos, SLOs	project/F10_evolution/agent_evolution_plan.yaml
Métricas operativas	Dashboard con las métricas de §5	Grafana / LLMOps tool
Historial de cambios	Log de versiones, config changes, model swaps	Git history + ADR
Incident review	Post-mortem de incidentes (si aplica)	Runbook template
Recomendación de continuidad	Promote, evolve, o retire	Revisión trimestral

---

8. Proceso de revisión trimestral

1. Recopilar métricas — exportar dashboard del trimestre
2. Evaluar SLOs — comparar contra umbrales de §5
3. Revisar incidentes — analizar post-mortems del periodo
4. Evaluar costo vs valor — ROI del agente
5. Decidir estado — mantener, promover, deprecar o retirar
6. Actualizar Agent Card — registrar decisión y justificación
7. Comunicar — notificar a stakeholders el resultado

---

9. Relación con la AI Factory

La AI Factory decide qué agentes se convierten en assets organizacionales y cuáles siguen siendo específicos de un proyecto.

Responsabilidades de la AI Factory:

• mantener el catálogo oficial (reference/cross_cutting/REF_CROSS_Agent_Catalog.md)
• aprobar promociones a estado Approved
• asignar presupuesto de tokens para agentes organizacionales
• coordinar revisiones trimestrales
• gestionar el pattern de autonomía progresiva

---

10. Referencias

• reference/cross_cutting/REF_CROSS_Agent_Catalog.md — catálogo de agentes
• reference/cross_cutting/REF_Progressive_Autonomy_Pattern.md — autonomía progresiva
• reference/cross_cutting/REF_CROSS_Subagent_Isolation_Patterns.md — patrones de aislamiento
• core/F07_Continuous_TEVV/CORE_F07_AI_Evaluation_Quality_Framework.md — evaluación
• core/F09_Deploy_Operate_GenOps/CORE_F09_Observabilidad_FinOps_Alertas.md — observabilidad
• guides/Multi_Agent_Orchestration_Guide.md — orquestación multi-agente
• scripts/schemas/agent_evolution_plan.schema.json — schema de validación