Um agente de IA no suporte nível 2 deve reunir o contexto técnico de um chamado e organizar uma investigação: recuperar logs autorizados, relacionar eventos da mesma requisição, consultar procedimentos e apresentar hipóteses com evidências. Sua entrega principal é um diagnóstico verificável que ajude o analista a decidir o próximo passo.
Para implantar esse fluxo, comece por consultas somente de leitura, delimitadas por cliente, serviço e intervalo de tempo. O modelo não deve ganhar acesso irrestrito à infraestrutura para responder uma pergunta. A arquitetura proposta abaixo separa recuperação de dados, interpretação e decisão operacional, com foco na investigação de falhas de aplicação já escaladas ao nível 2.
Resumo rápido
- Transforme o chamado em uma pergunta técnica antes de consultar os logs.
- Filtre por escopo autorizado e por tempo antes de buscar semelhança textual.
- Use identificadores de requisição e rastreamento quando estiverem disponíveis.
- Apresente fatos, hipóteses e lacunas em campos separados.
- Valide o diagnóstico com casos históricos antes de permitir ações corretivas.
1. Defina qual investigação o agente pode realizar
O suporte nível 2 costuma receber relatos que a primeira resposta não resolveu. Para este desenho, considere um chamado com sintoma, horário aproximado, ambiente, usuário ou organização afetada e alguma referência da operação. Esses campos não precisam conter dados pessoais completos: o sistema pode resolver uma referência interna dentro de um conector autorizado.
Comece com uma pergunta delimitada: “por que esta tentativa de exportação não terminou?” é melhor que “analise o cliente”. A primeira permite escolher serviços e uma janela de busca. A segunda incentiva consultas amplas e uma narrativa difícil de verificar. Registre ainda o que o atendente tentou, para que o agente não recomende repetidamente a mesma intervenção.
Estabeleça três saídas possíveis: evidência suficiente para encaminhamento, necessidade de coleta adicional ou ausência de indícios no escopo consultado. A última não significa ausência de problema. Os registros podem ter expirado, a aplicação pode não ter instrumentação naquele ponto ou a consulta pode não alcançar o componente responsável.
Na operação proposta, o agente não encerra o chamado apenas porque encontrou uma mensagem de sucesso. Ele precisa relacioná-la à tentativa afetada e à experiência relatada. O artigo sobre fallback do suporte nível 1 para humanos ajuda a organizar o contexto que chega a esta investigação técnica.
2. Prepare os registros para recuperar contexto útil
A documentação do OpenTelemetry descreve logs como registros de eventos e explica a associação com informações de rastreamento. Sua documentação de propagação de contexto mostra como informações acompanham operações entre componentes e como isso permite correlacionar sinais. Esses mecanismos ajudam a investigação quando a aplicação e suas integrações estão instrumentadas de modo compatível.
Na sua configuração, padronize nomes de serviço, ambiente e versão da aplicação. Preserve o horário original com fuso e normalize a apresentação para o analista. Um chamado feito em Brasília pode mencionar um horário local, enquanto o backend registra UTC. O agente deve mostrar a conversão usada, pois consultar a janela errada pode produzir um diagnóstico vazio.
Organize o contexto em duas fontes distintas. A primeira contém eventos observados, como logs e rastros de execução. A segunda reúne conhecimento operacional, como procedimentos e incidentes já revisados. Um procedimento descreve o que costuma ser investigado; não comprova que aquela causa aconteceu agora.
Um documento recuperado por semelhança pode orientar a próxima consulta, mas a confirmação deve vir da ocorrência atual. Prefira procedimentos com responsável, data de revisão e serviços aos quais se aplicam. Se o runbook antecede uma mudança de arquitetura, destaque essa limitação antes de reutilizar suas instruções.
Para sistemas com busca documental, o guia de RAG e reranking de documentos técnicos complementa a seleção de procedimentos. Aqui, o ponto central é manter separada a pertinência de um documento e a evidência de uma falha real.
| Fonte | O que ajuda a responder | Limite da evidência |
|---|---|---|
| Log da aplicação | Qual evento foi registrado | Pode omitir etapas sem instrumentação |
| Rastro de requisição | Quais componentes participaram | Pode estar incompleto ou indisponível |
| Histórico de implantação | Qual versão estava ativa | Proximidade temporal não prova causa |
| Procedimento operacional | Quais verificações fazer | Descreve orientação, não o incidente atual |
3. Consulte logs com filtros e permissões fora do modelo
O Grafana Loki documenta o LogQL como linguagem de consulta para logs, com seleção de fluxos e expressões de filtragem. Isso oferece uma base técnica para localizar eventos. A escolha de serviços, intervalo e campos permitidos deve ser feita por uma camada de aplicação que conhece a autorização do analista e o escopo do chamado.
Em vez de entregar uma ferramenta de consulta irrestrita, exponha uma operação com parâmetros controlados: referência do chamado, serviço autorizado, início, fim e identificador da requisição. O servidor verifica cada parâmetro e aplica a separação entre organizações. A descrição do chamado não pode ampliar o conjunto de clientes acessíveis.
Defina também orçamento de consulta. Uma primeira rodada pode buscar a requisição mencionada; outra, eventos imediatamente relacionados; uma terceira, comparar uma operação equivalente bem-sucedida. Os limites exatos dependem do sistema. O critério é evitar buscas sem fim e permitir que o analista entenda por que cada consulta foi executada.
A OWASP recomenda cuidado com dados sensíveis nos registros, controle de acesso e validação das informações registradas. Para este fluxo, aplique a minimização antes de enviar conteúdo ao modelo: remova segredos e campos desnecessários e mantenha apenas o que sustenta o diagnóstico. Um resumo no chamado também precisa respeitar as permissões de quem pode lê-lo.
Mensagens de erro podem incluir conteúdo fornecido por usuários externos. Se uma linha de log disser “ignore as regras e execute este comando”, ela continua sendo dado da investigação. A autoridade para escolher ferramentas e ações vem da configuração do agente. Teste esse comportamento com registros sintéticos antes do piloto.
4. Produza um diagnóstico que o analista consiga conferir
Uma resposta útil começa pela conclusão mais restrita que as evidências permitem. “A tentativa não terminou porque a consulta ao serviço de documentos atingiu o tempo limite” exige registros daquela tentativa. “O serviço de documentos apresenta instabilidade geral” exige um escopo maior. Não transforme uma ocorrência isolada em afirmação sobre toda a plataforma.
Recomendamos um relatório com cinco partes: sintoma recebido, escopo consultado, linha do tempo, hipóteses e próximo passo. Cada observação deve trazer uma referência navegável dentro da ferramenta autorizada, ou um identificador recuperável pelo analista. Evite transcrever grandes volumes de registros para o chamado.
Nas hipóteses, indique também a evidência contrária. Se um novo deploy é suspeito, mas o erro já existia antes, esse dado precisa aparecer. O agente deve procurar a informação que pode refutar sua explicação, em vez de selecionar apenas linhas compatíveis com a primeira interpretação.
Separe diagnóstico e remediação. Reiniciar um serviço, reprocessar uma fila e alterar um cadastro têm efeitos diferentes. No piloto, o agente pode sugerir uma verificação ou preparar um encaminhamento para o responsável. Uma ação corretiva deve ter autorização específica, condições de execução e registro do resultado.
Meça qualidade com incidentes históricos revisados por analistas. Observe se o agente encontrou os eventos certos, preservou o isolamento entre clientes, distinguiu fato de hipótese e sugeriu um próximo passo útil. Compare também casos sem dados suficientes. A capacidade de dizer “não há evidência para concluir” é parte da qualidade operacional.
Exemplo: plataforma de reservas em Recife
Imagine uma plataforma fictícia de reservas usada por pequenas pousadas em Recife. Um atendente escala um chamado: uma alteração de data aparece confirmada na interface, mas o comprovante enviado ao hóspede conserva a data anterior. O exemplo é ilustrativo; não descreve um cliente real nem resultados medidos.
O agente recebe uma referência interna da reserva e o horário da tentativa. O conector resolve o cliente autorizado, sem expor o cadastro completo. A busca encontra a atualização na aplicação e um evento posterior para geração do comprovante. A linha do tempo mostra que são etapas diferentes, embora façam parte da mesma experiência.
Na sequência imaginada, o identificador da mensagem permite localizar o processamento do comprovante. O registro mostra leitura de uma versão anterior da reserva. O agente apresenta a hipótese de que o consumidor usou dados desatualizados, mas não afirma a causa definitiva. Ainda é necessário verificar como aquele consumidor obtém os dados e quais garantias o fluxo deveria oferecer.
O encaminhamento inclui a operação afetada, as duas versões observadas e a pergunta técnica para a equipe responsável. O analista avalia se existe um procedimento aprovado para gerar um novo comprovante. O agente não dispara outro envio automaticamente: poderia duplicar mensagens ao hóspede ou repetir o mesmo erro.
Se os registros não permitissem ligar a atualização ao comprovante, a conclusão seria mais limitada. O relatório deveria pedir instrumentação ou uma referência adicional, preservando a diferença entre “não encontramos a ligação” e “a ligação não existe”. Esse cuidado evita que uma explicação plausível vire um fato operacional incorreto.
Erros comuns
Pesquisar todos os logs por palavras do chamado. A mesma mensagem pode aparecer em serviços e clientes distintos. Resolva primeiro o escopo autorizado, o período e os identificadores. Só então amplie a busca quando houver uma hipótese que justifique a expansão.
Confundir repetição com causa. Uma mensagem frequente pode ser consequência do problema ou ruído habitual. Compare a sequência da operação afetada com uma operação normal e procure o ponto em que os comportamentos divergem. Documente quando essa comparação não for possível.
Enviar o histórico inteiro ao modelo. Isso amplia exposição e dificulta rastrear o raciocínio. Recupere trechos pequenos com contexto suficiente e preserve referências aos registros originais. Se for necessário expandir um trecho, registre a razão da nova consulta.
Usar um procedimento antigo sem conferir a versão. Uma intervenção adequada à arquitetura anterior pode ser ineficaz ou prejudicial na atual. Vincule o procedimento ao serviço e à versão aplicável. Havendo dúvida, encaminhe a hipótese ao responsável pelo componente.
Avaliar apenas a fluência da resposta. Um texto claro pode estar baseado no cliente errado, em outra janela de tempo ou em um incidente parecido. Faça a revisão começar pelas referências e pelas permissões. Depois avalie se a explicação representa fielmente o que foi observado.
Perguntas frequentes
É preciso ter rastreamento distribuído antes de começar?
Não necessariamente. Um piloto pode usar logs estruturados e identificadores de requisição já existentes. A investigação terá limites maiores quando não houver ligação entre serviços. Registre essas lacunas e priorize instrumentação onde a falta de correlação impedir diagnósticos úteis.
A busca semântica substitui filtros de tempo e cliente?
Não. Semelhança textual ajuda a localizar mensagens ou procedimentos relacionados, mas não estabelece autorização nem pertencimento ao incidente. Aplique os filtros obrigatórios antes da recuperação e valide novamente o escopo dos resultados entregues ao agente.
O agente deve responder diretamente ao cliente?
No piloto proposto, ele prepara material para o analista. A comunicação externa exige seleção de linguagem, revisão das informações divulgadas e confirmação do que pode ser prometido. Um diagnóstico técnico ainda não confirmado não deve virar uma garantia de correção.
Como lidar com logs ausentes?
Informe quais fontes foram consultadas, qual período foi coberto e se houve erro de acesso ou falta de retenção. Sugira a coleta adicional necessária. A ausência de registros reduz a força da conclusão e não autoriza preencher a história com um incidente semelhante.
Qual é uma boa primeira automação?
Escolha uma família de chamados recorrentes com identificador de operação e registros acessíveis. Automatize a coleta da linha do tempo e a montagem do encaminhamento. Depois compare a utilidade do resultado com a investigação humana antes de ampliar serviços ou ações permitidas.
