Reiniciar serviços de forma automatizada ou utilizar scripts de auto-healing para limpar espaço em disco aos 90% não são novidade para um SRE. Temos utilizado esse tipo de automação básica e determinística há muito tempo.

O real desafio, e o objetivo final de qualquer time de plataforma, é a resolução de incidentes complexos: aqueles problemas multidimensionais que exigem navegar por dezenas de dashboards para entender que uma mudança no esquema do banco de dados está causando gargalos de conexão em um microsserviço.

Com a ascensão dos agentes de IA, essa visão de remediação inteligente deixou de ser especulativa. No entanto, entre a promessa da tecnologia e a realidade dos sistemas de produção, existe uma lacuna fundamental: o contexto.

Mais precisamente, a capacidade de agir dentro de limites seguros mesmo quando você não tem a visão completa do cenário.

A Nova Onda: Triagem Inteligente

Estamos vendo uma tendência clara com ferramentas como o Azure SRE Agent e o AWS DevOps Agent. Esses agentes não servem apenas para executar comandos; eles atuam como uma camada de inteligência sobre o caos.

Seu impacto mais imediato e mensurável está na triagem assistida.

Ao correlacionar logs, métricas e traces em sistemas distribuídos, esses agentes conseguem identificar rapidamente a causa provável de um incidente. Em vez de alertas brutos, os SREs recebem insights sintetizados:

A latência aumentou após o deploy X; as taxas de erro estão concentradas no serviço Y.

Isso reduz significativamente o MTTD (Mean Time To Detect) e diminui a carga cognitiva durante a resposta a incidentes. Mas passar da triagem para a remediação não é um passo linear. É uma mudança na classe do problema.

Riscos da Janela de Contexto e Improviso

Como discuti anteriormente em meu artigo Gerenciamento da Janela de Contexto para Agentes de IA, um agente de IA é tão bom quanto a informação que ele consegue processar sem se perder. Para um SRE, isso é um desafio crítico: o volume de logs, métricas e metadados gerados durante um incidente pode facilmente saturar a janela de contexto de um modelo.

Quando o tratamento de contexto degrada, os agentes podem:

• Ignorar sinais críticos
• Dar peso errado a correlações
• Gerar inferências tecnicamente plausíveis, mas incorretas

Isso introduz o risco de alucinação durante a remediação.

Imagine um agente que decide escalar um serviço stateful para conter uma alta latência, sem perceber — devido à saturação de contexto — que o problema real é uma contenção de locks no banco de dados. Essa ação de auto-healing poderia simplesmente amplificar o problema, gerando um thundering herd que derruba o que restava da infraestrutura.

Guardrails

Para mitigar esses riscos, introduzimos guardrails, que são restrições sobre quais ações um agente está autorizado a realizar. Eles definem a superfície de controle do sistema.

Mas enfrentamos um paradoxo técnico:

1. Se os guardrails forem muito rígidos, a IA não consegue resolver nada fora de um script básico.
2. Se damos liberdade para deduzir soluções em sistemas complexos com um contexto mal gerido, o risco de um resultado inesperado cresce exponencialmente.

A Segurança dos Runbooks Consolidados

A prática mais madura no mercado hoje é usar esses agentes como orquestradores de runbooks validados.

IA para a decisão. Sistemas determinísticos para a execução.

Se o agente executa uma ação automaticamente, precisamos ter certeza de que ela pode ser desfeita e que não causará efeitos colaterais se for repetida. A inteligência pertence à análise, mas a execução permanece em trilhos seguros.

A Lição da Aviação: Automation Surprise

Gosto de usar a analogia da aviação moderna.

Uma aeronave comercial hoje consegue lidar com quase todas as fases de um voo sozinha. No entanto, pilotos humanos continuam essenciais. Não para a operação rotineira, mas para casos extremos (edge cases).

Na engenharia de fatores humanos, existe um conceito chamado automation surprise (surpresa da automação). Isso acontece quando o sistema automático toma uma decisão que o operador não esperava. Se o seu agente de auto-healing decide isolar uma região inteira do provedor cloud sem uma explicação clara, o engenheiro de plantão é forçado a mudar o foco da recuperação para a interpretação.

Conclusão

O auto-healing totalmente autônomo não é apenas um desafio de engenharia de software; é uma questão de gerenciamento de risco.

Ferramentas como o Azure SRE Agent ou o AWS DevOps Agent são multiplicadores de força incríveis para diagnóstico e automação de tarefas repetitivas. No entanto, quando se trata dos controles de um sistema crítico, o julgamento humano ainda é a última linha de defesa.

Por enquanto, o modelo mais eficaz é claro: a IA opera como um copiloto. Humanos retêm a autoridade sobre decisões de alto impacto.

Não porque a IA não seja capaz, mas porque sistemas de produção oferecem margem zero para erro.

Continuar lendo

Interagir com uma inteligência artificial costuma ser visto como um problema de velocidade. Fazemos uma pergunta e esperamos uma resposta rápida, como se o tempo de resposta fosse um indicador direto de qualidade.

Isso funciona em muitos casos, mas começa a falhar quando o problema exige mais do que uma resposta plausível.

Modelos de linguagem não “pensam” antes de responder. Eles operam em um processo chamado inferência (que é simplesmente o momento em que, dado um texto de entrada, o modelo começa a gerar a resposta). Essa geração acontece token por token (pequenos pedaços de texto, geralmente palavras ou partes delas), prevendo qual é a próxima palavra mais provável com base no contexto.

Em problemas simples, esse mecanismo funciona bem. Entretanto, em situações mais complexas, ele tende a seguir o caminho mais curto, o que nem sempre leva à melhor resposta.

Nos últimos anos, ficou claro que a qualidade dessas respostas pode melhorar quando o modelo percorre um caminho mais longo antes de concluir. Isso pode acontecer de duas formas.

A primeira é externa (a forma como escrevemos o prompt). Pequenas mudanças, como pedir para estruturar o raciocínio ou considerar etapas intermediárias, podem levar o modelo a explorar mais possibilidades antes de responder.

A segunda é interna, relacionada ao próprio treinamento do modelo. Modelos mais recentes já são ajustados para gerar, de forma implícita, etapas intermediárias de raciocínio antes de produzir a resposta final (o que ficou conhecido como modelos de raciocínio). Esse processo quase sempre é invisível, mas influencia diretamente o resultado.

Nos dois casos, o efeito é semelhante: o modelo deixa de encerrar o raciocínio cedo demais.

No fundo, a natureza do sistema permanece a mesma, um jogo de probabilidades e padrões aprendidos. O que muda é o quanto exploramos esse processo antes de aceitar uma resposta.

Existe um paralelo direto com o raciocínio humano. O psicólogo Daniel Kahneman sugere em Rápido e Devagar (Objetiva, 2012) que nosso pensamento opera a partir de dois modos distintos, o que ele chama de Sistema 1 e Sistema 2.

Quando respondemos algo imediatamente, recorremos a padrões já conhecidos ou atalhos mentais. Como ele descreve: “o Sistema 1 opera automaticamente, com pouco ou nenhum esforço”, enquanto “o Sistema 2 aloca atenção às atividades mentais que exigem esforço”. Quando paramos para estruturar o problema e percorrer etapas intermediárias, a chance de erro diminui (um processo mais próximo do Sistema 2). Não porque nos tornamos mais inteligentes naquele momento, mas porque usamos mais esforço antes de concluir.

Nos modelos de linguagem, esse esforço aparece como mais tokens. Em humanos, aparece como tempo, atenção e organização do pensamento.

Em ambos os casos, o mecanismo é parecido. Não é sobre saber mais, mas sobre não parar cedo demais.

Isso também ajuda a explicar por que respostas diferentes podem surgir do mesmo modelo para o mesmo problema. A forma da pergunta (ou o próprio comportamento interno do modelo) altera o caminho percorrido. Caminhos diferentes levam a conclusões diferentes.

Interagir melhor com esses sistemas não é apenas sobre perguntar melhor, mas sobre entender quando vale a pena desacelerar. Tanto em modelos de linguagem quanto em pessoas, respostas melhores raramente são as mais rápidas, são as que tiveram tempo e espaço suficiente para acontecer.

Continuar lendo

Em algum momento da infância quase todo mundo escuta a mesma pergunta: o que você vai ser quando crescer? A resposta quase sempre vem no singular. Médico. Engenheiro. Advogado. Como se fosse preciso escolher uma única especialidade cedo demais e carregá-la pelo resto da vida.

Durante muito tempo, essa lógica fez bastante sentido. O mundo recompensava profundidade. Quanto mais alguém se aprofundava em um único campo, mais valioso se tornava. Décadas de estudo, anos de experiência, várias especializações. Era assim que se construía autoridade.

A inteligência artificial não acabou com essa lógica, mas certamente bagunçou parte dela.

Hoje qualquer pessoa pode fazer uma pergunta extremamente específica sobre praticamente qualquer assunto e obter uma resposta em segundos. Aquilo que antes exigia horas de pesquisa, consulta a livros ou especialistas, agora cabe em uma caixa de texto. Competir com a máquina nesse terreno começa a parecer algo sem sentido. É um pouco como tentar fazer contas de cabeça mais rápido que uma calculadora.

Isso não significa que a especialização perdeu valor. Pelo contrário. Alguém ainda precisa produzir conhecimento novo, validar ideias e, em muitos casos, treinar os próprios sistemas de inteligência artificial. Enquanto a máquina ainda depende de nós para aprender coisas novas, especialistas continuam sendo essenciais.

O problema talvez esteja em outro lugar.

Durante décadas formamos uma enorme quantidade de semi-especialistas, aqueles com conhecimento razoável em um campo estreito, mas não profundo o suficiente para expandir esse campo. Esse tipo de conhecimento intermediário era extremamente útil em um mundo onde informação era escassa. Hoje ele compete diretamente com máquinas que conseguem acessar e organizar quantidades gigantescas de conhecimento em segundos.

Nesse cenário, dois perfis parecem ganhar importância ao mesmo tempo. De um lado, os especialistas muito profundos, que continuam empurrando as fronteiras do conhecimento e criando as bases que a própria inteligência artificial utiliza. Do outro, os generalistas curiosos, que conseguem circular entre áreas diferentes e usar essas ferramentas com algum senso de direção.

A qualidade das respostas de uma inteligência artificial depende bastante da qualidade das perguntas, e boas perguntas raramente nascem de quem conhece apenas uma coisa. Quem já passou por tecnologia, negócios, comportamento humano ou história tende a reconhecer padrões que especialistas às vezes demoram mais para perceber. Não porque saibam mais profundamente sobre um único assunto, mas porque conseguem combinar ideias, e também desenvolver um certo senso crítico para distinguir entre algo que apenas soa convincente e aquilo que realmente faz sentido.

Marc Andreessen, uma das vozes influentes do Vale do Silício, comentou algo nessa linha ao falar sobre o perfil de profissionais na era da IA. Entre apostar em especialistas ou generalistas, ele disse que ficaria com os generalistas. A lógica é simples: a inteligência artificial funciona como um amplificador de profundidade sob demanda. Ela permite mergulhar em qualquer assunto quando necessário. Mas alguém ainda precisa decidir em que direção mergulhar.

Talvez por isso a velha curiosidade generalista esteja ganhando uma utilidade inesperada. Ler sobre assuntos diferentes, experimentar áreas distintas, cultivar interesses que aparentemente não têm relação entre si. Durante muito tempo isso parecia falta de foco. Hoje pode ser exatamente o contrário.

A inteligência artificial aprofunda, mas nós, pelo menos por enquanto, ainda conectamos as coisas.

Continuar lendo

“A primeira máquina ultrainteligente será a última invenção que o homem precisará fazer.” — I. J. Good, 1965

Hoje, novas ferramentas de inteligência artificial surgem numa velocidade que nós mal conseguimos acompanhar. Quando começamos a entender uma, chega outra prometendo fazer tudo melhor. Para quem trabalha com programação, essa mudança é muito clara: há pouco tempo, o máximo que essas ferramentas faziam era sugerir um trecho de código tímido enquanto digitávamos. Agora, nós descrevemos o que queremos e programas inteiros aparecem prontos na tela.

