Oi a todos, aqui é Chris Wade, novamente no agntlog.com. Estamos em março de 2026 e, honestamente, se você ainda pensa em monitorar seus agentes como fazíamos cinco anos atrás, está deixando dinheiro, saúde mental e talvez até seu trabalho na mesa. O mundo mudou e sua estratégia também deve mudar. Hoje quero falar sobre algo específico, algo que me preocupa (e que me salvou muitas vezes) ultimamente: a observabilidade dos estados dos agentes, não apenas das métricas.
Eu sei, “observabilidade” é uma palavra da moda lançada como um disco voador durante um piquenique tecnológico. Mas me escute. Para nós, no campo do monitoramento de agentes, não é apenas um termo em alta; é uma mudança fundamental na nossa compreensão de nossos sistemas. Não nos limitamos mais a olhar apenas o uso da CPU ou o consumo de memória. Estamos tentando entender o *estado interno* de nossos agentes, seu caminho através de um fluxo de trabalho e os sinais sutis que nos indicam que algo está prestes a dar errado – ou já deu.
Meu caminho para isso começou há cerca de um ano e meio. Tínhamos um novo cliente, um enorme call center com milhares de agentes que usam nossa integração de CRM personalizada. A abordagem antiga de monitoramento falhou de forma espetacular. Tínhamos dashboards que se acendiam de vermelho para “alto uso da CPU” ou “espaço em disco baixo” nos computadores dos agentes, mas o verdadeiro problema, aquele que causava reclamações dos clientes e SLAs perdidos, era mais profundo. Os agentes ficavam presos em um estado de “pós-chamada” indefinidamente ou seu CTI (Integração de Telefonia Computacional) não registrava corretamente as chamadas de saída. As métricas tradicionais nos diziam que as máquinas estavam indo bem, mas os *agentes* (e reflexivamente, a empresa) claramente não estavam.
Foi então que percebi que precisávamos parar de monitorar simplesmente a infraestrutura e começar a observar o comportamento dos agentes e as transições de estado. Não basta saber se o aplicativo de um agente funciona; precisamos saber *o que* esse aplicativo pensa que o agente está fazendo, e se isso corresponde à realidade.
O Problema de Monitorar Apenas Métricas
Pense na sua carro. Se a luz do motor acender, é uma métrica. Isso te diz que *algo* não vai bem. Mas não te diz *o que*. É uma tampa do tanque de gasolina mal colocada? Um sensor de oxigênio defeituoso? Uma falha catastrófica do motor? Você precisa de mais contexto, de maior visibilidade interna, para realmente entender o problema.
O monitoramento tradicional é como aquela luz do motor. Ele te diz *se* um recurso está restrito ou *se* um serviço está offline. Mas para agentes complexos e com estado, especialmente aqueles que interagem com múltiplos sistemas (CRM, telefonia, base de conhecimento, scripts personalizados), uma simples métrica muitas vezes não te dá uma visão completa. Um agente pode estar “conectado” (segundo o monitoramento de presença básico), mas efetivamente preso, incapaz de realizar ações, devido a um bloqueio sutil na máquina de estado de seu aplicativo.
Vimos essa situação de maneira flagrante com nosso cliente do call center. Nosso monitoramento básico mostrava que os agentes estavam conectados ao CRM. A conectividade de rede estava correta. A CPU estava normal. E ainda assim, as chamadas não estavam sendo processadas. Ao investigar mais a fundo, descobrimos que uma sequência específica de ações (transferir uma chamada, então tentar imediatamente acessar o histórico de pagamentos de um cliente) fazia com que o estado interno do CRM para aquele agente permanecesse preso em um ciclo de “aguardando resposta de um serviço externo”, mesmo depois que o serviço externo havia respondido. O aplicativo não travava; estava simplesmente congelado em um estado não reativo do ponto de vista do agente. Nenhuma métrica poderia detectar isso.
Observabilidade para os Estados dos Agentes: O que Isso Significa
Para mim, a observabilidade neste contexto significa capacitar suas aplicações e fluxos de trabalho de agentes para emitir dados detalhados e estruturados sobre suas mudanças de estado internas, eventos e contexto. Trata-se de perguntar:
“`html
- O que o agente está *atualmente* fazendo de acordo com o aplicativo? (por exemplo, “Em chamada”, “Em resumo”, “Disponível”, “Treinamento”, “Em pausa”)
- Qual era o *estado anterior*?
- Quais *eventos* dispararam a mudança de estado? (por exemplo, “Chamada entrante”, “Chamada atendida”, “Botão de pausa clicado manualmente”)
- Qual *contexto* está associado a este estado? (por exemplo, ID da chamada, ID do cliente, motivo da pausa, duração no estado atual)
Não se trata apenas de registrar erros; trata-se de documentar o *caminho* de um agente ao longo do seu dia de trabalho, passo a passo, com um contexto rico.
Exemplo 1: Monitoramento dos Estados do Fluxo de Trabalho dos Agentes
Suponhamos que você tenha um aplicativo de desktop personalizado para agentes. Em vez de simplesmente monitorar se o processo está funcionando, você quer conhecer seu estado interno. Você pode emitir registros estruturados ou rastros sempre que um estado chave mudar.
// No seu aplicativo de desktop para agentes (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(); // Obter do contexto do aplicativo
const sessionId = getCurrentSessionId(); // Obter do contexto do aplicativo
// Registrar a transição de estado com um 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;
}
// Exemplo de uso :
// Quando um agente atende uma chamada :
transitionState(AgentState.OnCall, { type: "CALL_ANSWERED", data: { callId: "12345", customerId: "98765" } });
// Quando um agente passa para resumo :
transitionState(AgentState.WrapUp, { type: "CALL_ENDED", data: { callId: "12345", dispositionTime: 30 } });
// Quando um agente pausa manualmente :
transitionState(AgentState.Paused, { type: "MANUAL_PAUSE", data: { reason: "Pausa", duration: 15 } });
Não é uma ciência dos foguetes, certo? Mas o poder reside na coleta desses eventos de maneira centralizada. Você pode então construir dashboards que mostram os estados dos agentes em tempo real, identificar agentes presos em estados inesperados e até analisar os padrões de transição de estado para identificar gargalos nos fluxos de trabalho.
Integrando a Observabilidade na Sua Ferramenta de Gestão de Agentes
Não se trata apenas de adicionar algumas instruções de impressão. Requer uma abordagem reflexiva na implementação. Aqui está como abordamos a questão:
1. Defina os Estados e Transições Chave dos Agentes
Antes de escrever o código, sente-se com seus gerentes de produto, líderes de equipe e até alguns agentes. Mapeie os estados críticos em que um agente pode estar e as maneiras legítimas de passar de um estado para outro. Isso se torna a sua “verdade básica” sobre como parece um fluxo de trabalho saudável para um agente. Documente tudo explicitamente.
2. Instrumente Tudo que é Pertinente
Nos seus aplicativos para agentes (desktop, web, serviços backend que suportam os agentes), emita registros estruturados ou rastros a cada mudança de estado significativa ou evento. Concentre-se em:
- Alterações de Estado: Quando o estado de um agente muda (por exemplo, “Disponível” para “Em chamada”).
- Ações Chaves: Quando um agente realiza uma ação crítica (por exemplo, “Transferir a chamada”, “Atualizar o dossiê do cliente”, “Enviar o formulário”).
- Interações com Sistemas Externos: Quando o aplicativo do agente interage com um CRM, sistema telefônico ou banco de dados. Registre a solicitação, a resposta e qualquer erro.
3. Utilize Registros Estruturados
JSON é seu amigo aqui. Não se limite a despejar texto cru. Registros estruturados simplificam enormemente a análise, filtragem e compreensão dos seus dados posteriormente. Inclua atributos comuns em cada entrada de registro (timestamp, ID do agente, ID da sessão, versão do aplicativo) e atributos específicos para cada tipo de evento.
4. Centralize e Analise
“`
Enviar todos esses registros para um sistema de registro centralizado (Elasticsearch, Splunk, Loki, DataDog, etc.). Aqui é onde a mágica acontece. Agora você pode:
- Construir Painéis em Tempo Real: Visualize o estado atual de todos os agentes, identifique valores anômalos (por exemplo, agentes presos em “Resumo” por muito tempo).
- Consultar e Filtrar: Encontre rapidamente todos os eventos de um agente, um cliente ou um ID de chamada específico.
- Alertar sobre Anomalias: Configure alertas para transições de estado ou durações inesperadas (por exemplo, “Alerta se um agente estiver em estado ‘Em Pausa’ por mais de 30 minutos sem código de motivo válido”).
- Acompanhar Fluxos de Trabalho: Siga o caminho de um agente através de um processo complexo conectando entradas de log relacionadas.
Exemplo 2: Detectar Agentes Presos com a Análise de Logs
Usando um sistema de logging como Elasticsearch com Kibana, você poderia configurar uma consulta para encontrar agentes presos em um estado indesejado. Imagine procurar agentes que entraram no estado “Resumo” mas que não saíram há mais de 5 minutos.
// Consulta Elasticsearch (Kibana Discover ou Dev Tools)
{
"query": {
"bool": {
"must": [
{ "match": { "newState.keyword": "WrapUp" } },
{ "range": { "timestamp": { "lte": "now-5m" } } }
],
"must_not": [
{ "exists": { "field": "nextState" } } // Supondo que você esteja registrando um evento "nextState" ou "transitionedOut"
]
}
},
"aggs": {
"stuck_agents": {
"terms": {
"field": "agentId.keyword",
"size": 100
}
}
}
}
Essa consulta forneceria uma lista de IDs de agentes que entraram no estado “Resumo” mais de 5 minutos atrás e que não tiveram eventos de mudança de estado registrados posteriormente. É uma maneira muito poderosa de identificar e abordar proativamente os problemas antes que se tornem mais sérios.
Meu Feedback e Passos Acionáveis
Se você gerencia agentes, sejam eles humanos ou bots automatizados, é fundamental ir além de uma simples monitorização do tempo de atividade. Aqui está o que eu recomendo:
- Deixe de apenas monitorar recursos, comece a observar estados: Altere seu foco de “A CPU está alta?” para “O que exatamente a aplicação do agente está fazendo neste momento, e isso está certo?”.
- Mapeie seus fluxos de trabalho de agente: Documente cada estado significativo em que um agente pode estar e as transições válidas. Esse é seu plano para a observabilidade.
- Instrumente suas aplicações de agente: Integre um logging estruturado ou um rastreamento diretamente em suas ferramentas de agente. Cada mudança de estado crítica ou ação deve gerar um evento detalhado. Use JSON.
- Centralize seus dados: Envie esses eventos para um sistema onde você possa consultá-los, visualizá-los e receber alertas.
- Estabeleça alertas proativos: Não espere que os agentes reclamem. Configure alertas para durações de estado inesperadas ou transições inválidas. Por exemplo, se um agente permanecer em “WrapUp” por mais de 180 segundos, avise. Se um agente tentar aceitar uma chamada enquanto estiver em estado “Em Pausa”, avise.
- Eduque suas equipes: Mostre às suas equipes de suporte, operações e produtos como utilizar esses novos painéis e consultas. Quanto mais olhos houver nos dados, mais rapidamente você reconhecerá os problemas.
Não é um projeto de uma única vez. É um processo contínuo de refinamento da sua instrumentação, melhoria dos seus painéis e consulta profunda sobre a experiência dos seus agentes. Mas eu prometo que o investimento vale a pena. Nós passamos de uma luta reativa para uma identificação e resolução proativa de problemas que afetam os agentes em questão de minutos, às vezes até antes que o próprio agente perceba um problema. Isso melhorou a conformidade com os SLAs dos nossos clientes, reduziu a frustração dos agentes e, francamente, tornou meu trabalho muito menos estressante. E isso, em março de 2026, é uma vitória aos meus olhos.
Você tem pensado sobre a observabilidade dos agentes? Deixe-me saber nos comentários abaixo!
Artigos Relacionados
- Desenvolvimento dirigido por logs de agentes AI
- Minha estratégia de debug: Do caos à calma
- Logging de agentes AI em produção
🕒 Published: