El agente RMM de ConnectWise diagnostica el ticket y espera a una persona: la espera es el diseño

A las dos de la mañana llega un ticket: el portátil de un usuario no puede acceder al recurso compartido de archivos. Un técnico que lo retome a las ocho pasará los primeros veinte minutos haciendo lo que hace todo técnico. Revisar el dispositivo, revisar la red, revisar los logs, probar lo obvio y solo entonces empezar a pensar.

El lanzamiento de ConnectWise el 29 de octubre automatiza esos primeros veinte minutos y se detiene ahí a propósito. Su nuevo Agentic RMM coloca un agente dentro de la plataforma de monitorización y gestión remota que usan los proveedores de servicios gestionados (MSP) para operar los endpoints de sus clientes. Cuando llega un ticket, el RMM Agent investiga el dispositivo que hay detrás, prueba la causa probable y prepara una corrección de un catálogo validado. Los diagnósticos son de solo lectura. Cualquier cambio en el dispositivo requiere la aprobación explícita de un técnico, dada dentro del ticket.

ConnectWise también puso en disponibilidad general tres agentes de recepción, para voz, Microsoft Teams y correo electrónico, que recogen los datos que faltan del usuario final antes de que un ticket llegue a una persona. Los cuatro agentes se describen como en disponibilidad general en el lanzamiento.

Empezar por solo lectura no es timidez

Habría sido fácil vender esto como remediación autónoma. ConnectWise eligió una forma más acotada: el agente puede mirar cualquier cosa, probar hipótesis sin cambiar el estado y proponer un cambio, pero solo a partir de un catálogo de scripts que el proveedor ya ha validado. Eso encaja bien con la escalera que propusimos para ganar autonomía del agente: leer, luego recomendar, luego actuar con aprobación. El RMM Agent se sitúa a propósito en el tercer peldaño.

Para un MSP, la razón es tanto comercial como técnica. Un proveedor gestiona endpoints de muchos clientes bajo contrato. Un cambio erróneo hecho automáticamente en la máquina de un cliente es una ruptura de la confianza con ese cliente, no solo un incidente. Mantener al técnico como quien pulsa el botón mantiene la responsabilidad donde la sitúa el contrato.

El catálogo validado importa tanto como la aprobación. Convierte ‘qué puede hacer el agente’ en una lista que alguien mantiene. Si una corrección no está en el catálogo, el agente no puede proponerla, lo que acota el daño de un diagnóstico equivocado hecho con seguridad.

Lo que reportan los socios

Las cifras del comunicado proceden de socios de ConnectWise y son anécdotas, no mediciones controladas. RealBytes dice que sus agentes evaluaron el 99 por ciento de 7,074 tickets en 30 días y devolvieron 178 horas al equipo, y que más de 500 tickets activos pasaron por el RMM Agent, con un diagnóstico útil en el 91 por ciento de ellos, cada uno en alrededor de un minuto. Fusion Computing reporta un 86 por ciento menos de escalaciones. RealBytes sitúa el punto de equilibrio de su gasto en IA en unos 16 minutos ahorrados por técnico y día.

‘Diagnóstico útil’ es la frase que hay que examinar. No es lo mismo que uno correcto. Un equipo que adopte esto debería definir, antes del piloto, qué cuenta: que el diagnóstico nombrara la causa raíz, que la corrección preparada fuera la que aplicó el técnico o que el técnico simplemente la encontrara útil. Cada criterio da una cifra distinta. Los agentes de operaciones que revisamos de AWS y Azure plantean el mismo punto: una explicación segura de sí misma no es evidencia hasta que alguien la contrasta con lo que resolvió el problema.

Qué preguntar antes de activarlo

¿Quién mantiene el catálogo y cómo se versiona? Los scripts se desvían. Una corrección que era segura para una compilación del sistema operativo puede no serlo para la siguiente.

¿Qué lee el agente? Los diagnósticos de solo lectura pueden tocar datos sensibles en el dispositivo de un cliente: nombres de archivos, logs de eventos y actividad del usuario. Puede que los clientes necesiten saberlo.

¿Cómo se registra la aprobación? La aprobación dentro del ticket debería mostrar lo que vio el técnico: el diagnóstico, el script propuesto y el dispositivo. De lo contrario, ‘aprobado’ se convierte en un reflejo.

¿Qué pasa con las horas? Si los primeros veinte minutos desaparecen, el proveedor tiene que decidir para qué sirve esa capacidad: más clientes por técnico, niveles de respuesta más rápidos o trabajo más profundo. Sin esa decisión, el ahorro se queda en una diapositiva.

El lanzamiento es un ejemplo útil de TI agéntica hecha con mesura. El agente hace la investigación que a la gente le resulta tediosa; la decisión sigue en la persona que responde por ella.