Hola a todos, Chris Wade aquí, de nuevo en agntlog.com. Es marzo de 2026 y, honestamente, si todavía estás pensando en monitorear a tus agentes de la manera en que lo hicimos hace cinco años, estás dejando dinero, cordura y tal vez incluso tu trabajo sobre la mesa. El mundo ha avanzado y tu estrategia también debería hacerlo. Hoy quiero hablar sobre algo específico, algo que me ha estado molestando (y salvando las papas) mucho últimamente: Observabilidad para los Estados de los Agentes, No Solo Métricas.
Lo sé, “observabilidad” es una palabra de moda que se lanza como un frisbee en un picnic tecnológico. Pero escúchame. Para nosotros, en el espacio de monitoreo de agentes, no es solo un término elegante; es un cambio fundamental en cómo entendemos nuestros sistemas. Ya no estamos mirando solo el uso de CPU o el consumo de memoria. Estamos tratando de entender el *estado interno* de nuestros agentes, su recorrido a través de un flujo de trabajo y las señales sutiles que nos dicen que algo está a punto de irse de lado — o ya lo ha hecho.
Mi viaje en esto comenzó hace aproximadamente un año y medio. Teníamos un nuevo cliente, una operación de centro de llamadas masivo con miles de agentes usando nuestra integración personalizada de CRM. El antiguo enfoque de monitoreo estaba fallando de manera espectacular. Teníamos paneles iluminados en rojo por “alta CPU” o “bajo espacio en disco” en las estaciones de trabajo de los agentes, pero el verdadero problema, el que estaba causando quejas de los clientes y SLAs incumplidos, era más profundo. Los agentes se quedaban atascados en un estado de “resumen posterior a la llamada” indefinidamente, o su CTI (Integración de Telefonía por Computadora) no estaba registrando correctamente las llamadas salientes. Las métricas tradicionales nos decían que las máquinas estaban bien, pero los *agentes* (y por extensión, el negocio) claramente no lo estaban.
Fue entonces cuando me di cuenta de que necesitábamos dejar de solo monitorear la infraestructura y comenzar a observar el comportamiento de los agentes y las transiciones de estado. No es suficiente saber si la aplicación de un agente está funcionando; necesitamos saber *qué* cree esa aplicación que el agente está haciendo, y si eso se alinea con la realidad.
El Problema de Solo Monitorear Métricas
Piense en tu auto. Si se enciende la luz del motor, eso es una métrica. Te dice que *algo* está mal. Pero no te dice *qué*. ¿Es una tapa de gas suelta? ¿Un sensor de oxígeno defectuoso? ¿Un fallo catastrófico del motor? Necesitas más contexto, más visibilidad interna, para comprender verdaderamente el problema.
El monitoreo tradicional es como esa luz del motor. Te dice *si* un recurso está restringido o *si* un servicio está caído. Pero para agentes complejos y con estado, especialmente aquellos que interactúan con múltiples sistemas (CRM, telefonía, base de conocimientos, scripts personalizados), una simple métrica a menudo no te da el panorama completo. Un agente podría estar “conectado” (según tu monitoreo básico de presencia) pero efectivamente congelado, incapaz de realizar cualquier acción, debido a un sutil bloqueo en la máquina de estado de su aplicación.
Vimos esto vívidamente con nuestro cliente de centro de llamadas. Nuestro monitoreo básico mostró que los agentes estaban conectados al CRM. Su conectividad de red estaba bien. La CPU era normal. Aun así, las llamadas no se estaban procesando. Al investigar más a fondo, encontramos que una secuencia específica de acciones (transferir una llamada, luego intentar inmediatamente acceder al historial de pagos de un cliente) estaba causando que el estado interno del CRM para ese agente quedara atascado en un bucle de “esperando la respuesta del servicio externo”, incluso después de que el servicio externo había respondido. La aplicación no estaba fallando; solo estaba congelada en un estado no responsivo desde la perspectiva del agente. Ninguna métrica habría captado eso.
Observabilidad para los Estados de los Agentes: Lo Que Significa
Para mí, la observabilidad en este contexto significa instrumentar tus aplicaciones y flujos de trabajo de los agentes para emitir datos estructurados y detallados sobre sus cambios de estado interno, eventos y contexto. Se trata de preguntar:
- ¿Qué está *haciendo actualmente* el agente según la aplicación? (por ejemplo, “En llamada”, “Resumen”, “Disponible”, “Entrenamiento”, “En pausa”)
- ¿Cuál fue el *estado anterior*?
- ¿Qué *eventos* desencadenaron el cambio de estado? (por ejemplo, “Llamada entrante”, “Llamada respondida”, “Se hizo clic en el botón de pausa manual”)
- ¿Qué *contexto* está asociado con este estado? (por ejemplo, ID de llamada, ID de cliente, razón para la pausa, duración en el estado actual)
Esto no es solo registrar errores; se trata de registrar el *viaje* de un agente a través de su jornada laboral, paso a paso, con un rico contexto.
Ejemplo 1: Seguimiento de los Estados del Flujo de Trabajo del Agente
Supongamos que tienes una aplicación de escritorio de agente personalizada. En lugar de solo monitorear si el proceso está en ejecución, quieres conocer su estado interno. Puedes emitir registros estructurados o trazas cada vez que un estado clave cambia.
// Dentro de tu aplicación de escritorio de agente (pseudo-código)
enum AgentState {
LoggedIn,
Available,
OnCall,
WrapUp,
Paused,
Offline
}
currentAgentState = AgentState.Offline;
function transitionState(newState, eventDetails = {}) {
const timestamp = new Date().toISOString();
const agentId = getAgentId(); // Obtener del contexto de la aplicación
const sessionId = getCurrentSessionId(); // Obtener del contexto de la aplicación
// Registrar la transición de estado con un contexto rico
console.log(JSON.stringify({
timestamp: timestamp,
agentId: agentId,
sessionId: sessionId,
oldState: currentAgentState.toString(),
newState: newState.toString(),
eventType: eventDetails.type || "STATE_CHANGE",
eventData: eventDetails.data || {}
}));
currentAgentState = newState;
}
// Ejemplo de uso:
// Cuando un agente responde a una llamada:
transitionState(AgentState.OnCall, { type: "CALL_ANSWERED", data: { callId: "12345", customerId: "98765" } });
// Cuando un agente pasa a resumen:
transitionState(AgentState.WrapUp, { type: "CALL_ENDED", data: { callId: "12345", dispositionTime: 30 } });
// Cuando un agente pausa manualmente:
transitionState(AgentState.Paused, { type: "MANUAL_PAUSE", data: { reason: "Descanso", duration: 15 } });
Esto no es ciencia de cohetes, ¿verdad? Pero el poder radica en la recopilación central de estos eventos. Luego puedes construir paneles que muestren los estados reales de los agentes, identificar a los agentes atascados en estados inesperados e incluso analizar los patrones de transición de estados para detectar cuellos de botella en el flujo de trabajo.
Incorporando Observabilidad en Tus Herramientas para Agentes
Esto no se trata solo de agregar algunas declaraciones de impresión. Requiere un enfoque reflexivo hacia la instrumentación. Así es como lo abordamos:
1. Define Estados Clave y Transiciones de los Agentes
Antes de escribir cualquier código, siéntate con tus gerentes de producto, líderes de equipo e incluso algunos agentes. Mapea los estados críticos en los que un agente puede estar y las formas legítimas en que transitan entre ellos. Esto se convertirá en tu “verdad fundamental” sobre cómo se ve un flujo de trabajo de agentes saludable. Documenta esto de manera explícita.
2. Instrumenta Todo lo Relevante
En tus aplicaciones de agente (escritorio, web, servicios backend que apoyan a los agentes), emite registros estructurados o trazas en cada cambio significativo de estado o evento. Concéntrate en:
- Cambios de Estado: Cuando cambia el estado de un agente (por ejemplo, “Disponible” a “En llamada”).
- Acciones Clave: Cuando un agente realiza una acción crítica (por ejemplo, “Llamada transferida”, “Registro de cliente actualizado”, “Formulario enviado”).
- Interacciones con Sistemas Externos: Cuando la aplicación del agente interactúa con un CRM, sistema de telefonía o base de datos. Registra la solicitud, respuesta y cualquier error.
3. Usa Registro Estructurado
JSON es tu amigo aquí. No solo vuelques texto plano. Los registros estructurados facilitan infinitamente el análisis, filtrado y análisis de tus datos más adelante. Incluye atributos comunes en cada entrada de registro (marca de tiempo, ID de agente, ID de sesión, versión de la aplicación) y atributos específicos para cada tipo de evento.
4. Centraliza y Analiza
Envía todos estos registros a un sistema de logging central (Elasticsearch, Splunk, Loki, DataDog, etc.). Aquí es donde ocurre la magia. Ahora puedes:
- Construir Paneles en Tiempo Real: Visualizar el estado actual de todos los agentes, identificar outliers (por ejemplo, agentes atascados en “Resumen” demasiado tiempo).
- Consultar y Filtrar: Encontrar rápidamente todos los eventos para un agente, cliente o ID de llamada específicos.
- Alertar sobre Anomalías: Configura alertas para transiciones de estado o duraciones inesperadas (por ejemplo, “Alertar si un agente está en estado ‘Pausado’ durante más de 30 minutos sin un código de razón válido”).
- Rastrear Flujos de Trabajo: Seguir el viaje de un agente a través de un proceso complejo vinculando entradas de registro relacionadas.
Ejemplo 2: Detectando Agentes Atascados con Análisis de Registros
Usando un sistema de logging como Elasticsearch con Kibana, podrías configurar una consulta para encontrar agentes atascados en un estado indeseable. Imagina que estás buscando agentes que ingresaron al estado “Resumen” pero no han salido de él durante más de 5 minutos.
// Consulta de Elasticsearch (Kibana Discover o Dev Tools)
{
"query": {
"bool": {
"must": [
{ "match": { "newState.keyword": "WrapUp" } },
{ "range": { "timestamp": { "lte": "now-5m" } } }
],
"must_not": [
{ "exists": { "field": "nextState" } } // Suponiendo que registrarías un evento "nextState" o "transitionedOut"
]
}
},
"aggs": {
"stuck_agents": {
"terms": {
"field": "agentId.keyword",
"size": 100
}
}
}
}
Esta consulta te daría una lista de ID de agentes que ingresaron al estado “Resumen” hace más de 5 minutos y no han tenido un evento de cambio de estado subsiguiente registrado. Esta es una forma muy poderosa de identificar y abordar problemas proactivamente antes de que se agraven.
Mis Conclusiones y Pasos Accionables
Si estás gestionando agentes, ya sean humanos o bots automatizados, definitivamente necesitas ir más allá de la supervisión básica de disponibilidad. Aquí tienes lo que recomiendo:
- Deja de Monitorear Solo Recursos, Comienza a Observar Estados: Cambia tu enfoque de “¿Está alto el CPU?” a “¿Qué está *haciendo* la aplicación del agente ahora mismo, y es correcto?”
- Mapea los Flujos de Trabajo de Tu Agente: Documenta cada estado significativo en el que puede estar un agente y las transiciones válidas. Este es tu esquema para la observabilidad.
- Instrumenta Tus Aplicaciones de Agente: Construye registros estructurados o trazas directamente en tus herramientas de agente. Cada cambio de estado o acción crítica debería generar un evento detallado. Usa JSON.
- Centraliza Tus Datos: Lleva esos eventos a un sistema donde puedas consultarlos, visualizarlos y alertar sobre ellos.
- Crea Alertas Proactivas: No esperes a que los agentes se quejen. Configura alertas para duraciones de estado inesperadas o transiciones inválidas. Por ejemplo, si un agente permanece en “WrapUp” más de 180 segundos en promedio, alerta. Si un agente intenta aceptar una llamada mientras está en estado “Paused”, alerta.
- Educa a Tus Equipos: Muestra a tus equipos de soporte, operaciones y producto cómo usar estos nuevos paneles de control y consultas. Cuantos más ojos en los datos, más rápido detectarás problemas.
Este no es un proyecto de una sola vez. Es un proceso continuo de refinamiento de tu instrumentación, mejora de tus paneles de control y formulación de preguntas más profundas sobre la experiencia de tu agente. Pero te prometo que la inversión vale la pena. Pasamos de apagar incendios de manera reactiva a identificar y resolver proactivamente los problemas que afectan a los agentes en cuestión de minutos, a veces incluso antes de que el propio agente notara un problema. Mejoró la adherencia al SLA de nuestro cliente, redujo la frustración de los agentes y, francamente, hizo que mi trabajo fuera mucho menos estresante. Y eso, en marzo de 2026, es una victoria en mi libro.
¿Tienes pensamientos sobre la observabilidad de agentes? ¡Háblame en los comentarios a continuación!
Artículos Relacionados
- Desarrollo impulsado por registros de agentes de IA
- Mi Estrategia de Depuración: Del Caos a la Calma
- Registro de agentes de IA en producción
🕒 Published: