MLOps manejaba modelos que predicen. LLMOps llegó a manejar modelos que generan texto. Y ahora, en 2026, los equipos de datos están corriendo detrás de una tercera capa: AgentOps, la disciplina para gestionar agentes que actúan solos —que mandan correos, modifican bases de datos o aprueban solicitudes sin que nadie revise cada paso.
Por qué la vara sigue subiendo tan rápido
Lo curioso es la velocidad. DevOps tardó una década en madurar como disciplina. MLOps tardó cinco años. LLMOps, dos. AgentOps recién está apareciendo y ya hay estimaciones —de Deloitte— de que la mitad de las empresas que usan IA generativa tendrán agentes desplegados para 2027. El mercado de MLOps por sí solo se proyecta en 4.380 millones de dólares para este año, creciendo casi 40% anual, y la mayoría de los equipos de datos con los que hablo siguen operando con el manual de hace tres años. Ese manual no cubre lo que pasa cuando un agente decide algo mal.
Las tres capas, explicadas sin rodeos
MLOps gestiona predicciones: un modelo de churn dice sí o no, y tú mides precisión. LLMOps gestiona generaciones: un LLM escribe un resumen o responde un ticket, y tú evalúas si el texto es correcto, si no alucina, cuánto cuesta cada llamada. AgentOps gestiona acciones: un agente decide qué herramienta usar, ejecuta un paso y luego decide el siguiente —y ahí el error ya no es un texto raro, es una transacción real que ya se hizo.
Lo que un equipo de MLOps necesita sumar para operar agentes en 2026:
- ▸Tracing de cada paso que da el agente, no solo del resultado final: MLflow 3.14 ya trae observabilidad con un solo comando.
- ▸Evaluaciones automáticas en CI que bloqueen un despliegue si la calidad cae: MLflow 3.15 sumó jueces multimodales para esto.
- ▸Un registro central de qué herramientas y servidores MCP puede tocar cada agente, con permisos por rol.
- ▸Métricas de negocio, no solo de latencia: cuántas acciones del agente terminaron revertidas a mano.
Cómo se ve esto en la práctica
Piensa en un pipeline clásico de scoring de crédito: entra un dato, sale un número, un humano decide con ese número. Ahora piensa en un agente de cobranza que lee el historial, decide si mandar un recordatorio, una oferta de refinanciamiento o escalar el caso a un humano, y lo hace solo. El primer caso se audita revisando el modelo. El segundo se audita revisando cada decisión que tomó el agente, y si tu equipo nunca instrumentó eso, te vas a enterar del problema cuando ya sea un reclamo de un cliente.
Lo que casi nadie dice en voz alta: la mayoría de los equipos de MLOps que conozco no están listos para esto, y no es un problema de herramientas — es que nadie definió todavía quién responde cuando un agente se equivoca.
Quién hace qué en el nuevo stack
Un detalle que se pierde en los diagramas bonitos: estas tres capas casi nunca las opera la misma persona. El Data Engineer sigue siendo dueño de que el dato llegue limpio y a tiempo —eso no cambió con nada de esto—. El ML Engineer clásico se queda con MLOps y con la parte de LLMOps que es puramente de evaluación de modelos. Y la capa de AgentOps, la que decide qué herramientas puede tocar un agente y con qué reglas, cada vez se parece más al trabajo de un AI Agentic Engineer que al de alguien saliendo de un bootcamp tradicional de Machine Learning. Si tu organigrama todavía no tiene ese rol, es una señal de que vas atrasado, no de que no lo necesitas.
Errores comunes al migrar
- ▸Reusar el mismo dashboard de monitoreo de modelos para vigilar agentes, cuando las métricas que importan son distintas.
- ▸Dar acceso amplio a un agente "para probar rápido" y olvidar retirarlo cuando pasa a producción.
- ▸Medir éxito por respuestas generadas en vez de por tareas completadas de principio a fin.
Cómo medir si tu AgentOps está funcionando
Los números que importan acá no son los mismos de un dashboard de ML clásico. Precisión y recall te dicen poco cuando el problema no es "¿la predicción fue correcta?" sino "¿la secuencia de acciones que tomó el agente llegó al resultado que querías, con el mínimo de pasos y sin tocar nada que no debía?". En la práctica, esto se traduce en tres números que sí vale la pena llevar en un dashboard: tasa de finalización de tareas sin intervención humana, costo promedio por tarea completada (contando tokens y llamadas a herramientas, no solo tiempo), y tasa de reversión —cuántas acciones tuvo que deshacer un humano después—. Si no tienes los tres, probablemente estés operando a ciegas aunque el agente "funcione".
Qué pasa si tu empresa no hace esta transición a tiempo
No es un escenario catastrófico, es más aburrido que eso: tu competencia despliega agentes que resuelven en minutos lo que tu equipo resuelve en horas, y tú sigues discutiendo si conviene o no meterte a esto. He visto empresas de retail y de banca en LATAM pasar de "vamos a evaluarlo el próximo trimestre" a "ya perdimos seis meses de ventaja" sin darse cuenta del momento exacto en que cruzaron esa línea. La transición de MLOps a AgentOps no es opcional a mediano plazo, es cuestión de cuándo la haces con calma y cuándo la haces con presión.
Un roadmap realista de 90 días
Nadie migra su stack completo de un mes a otro, y tampoco hace falta. Un plan que sí funciona: en el primer mes, instrumenta tracing sobre un solo flujo de agente que ya tengas corriendo (o uno piloto), aunque sea con las herramientas de MLOps que ya usas hoy. En el segundo, define las tres o cuatro métricas de negocio que de verdad importan para ese flujo y arma un dashboard simple, aunque no sea bonito. En el tercero, recién ahí evalúa si necesitas una plataforma dedicada de AgentOps o si con lo que ya armaste te alcanza para los próximos seis meses. El error más común es saltarse los dos primeros pasos y comprar una plataforma antes de saber qué necesitas medir.
Cómo prepararte para este cambio
Si vienes del mundo de Machine Learning no partes de cero: la base de MLOps (versionado de modelos, monitoreo, CI/CD) se traslada directo. Lo que falta es la capa de agentes. La ruta ML Engineer cubre el stack completo de MLOps clásico, y si tu siguiente paso es meterte de lleno a construir y operar agentes —no solo modelos—, la ruta AI Agentic Engineer es donde se enseña a diseñar los sistemas multi-paso que AgentOps después tiene que vigilar.
Si quieres discutir esto con otros que están migrando sus pipelines ahora mismo, en la Comunidad AI Builders hacemos un taller semanal en vivo donde tocamos justo estos temas de producción, desde 19 USD al mes: https://builders.datapath.ai/?utm_source=datapath_web&utm_medium=blog_body&utm_campaign=ai_builders
AgentOps no es una moda de nombre: es la consecuencia directa de que los agentes ya actúan sobre sistemas reales. Si tu equipo va a operar agentes en 2026, empieza por la ruta ML Engineer, súmale AI Agentic Engineer y revisa el resto de rutas en /cursos.
