Este é um problema real e recorrente em times de SRE/DevOps que colocam um agente para diagnosticar incidentes e, gradualmente, conectam ferramentas até que ele deixe de “recomendar” e passe a “operar” em produção. O erro não aparece como uma queda única e óbvia. Ele aparece como vazamento de autoridade: mudanças com blast radius maior do que o necessário, correções que mascaram a causa raiz, degradação silenciosa e, em casos piores, indisponibilidade e perda de dados.
Aqui, Agent Map é um diagnóstico: um modo de mapear onde a autoridade está, como ela flui entre agentes, ferramentas e pipelines, onde cruza limites e onde não existe freio suficiente para interromper o sistema quando a confiança cai.
AS-IS — autoridade por inércia, controle por narrativa
No estado AS-IS, o padrão típico é simples: o agente recebe alertas e sinais, propõe uma correção e executa (reinicia serviços, muda autoscaling, altera configuração, faz rollout, roda scripts, ajusta policies). A “política” existe em documentos e boas práticas, mas não existe como limite executável no runtime. Quando há desvio, a organização explica por narrativa: “o agente viu X”, “era urgente”, “o playbook indicava Y”, “foi uma exceção”.
O diagnóstico Agent Map, aplicado ao AS-IS, costuma revelar quatro falhas estruturais:
1) Direitos de mudança implícitos
Não há fronteira clara entre “diagnosticar/recomendar” e “aplicar mudança”. O agente vira o ponto de decisão por estar no caminho do incidente. Isso é autoridade acidental: ninguém delegou explicitamente, mas o sistema passou a operar como se tivesse delegado.
2) Ferramentas como delegação invisível (sem blast radius)
Conectar CLI de cluster, APIs de nuvem, pipelines de deploy e ferramentas de configuração parece um detalhe técnico, mas na prática é transferência de poder. Sem escopo obrigatório (serviço, ambiente, região, conta) e sem limites, a remediação “local” vira mudança sistêmica.
3) Handoffs opacos e sem recibo
Quando o agente muda produção, faltam recibos replayáveis: quais sinais sustentaram a hipótese, qual regra/playbook foi aplicado, qual versão estava ativa, quais alternativas foram descartadas, qual sequência de comandos ocorreu. Sem isso, o pós-incidente vira opinião — e a correção vira tentativa e erro.
4) Sem freios: hesitação e rollback improvisados
Quando sinais são conflitantes ou o incidente é novo, o sistema não tem um mecanismo claro de hesitar e escalar. E quando a mudança foi errada, o rollback depende de mutirão: reverter às pressas, desfazer manualmente, “voltar como estava” sem preparação — o que em infraestrutura raramente existe de verdade.
Os sintomas emergem como custo oculto:
- correções rápidas na média, incidentes maiores na cauda;
- “conserto” que vira dívida (configuração divergente, exceções permanentes);
- confiança interna corroída (times criam bypass, travas ad hoc, aversão a automação);
- dificuldade crescente de auditar por que mudanças aconteceram.
TO-BE — o que o diagnóstico Agent Map recomenda ajustar no sistema
No estado TO-BE, a pergunta deixa de ser “como fazer o agente consertar mais rápido” e vira “como manter controle quando inevitavelmente ele estiver errado”. O Agent Map, como diagnóstico, recomenda um redesenho centrado em quatro correções operacionais.
1) Tornar explícitos os direitos de mudança (recomendar ≠ executar)
O agente passa a propor ações com justificativa, mas a execução passa por um plano de controle fora do modelo: validações, limites, autorização e condição de parada. Isso elimina autoridade por inércia em produção.
2) Definir corredores de permissão por classe de mudança (risco e reversibilidade)
O diagnóstico recomenda classificar ações:
- baixo impacto e reversíveis podem ser automáticas (coleta de evidências, checks, diagnóstico assistido);
- impacto médio exige supervisão leve e blast radius estrito (um serviço, um ambiente, uma região);
- alto impacto ou irreversíveis exigem escalonamento e aprovação humana (infra, políticas, roteamento, migrações).
A organização para de discutir “o agente pode?” e passa a operar “em qual corredor isso está?”.
3) Exigir escopo e fatos antes de mudança (evidência mínima + limites)
Antes de aplicar qualquer remediação, o fluxo precisa fechar evidências mínimas: sinais consistentes, hipótese explícita, alvo explícito e impacto estimado. Se dados entram em conflito, a recomendação correta é hesitar e escalar — não “agir para ver se melhora”.
4) Implantar recibos replayáveis e reversibilidade real
O diagnóstico recomenda que toda mudança relevante gere um recibo mínimo (hipótese, sinais usados, regra aplicada, comandos/ações exatas, alvo exato, resultado observado) e que mudanças só sejam automatizadas quando houver rollback confiável (canary/rollout reversível, flags, snapshots, idempotência). Sem isso, cada remediação automática vira risco acumulado; com isso, vira capacidade controlada.
Análise — Agent Map como diagnóstico separa “automação” de “delegação”
O que o Agent Map evidencia é uma diferença que costuma ficar invisível: automatizar remediação em incidentes não é apenas “ganhar velocidade”. É redistribuir autoridade sobre mudança em produção. No AS-IS, essa autoridade escapa por detalhe técnico: credenciais amplas, ferramentas sem escopo, pipelines acionáveis e ausência de recibo e freio. No TO-BE, a autoridade vira explícita, mensurável e interrompível — e a automação deixa de ser aposta cega para virar engenharia governável.
O custo do TO-BE é disciplina: mais validação, mais instrumentação, mais etapas e mais desenho de rollback. O ganho é previsibilidade: menos incidentes grandes na cauda, menos exceções que viram infraestrutura, e capacidade de evoluir automação sem transformar produção em um laboratório involuntário.
Onde está a maior ilusão hoje — acreditar que o problema é “o agente não ser bom o suficiente”, ou reconhecer que o problema é delegação de autoridade sem mapa explícito de mudança? E qual correção deveria virar prioridade já agora — separar recomendar de executar, instituir corredores de permissão por blast radius, ou exigir recibos replayáveis para toda ação com impacto relevante?