Mas o ponto principal não é a quantidade de lançamentos. É o fato de que a IA deixou de ser apenas um produto final para virar parte do próprio processo de criação. Em Vida 3.0 (Benvirá, 2020), Max Tegmark chama isso de inteligência artificial recursiva. Não é à toa que o desenvolvimento de software tem sido a área mais impactada: como a IA é feita de código, ao aprender a programar, ela consegue se retroalimentar. Cada passo diminui o trabalho do próximo. Basicamente, a máquina ganha o poder de participar da sua própria evolução.

Isso pode assustar, mas a inteligência humana sempre funcionou do mesmo jeito. Ninguém nasce sabendo matemática ou física. Nós aprendemos lendo livros de pessoas que nunca vimos e construímos coisas novas em cima de descobertas antigas. Nossa inteligência individual é só a ponta de um iceberg, apoiada numa base invisível de linguagem e história. Somos, no fundo, mentes biológicas usando o conhecimento acumulado de todo mundo que veio antes.

A grande diferença é que, para nós, esse processo sempre foi lento. O conhecimento levava décadas para se espalhar. Teorias demoravam gerações para amadurecer. Com a IA, esse tempo encolheu. O que antes levava uma vida inteira agora acontece em meses. O aprendizado deixou de ser apenas humano e virou misto. Entregamos parte da criação para máquinas que funcionam numa escala que nós não conseguimos alcançar.

Isso não é necessariamente ruim. O problema não é a ferramenta ficar mais inteligente, mas sim nós perdermos o controle sobre para onde ela está indo. Sempre convivemos com avanços tecnológicos, da imprensa à internet, mas agora o jogo é diferente. O verdadeiro risco é nós lavarmos as mãos e deixarmos esse ciclo rodar solto, sem valores humanos claros e sem ninguém no comando. Se fizermos isso, acabaremos transformando a previsão de I. J. Good em uma profecia apocalíptica.

Continuar lendo

Todo Site Reliability Engineer experiente sabe que resposta a incidentes é, fundamentalmente, sobre informação. Quando algo quebra ou começa a degradar, você não olha para uma única métrica ou uma linha de log isolada. Você navega por logs, traces, alertas, dashboards, mudanças de configuração e conversas humanas para entender o que aconteceu — e o que fazer a seguir.

Agentes de IA prometem ajudar exatamente nesse tipo de sobrecarga cognitiva. Eles conseguem ler, correlacionar e resumir informações mais rápido do que qualquer humano. Mas a efetividade desses agentes é moldada por uma limitação técnica dura — e frequentemente ignorada.

A janela de contexto.

Janelas de Contexto são a Memória de Trabalho da IA

A janela de contexto é a memória de trabalho de um modelo de IA. Ela define quanta informação o agente consegue manter ativa para raciocinar em um determinado momento. Mesmo com modelos modernos anunciando janelas de contexto muito grandes, essa memória continua sendo finita — e surpreendentemente frágil.

Análise de incidentes é a receita perfeita para esgotamento de contexto. Alertas disparam cascatas de chamadas de ferramentas. Logs e traces crescem rapidamente. Snapshots de configuração e dados históricos se acumulam. Quando tudo isso é empurrado para a janela de contexto sem disciplina, o agente não fica mais inteligente. Ele fica mais lento, mais caro e menos confiável.

Mais contexto não significa automaticamente melhor raciocínio. Depois de certo ponto, geralmente significa menos foco.

Agentes, Subagentes e Skills

Agentes modernos de IA são construídos de forma muito parecida com sistemas distribuídos. Eles são compostos por subagentes e skills, cada um responsável por uma tarefa bem delimitada, como análise de logs, inspeção de configurações ou sumarização.

Essa separação de responsabilidades não é apenas uma preferência arquitetural. É um mecanismo de sobrevivência. Escopos menores significam janelas de contexto menores, raciocínio mais claro e menos falhas silenciosas. Um único agente tentando manter todo o estado de um incidente ao mesmo tempo não é diferente de um monólito sob carga ilimitada.

No entanto, isso não acontece automaticamente.

A maioria dos frameworks de agentes oferece subagentes e skills como capacidades — não como salvaguardas. Cabe ao usuário entender como esses recursos funcionam e configurá-los de forma intencional. Sem limites claros, uma skill pode facilmente se tornar apenas mais uma forma de injetar grandes volumes de dados na mesma janela de contexto já sobrecarregada.

