Hay un agente en tu cuenta que se desplegó en marzo. Contesta. Factura tokens todos los días. La persona que lo especificó cambió de equipo en mayo, la base de conocimiento que lee se sincronizó por última vez en junio, y nadie abrió una de sus conversaciones desde la semana del lanzamiento.
La pregunta interesante no es si está roto. Es que no tenés ningún procedimiento que te lo diría en un sentido ni en el otro — y la misma frase es cierta para la mayoría de los agentes que cualquier organización está corriendo hoy.
Tres preguntas que nadie puede contestar sobre su propia flota
El 26 de agosto de 2026, en el episodio de McKinsey Talks Talent titulado Your AI agents need performance management, too, la senior partner Kate Smaje —líder global de tecnología e IA de McKinsey— reduce el problema a tres preguntas que un operador debería poder contestar: "How many agents do I actually have? Who is responsible or accountable for their performance? What value are they creating?"
En la misma conversación nombra el modo de falla sin vueltas. Los agentes "need strong life cycle management because they can't exist in perpetuity. A wonderfully fit-for-purpose agent that existed six months ago could possibly be a significant liability today." Su término para lo que se acumula es abandonware: "the things in your networks that have been forgotten about and should no longer exist."
La senior partner Brooke Weddle agrega el supuesto que está debajo: "There's a bias today that any agent is a good thing, but that's simply not true."
El encuadre está tomado prestado de RR.HH., y esa es la parte útil más que un adorno. Las organizaciones saben contratar por una capacidad, evaluar contra ella, corregir, y terminar el vínculo en una fecha definida cuando deja de encajar. Casi ninguna aplica nada de eso al software que decide en su nombre — porque el software históricamente no lo necesitó, y un agente sí: se degrada estando perfectamente quieto.
Un inventario no contesta ninguna de las tres
El primer instinto es una lista de agentes. Contesta la primera pregunta de forma aproximada y las otras dos no las contesta en absoluto, porque la unidad de observación no es el agente. Es el run —una ejecución, del disparo a la salida final— y el registro que deja. "Valor" es un cociente, y no podés calcular un cociente a partir de una lista.
| Registrado por run | Sin eso no podés contestar |
|---|---|
| Identidad del agente y versión | Nada, porque toda métrica promedia en silencio dos agentes distintos |
| Estado terminal, y la clase de falla cuando falló | Si funciona |
| Llamadas a herramientas intentadas contra llamadas exitosas | Si funciona por el motivo que creés |
| Tokens de entrada y salida, atribuidos al paso que los gastó | Cuánto cuesta producir un resultado |
| El veredicto del usuario final, cuando lo dio | Si el resultado sirvió para algo |
| El tenant y la persona dueña a la que pertenece | A quién avisarle |
El campo de versión es el que más se omite y el que rompe todo lo que viene después. Un run que no nombra la definición que ejecutó no se puede comparar con el run anterior: editás un prompt, y la tasa de satisfacción del mes pasado pasa a ser una mezcla de dos poblaciones. Es la disciplina que cualquier equipo aplica a un tag de release, salteada para los agentes porque la edición se siente como escribir y no como desplegar.
Dos de esas filas te dan además el denominador de una economía unitaria real: costo por resultado en vez de costo por token es la única forma en que la tercera pregunta sobrevive al contacto con un área de finanzas.
La responsabilidad es una columna, no una política
Smaje es explícita en que esto no debería caer sobre el CTO: "I would love to see the business owners who use these agents for their workflows take on that responsibility. I don't think this is a technology problem." El responsable de finanzas que cuida a los humanos que hacen el cierre de mes debería cuidar también a los agentes que lo hacen.
El motivo por el que en general no funciona es más mecánico que la conversación de diseño organizacional que lo rodea. Si "quién es dueño de este agente" se contesta con el recuerdo de quién lo pidió, la respuesta es nadie — formalmente nadie, la primera vez que esa persona cambia de equipo. La propiedad federada necesita tres cosas nada extraordinarias antes de poder ser un modelo operativo:
- Un campo de dueño que no pueda ser nulo en la creación. No una descripción, no una etiqueta: una identidad resoluble a la que se enruten las alertas.
- Una postura de riesgo que el dueño no escribió. La condición de Smaje para federar es "guardrails, standards, and clear life cycle management across your organization." El líder de finanzas elige qué hace su agente, no si loguea, si sus salidas se chequean, ni cuánto tiempo se guardan sus datos.
- Una revisión que llega sin que nadie la pida. Una propiedad que se activa solo cuando algo se rompe es indistinguible de no tener dueño, porque el modo de falla que sigue no rompe nada.
La división no es nueva — es la misma con la que un operador maneja fronteras entre muchas organizaciones, un nivel más abajo.
Los agentes se degradan estando perfectamente quietos
Un servicio que nadie toca sigue haciendo exactamente lo que hacía. Un agente cuya definición nadie toca, no, porque abajo se mueven cuatro cosas:
- El modelo se mueve. El proveedor deprecia la versión que fijaste, o mejora en silencio la que no fijaste, y un prompt afinado contra el comportamiento viejo ahora está afinado contra nada.
- El corpus deriva. El retrieval devuelve siempre la mejor coincidencia del índice, con la misma confianza esté el índice sincronizado esta mañana o el trimestre pasado. La desactualización no tiene estado de error.
- Las herramientas cambian de contrato. Un campo pasa a ser opcional, un enum gana un valor, un endpoint empieza a paginar. El agente se adapta —inventa una lectura plausible de la forma nueva— que es peor que romperse.
- El proceso cambia y el agente no. La política de descuentos cambió en abril. El agente sigue ejecutando la de marzo, con fluidez y con citas.
Solo la tercera suele levantar una alerta. Las otras producen una salida que se ve exactamente como una salida correcta, y por eso se detectan leyendo conversaciones y no monitoreando disponibilidad. El estado peligroso de un agente no es "caído". Es "obsoleto con seguridad" — y el único instrumento que lo detecta es una persona leyendo un puñado de transcripciones con una cadencia fija.
El retiro es un estado, no un delete
El trabajo normativo acá es anterior a la conversación sobre agentes y se levanta tal cual. El AI Risk Management Framework de NIST —NIST AI 100-1, publicado el 26 de enero de 2023 y actualmente en revisión— hace del desmantelamiento un control de primera clase. La subcategoría MANAGE 2.4 dice: "Mechanisms are in place and applied, responsibilities are assigned and understood to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use." La MANAGE 4.1 lista el decommissioning junto a la respuesta a incidentes y la gestión de cambios como componente del monitoreo post-despliegue, no como una tarea de limpieza.
El playbook que la acompaña es más específico, y el verbo importa: "Decommission and preserve system components that cannot be updated to meet criteria for redeployment." Preservar, no borrar — las conversaciones que un agente produjo están referenciadas por auditorías, disputas y la memoria de otros agentes, y borrar la definición que las generó convierte un año de historia en salidas inexplicables.
Así que el ciclo de vida mínimo son cuatro estados y una fecha:
| Estado | Qué significa | Quién lo mueve |
|---|---|---|
| Draft | Existe, no es alcanzable por ningún canal | Cualquiera con permiso de edición |
| Activo | Sirviendo tráfico, con una fecha de revisión encima | El dueño, con un chequeo que pasa |
| Deprecado | Sigue contestando, marcado para reemplazo, sin nuevos vínculos | El dueño |
| Retirado | No contesta nada; definición, versiones y runs preservados | El dueño, y queda registrado |
La fecha es lo que hace el trabajo. Un estado activo sin fecha de revisión no es ningún ciclo de vida — es exactamente la condición que produce el agente de marzo. Ponela en el despliegue, mostrala sobre el agente, y dejá que venza haciendo ruido.
Qué puede decidir una máquina por su cuenta
Tres señales son mecánicas sin riesgo. Fallas consecutivas — un agente agendado que da error N veces seguidas debería pausarse solo y avisarle a su dueño, con el contador reseteándose ante cualquier éxito para que un proveedor intermitente no lo dispare. Inactividad — cero runs en una ventana definida es una señal fuerte y un veredicto débil: marca para revisión, nunca más que eso. Anomalías de costo o volumen contra la propia línea de base del agente, mejor comparador que cualquier umbral común a toda la flota.
Lo que no debe automatizarse es la transición de estado: el retiro, los cambios de alcance y cualquier relajación de un guardrail son decisiones que llevan el nombre de una persona. La asimetría es la regla que conviene copiar — la automatización puede reducir lo que un agente tiene permitido hacer, nunca ampliarlo. Un sistema que pausa un agente por su cuenta es un mecanismo de seguridad. Uno que lo reanuda por su cuenta sacó al humano de la única decisión por la que estaba ahí.
Cuando la medición se vuelve el problema
Esta disciplina tiene un costo, y se puede pasar de largo en dos direcciones.
Medir lo equivocado es peor que no medir, y hay algo equivocado específico que todo el mundo agarra primero. Smaje de nuevo: "I get nervous when I see scorecards with adoption metrics such as 'What's the adoption rate of tool A versus tool B versus tool C, market by market?' That's a highway to nowhere. It doesn't tell you how the technology is being used, let alone how it's creating value." Los conteos de runs y los totales de tokens son la misma métrica disfrazada de operaciones: te dicen que un agente está ocupado, y un agente ocupado contestando la pregunta equivocada cuesta más que uno ocioso.
Todo chequeo humano es una cola. Revisión muestreada de transcripciones, approval gates, fechas de revisión — cada uno es trabajo que cae en un calendario real, y Smaje señala el efecto de segundo orden: las personas que trabajan más intensamente con estos sistemas están "exhausted — not because AI is failing them, but because it's working", con solo el residuo cargado de juicio. Una cadencia que nadie sostiene se vuelve ninguna revisión, que es donde empezaste, ahora con un documento de política encima. Fijá la muestra en lo que el dueño va a leer de verdad.
Y el argumento para no construir nada de esto: si una sola persona construyó y opera tres agentes, esa persona es el ciclo de vida. La maquinaria empieza a pagar cuando la propiedad cruza el límite de una persona — cuando quien responde por un agente no es quien lo escribió. Por debajo de eso, el registro es ceremonia. Por encima, la alternativa es el agente de marzo.
La revisión mensual de la flota
Una hora, una agenda, y cada punto es contestable con registros que ya guardás o deberías empezar a guardar. Ningún punto es más fácil de pasar en una plataforma que en otra — eso es deliberado.
- ¿Cuántos agentes están activos, contra el mes pasado? Un número que solo sube no es una flota, es una acumulación.
- ¿Cuáles corrieron cero veces en 30 días? Cada uno recibe una decisión de su dueño en el momento: retirarlo, o escribir por qué se queda.
- ¿Cuáles no tienen dueño, o tienen un dueño que ya no está? Esos son el abandonware. Asignalos o retiralos antes de que termine la reunión.
- ¿Cuáles pasaron su fecha de revisión? Si es más de un cuarto, la cadencia está mal, no la flota.
- Leé tres conversaciones reales por agente relevante. No resúmenes, no las del pulgar abajo. Muestreadas al azar.
- Qué cambió por debajo de ellos —versiones de modelo, contratos de herramientas, sincronizaciones del corpus— y qué agentes están aguas abajo de cada cambio.
- Costo por resultado completado, por agente. Cociente, no total: un total que sube con un cociente que baja es un éxito.
- ¿Qué se retiró? Una revisión que nunca retira nada no es una revisión. "Nada" dos veces seguidas significa que el punto 2 no se está contestando de frente.
Las tres preguntas de Smaje son más diagnósticas que operativas: una organización que no puede contestarlas no tiene un problema de medición. Estuvo contratando sin evaluación de desempeño, indefinidamente, y llamándolo velocidad.
