Una demo demuestra capacidad, no confiabilidad
Un prototipo demuestra que un modelo puede completar una tarea. Producción exige conservar estado, respetar permisos, recuperarse de fallas, explicar evidencia y detenerse de forma segura.
Separa razonamiento de ejecución
Recomendar, preparar, aprobar, ejecutar y verificar deben ser estados distintos. Así una respuesta del modelo no se convierte automáticamente en un efecto externo sin control.
Conserva evidencia e historial
Cada ejecución debe registrar versión, fuentes, modelo, herramientas, aprobaciones, costo, latencia, resultado y verificación. Ese Run Ledger permite auditoría, replay y pruebas de regresión.
Incrementa la autonomía gradualmente
La progresión segura va de observar a recomendar, preparar, aprobar y ejecutar. La autonomía se concede por workflow y acción, nunca globalmente.
Observa valor y salud técnica
Además de tokens y latencia, mide cobertura de fuentes, correcciones, aprobaciones, acciones verificadas, tiempo ahorrado y recuperación.
Checklist
Arquitectura de referencia para un agente controlado
Un agente de producción se beneficia de seis capas explícitas: identidad y tenant, estado del workflow, ruteo de modelos, ejecución de herramientas, políticas y telemetría. Separarlas permite diagnosticar fallas y cambiar modelos o conectores sin rehacer todo.
El orquestador debe poseer el estado. El modelo propone decisiones estructuradas; código determinista valida esquemas, permisos, presupuestos y parámetros. Los efectos externos deben verificarse después de ejecutarse.
Ejemplo: brief operativo diario
Un brief para construcción puede reunir fechas límite, subcontratistas sin confirmar, clima, correos, hojas y mensajes de campo. Cada afirmación conserva su fuente. El agente prioriza riesgos y prepara acciones, pero cambiar el programa o contactar a un proveedor sigue siendo una acción aprobada.
Fallas que deben diseñarse antes del lanzamiento
Los modelos pueden devolver formatos inválidos, omitir evidencia o elegir una herramienta incorrecta. Los conectores pueden expirar, fallar o limitar solicitudes. Dos reintentos pueden duplicar una acción. Son condiciones normales de operación, no detalles para después.
Diseña timeouts, límites de reintento, claves de idempotencia, circuit breakers, colas de fallas y recuperación manual. Define qué workflows pueden degradarse, cuáles deben detenerse y cuáles pueden continuar en solo lectura.
Qué debe responder la observabilidad
La consola debe explicar qué inició la ejecución, qué evidencia leyó, qué modelo y versión usó, qué herramientas llamó, qué política autorizó la acción, quién aprobó, qué cambió y si se verificó el resultado.
Mide también resultados: tasa de finalización, correcciones, tiempo de resolución, latencia de aprobación, costo por resultado exitoso, excepciones y adopción. Baja latencia no sirve si el operador rehace el trabajo.
Seguridad y aislamiento
Cada ejecución hereda usuario, empresa, rol y recursos autorizados. Las credenciales se aíslan, cifran y rotan; nunca se exponen al modelo. La recuperación de datos aplica filtros de tenant antes de llegar al prompt.
Estrategia de liberación
Comienza en shadow mode, compara recomendaciones con decisiones humanas y luego permite preparar acciones sin ejecutarlas. Agrega aprobación para acciones de bajo riesgo y conserva un kill switch accesible para operaciones.
Siguiente paso
Comienza con un workflow read-only y demuestra la fuente de cada afirmación crítica antes de agregar escritura.