MCP: o Inimigo Silencioso da Janela de Contexto

À medida que agentes se tornaram mais comuns nos fluxos de trabalho de SRE, servidores MCP passaram a se proliferar rapidamente. Grafana, GitHub, Slack, sistemas de CI, provedores de cloud e plataformas internas agora expõem interfaces MCP que os agentes podem consumir livremente.

É aqui que o MCP se torna um inimigo silencioso.

Cada servidor MCP representa um potencial dilúvio de tokens. Muitas configurações registram dezenas de ferramentas MCP logo de início, mesmo que apenas uma pequena fração seja usada durante um incidente. O agente nem precisa chamá-las para que o dano aconteça. Esquemas de ferramentas, descrições e capacidades disponíveis já consomem parte da janela de contexto antes mesmo de qualquer trabalho começar.

Com o tempo, isso corrói o espaço efetivo de raciocínio do agente.

Por esse motivo, frameworks de agentes já estão correndo para melhorar o gerenciamento de MCPs. Técnicas como progressive disclosure estão se tornando mais comuns. Em vez de expor todos os MCPs de uma vez, os agentes revelam ferramentas gradualmente, com base na intenção e na etapa da investigação. Outros atrasam o carregamento de metadados até que a ferramenta seja realmente necessária, ou removem dinamicamente MCPs não utilizados do contexto ativo.

A lição é simples: MCPs são poderosos, mas precisam ser tratados como dependências de produção. Cada ferramenta habilitada tem um custo — mesmo quando não é utilizada.

O Verdadeiro Problema de SRE: Explosão de Contexto

Incidentes são iterativos. Cada passo gera mais dados e mais hipóteses.

Imagine um agente investigando um CrashLoopBackOff no Kubernetes. Ele busca a descrição do pod, depois as últimas 500 linhas de log, depois o YAML do deployment. De repente, grande parte do contexto está ocupada por stack traces repetitivos. A mudança real de configuração que causou o problema mal consegue caber.

É assim que falhas silenciosas acontecem. Não porque o modelo é fraco, mas porque o sinal se perdeu no meio do ruído.

Existe também uma preocupação muito prática aqui. Janelas de contexto grandes aumentam latência e custo. Um agente que leva dezenas de segundos para raciocinar porque está relendo milhares de tokens é inútil durante um incidente crítico. Gerenciamento de contexto não é apenas sobre correção. É também sobre FinOps e tempo de resposta.

Tratando o Contexto como um Problema de Engenharia

Trabalhar com IA de forma eficaz em SRE exige tratar contexto como um recurso escasso.

Sumarização precisa ser explícita, não acidental. Skills e subagentes devem ser projetados para emitir estados compactos, não transcrições completas do que observaram. Dados históricos e saídas volumosas devem ser descarregados para sistemas de memória de longo prazo, como vector stores, em vez de permanecer indefinidamente na janela de contexto ativa.

Da mesma forma, o uso de MCPs precisa ser intencional. Habilite menos ferramentas, exponha-as de forma progressiva e remova o que não é necessário. Gerenciamento de contexto não é algo que o agente resolve magicamente por você. É uma decisão de design — e uma responsabilidade.

Agentes também precisam de observabilidade. Uso de tokens por etapa, taxas de compressão e quanto insight é produzido por token importam. Se monitoramos tudo em produção, o agente não deveria ser uma caixa-preta.

Conclusão

Agentes de IA não falham por falta de inteligência. Eles falham porque ficam sobrecarregados.

Para SREs, gerenciar a janela de contexto não é diferente de gerenciar memória, latência ou error budgets. Ignorar isso torna as falhas sutis e caras. Projetar levando isso em conta transforma agentes em parceiros confiáveis — em vez de ferramentas imprevisíveis.

Trate sua janela de contexto como um recurso escasso. Porque dados sem contexto são ruído — e contexto sem gerenciamento é caos.

---

Este artigo foi redigido com o apoio de ferramentas de IA (texto e imagem de capa), com conteúdo final, estrutura e ideias definidos pelo autor.

Continuar lendo