LLMOps evoluciona hacia AgentOps

Actualizar un modelo ya era delicado. Actualizar un agente que consulta documentos, llama a seis herramientas, conserva memoria y puede aprobar una gestión cambia bastantes más cosas que un endpoint.

LLMOps organizó la operación de aplicaciones con modelos: versiones, evaluaciones, despliegues, costes y observabilidad. AgentOps amplía ese trabajo a sistemas que recorren trayectorias y producen efectos. La unidad operativa pasa a ser el trabajo completo, con todos sus pasos y consecuencias.

Qué cambia de verdad

En una aplicación LLM sencilla, una entrada produce una salida. En un agente, una entrada puede generar diez turnos, tres búsquedas, una transferencia, una espera humana y dos escrituras en sistemas externos. Un fallo temprano altera todo lo que viene después.

AgentOps incorpora al ciclo operativo piezas que antes quedaban fuera:

OpenAI recomienda financiar como capacidades compartidas la identidad, los conectores de confianza, el conocimiento, las evaluaciones, la observabilidad, el model routing y los patrones reutilizables de agentes (OpenAI, julio de 2026). Esa lista describe bastante bien la plataforma mínima de AgentOps.

Una versión debe poder reconstruirse

Para reconstruir una ejecución hay que guardar algo más que el nombre del modelo y el prompt: versión de instrucciones, esquemas y descripciones de herramientas, configuración de recuperación, índice documental, estrategia de memoria, controles, permisos, límites y código de orquestación.

El manifiesto de despliegue debería enlazar todas esas versiones. Si el comportamiento cambia, podemos comparar qué componente cambió y reproducir la combinación anterior. Las APIs también advierten que el comportamiento puede variar entre snapshots y recomiendan versiones fijadas junto con evaluaciones (OpenAI API).

No todo necesita publicarse al mismo ritmo. Una política de importe puede cambiar sin desplegar el modelo; un índice se actualiza cada hora; una herramienta estrena un parámetro. El manifiesto crea una fotografía lógica de piezas que tienen ciclos distintos.

Del test de respuesta a la evaluación del recorrido

Anthropic señala que los agentes son más difíciles de evaluar porque operan durante varios turnos, modifican estado y se adaptan a resultados intermedios (Anthropic, 2026). Un resultado aparentemente correcto puede esconder una fuente prohibida, una acción duplicada o cuatro intentos innecesarios.

Una batería útil combina tres niveles:

• Componente: contratos de herramientas, recuperación, clasificadores y salidas estructuradas.
• Trayectoria: secuencia de acciones, permisos, reintentos, escalados y condición de salida.
• Resultado: calidad del entregable, efecto empresarial, coste y revisión necesaria.

Los casos incluyen errores de API, información contradictoria, aprobaciones rechazadas, reinicios y datos que cambian durante la ejecución. También hay pruebas de regresión tomadas de incidentes reales. Cada fallo útil se convierte en un caso que no debería repetirse.

Desplegar un agente sin soltarlo de golpe

El despliegue progresivo adquiere otra dimensión cuando el sistema actúa. Primero puede ejecutarse en sombra y comparar sus decisiones. Después prepara borradores, pasa a aprobación obligatoria y solo automatiza segmentos con evidencia suficiente.

1. Entorno de evaluación. Casos congelados, servicios simulados y ninguna acción real.
2. Sombra. Datos reales autorizados, sin modificar sistemas; se compara con el trabajo humano.
3. Piloto con aprobación. Usuarios limitados y consecuencias revisadas antes de ejecutarse.
4. Autonomía acotada. Solo acciones reversibles, importes o segmentos que superan el umbral.
5. Ampliación gradual. Más alcance si calidad, coste, incidentes y adopción se mantienen.

Cada etapa necesita una ruta de reversión. Volver atrás no significa únicamente seleccionar el modelo anterior. Puede implicar cerrar nuevas herramientas, reducir permisos y reanudar trabajos con un estado compatible.

Operar es decidir qué hacer ante el fallo

Una alerta debe conducir a una acción conocida. Si suben los errores de recuperación, ¿se bloquean respuestas sin evidencia? Si cae la herramienta de pedidos, ¿el agente espera, escala o entrega un borrador? Si el coste por resolución se duplica, ¿reduce iteraciones o enruta a otro modelo?

En observabilidad para agentes proponemos medir resultado, trayectoria, operación y economía. AgentOps añade responsables y procedimientos: quién recibe la alerta, quién puede detener, qué evidencia permite reabrir y cómo se comunica al usuario.

Las trazas sirven para depurar. El registro de auditoría cumple otra función: conservar acciones relevantes con la integridad, la identidad y la retención que exige el negocio.

Retirar también es una operación

Los agentes dejan trabajos abiertos, memoria, credenciales, índices, cachés y aprobaciones pendientes. Una retirada debe decidir qué ejecuciones terminan, cuáles migran y cuáles se cancelan. Después revoca identidades, desactiva herramientas, conserva el registro exigido y elimina datos conforme a la política.

La dependencia de defaults es especialmente frágil. El registro de versiones del SDK de agentes de OpenAI muestra que el modelo predeterminado puede cambiar entre releases y recomienda fijarlo explícitamente cuando se necesita conservar comportamiento (OpenAI Agents SDK). En producción, ningún componente capaz de alterar el resultado debería cambiar por accidente al actualizar una librería.

Preguntas frecuentes