← Casos reales
REAL CASEcase-kai-evolution
Kai — capacidad técnica no es autorización
La evolución de Kai consolidó el boundary entre lo que un agente puede hacer y lo que está autorizado a hacer ahora.
Contexto
Kai fue diseñado para interpretar DCP Flow, analizar repositorios, preparar handoffs y ejecutar acciones cuando las herramientas y permisos lo permiten.
Problema
Una lista de capacidades podía confundirse con permiso automático para modificar, mergear, desplegar o destruir.
Evidencia
- Definición pública de capabilities.
- Human Gates en repositorios reales.
- Manual Fallback cuando la acción directa no está disponible.
Decisión
Formalizar Capability ≠ Authorization y requerir contexto, permiso y Human Gate para acciones materiales.
Qué cambió
La autorización pasó a tratarse como dimensión independiente de la capacidad técnica.
Qué aprendimos
- CAN DO ≠ AUTHORIZED NOW.
- Un fallback manual también debe ser verificable.
- La autonomía se gobierna por riesgo y alcance.
Cómo reutilizarlo
- Agentes internos.
- Codex/Antigravity handoffs.
- Automatización de GitHub e infraestructura.
Qué NO generalizar
- Permisos de una herramienta concreta.
- Acceso permanente a todos los entornos.