Parte 1: Intenção vs Estado — Como o Agente DevOps da AWS Fecha a Lacuna

Há algumas semanas, eu estava em uma mesa redonda da AWS em Auckland. Uma dúzia de líderes de plataforma ao redor de uma mesa, cada um deles colocando agentes de IA em produção, cada um deles descrevendo a mesma lacuna.

Seus agentes podiam ler a documentação da AWS. Podiam chamar a API da AWS. Podiam escrever Terraform. Podiam até, em um bom dia, propor uma correção para um incidente real.

O que nenhum deles conseguia fazer: informar ao plantão se a exposição da API no serviço de faturamento é uma regressão — ou uma aceitação de risco de 30 dias que a equipe aprovou no último trimestre.

Essa lacuna é sobre o que toda essa série trata.

Vou mostrar a configuração do AWS DevOps Agent que construí para fechá-la. A implementação complementar é Intent Guard — uma demonstração que publicarei junto com esta série (anonimizada; não posso compartilhar a cópia da minha empresa).

A coisa que mais demorou para eu internalizar: a parte difícil de um agente ciente da organização não é a IA. A parte difícil é descobrir onde as decisões reais da sua organização estão, colocá-las diante do modelo no momento em que importam e dar ao modelo metadados suficientes para saber quais ainda se aplicam.

Deixe-me começar com a estrutura sobre a qual o restante da série se baseia.

Quando algo quebra às 3 da manhã, o que você realmente olha?

Existem duas pilhas de evidências sobre o seu sistema, e elas são usadas de maneira muito diferente.

A pilha do "o que É". Logs, métricas, rastreamentos, CloudTrail. Esta é a metade madura. Cada ferramenta de incidente importante — Datadog Watchdog, New Relic AI, PagerDuty AIOps — é excelente nisso. Elas fazem detecção de anomalias, correlação de alertas, atribuição de mudanças. Até 2026, isso é um problema suficientemente resolvido que, no momento em que os alertas disparam, você tem minutos de triagem automatizada.

A pilha do "o que DEVE SER". ADRs, runbooks, documentos de planejamento, relatórios de incidentes, as notas da reunião onde alguém concordou em adiar o trabalho de OAuth até depois do lançamento. Sua organização escreveu tudo isso uma vez. Depois, na maioria das vezes, ninguém lê novamente.

Aqui está a verdade desconfortável: ninguém lê ambos na primeira hora. O plantão puxa painéis. Eles rolam logs. Se forem seniores, perguntam no Slack: "Houve alguma mudança?" Se nada mudou, eles vão mais fundo nas métricas.

O que eles quase nunca fazem, na primeira hora, é abrir o repositório de ADR e procurar por "circuit breaker" ou "rate limit" — porque não têm motivo para suspeitar que o incidente é sobre uma decisão que a equipe tomou três meses atrás e que silenciosamente passou do prazo.

Essa é a lacuna. Os piores incidentes que assisti nos últimos anos não foram sobre mudanças recentes. Eles foram sobre decisões tomadas meses antes que se transformaram em dívidas enquanto nenhum alarme estava observando.

Se o estado é a metade madura do problema, a intenção é a metade que ninguém automatizou ainda.

O que mudou quando o AWS DevOps Agent foi lançado

O AWS DevOps Agent foi anunciado no re:Invent 2025 e entrou em GA em abril de 2026. Por trás dele, ele roda no Bedrock AgentCore com Claude como o modelo padrão. Da perspectiva de um construtor, os pontos interessantes são:

• Ele aceita gatilhos do CloudWatch, PagerDuty, Dynatrace, ServiceNow — ou qualquer webhook assinado.
• Ele executa uma investigação autônoma em sua telemetria, CloudTrail, repositórios de código e quaisquer Bases de Conhecimento Bedrock que você registrou.
• Ele apresenta uma descoberta com citações — linhas de log, eventos de trilha, IDs de documentos de KB.

A mudança mental: não é "mais uma ferramenta de AIops". É um SRE que leu cada ADR que você já escreveu e começa o runbook no momento em que seu alarme dispara.

Isso muda o que é possível na primeira hora — mas apenas se as decisões da sua organização estiverem realmente em uma Base de Conhecimento em uma forma que o agente possa usar. A maioria das ADRs das organizações não estão. Esse é o trabalho.

Uma maneira útil de posicionar isso em relação às ferramentas existentes:

                 │ Lê                        │ Perde
─────────────────┼───────────────────────────┼─────────────────────────
AIops incumbentes │ Telemetria — anomalia      │ Suas ADRs.
(Watchdog, New   │ detecção, alerta          │ Seus runbooks.
Relic AI,        │ correlação.               │ Suas decisões.
PagerDuty AIOps) │                           │
─────────────────┼───────────────────────────┼─────────────────────────
DevOps Agent +   │ Telemetria mais sua       │ —
KB curada        │ intenção documentada.     │

Quero ter cuidado aqui: as ferramentas do "o que É" são maduras e boas. Isso não é uma substituição. É a camada que eles não veem.

Um cenário concreto: 60 dias após um compromisso

A estrutura genérica só vai até certo ponto. Deixe-me tornar isso real com a demonstração que usarei ao longo da série.

Northwind Logistics é uma SaaS B2B fictícia. (O cliente é fictício. A arquitetura e a forma do incidente são reais, extraídas do trabalho que fiz.) Eles rodam na AWS, ECS Fargate, RDS, App Runner. Eles têm um recurso interno chamado northwind-quote que transforma um resumo do cliente em uma proposta orçada — a mágica acontece em um endpoint /tweak que chama o Bedrock de forma síncrona para aplicar ajustes em linguagem natural como "trocar para Nova Pro" ou "reduzir para 10M tokens/dia".

A equipe lançou northwind-quote em janeiro de 2026. Eles sabiam que a chamada síncrona do Bedrock era um risco. Eles capturaram esse risco em uma ADR:

---
type: adr
id: ADR-004
title: Chamada síncrona do Bedrock em /tweak — temporária
date: 2026-01-12
status: aceito
service: northwind-quote
expires: 2026-03-01
---

# ADR-004: Chamada síncrona do Bedrock em /tweak

## Status
ACEITO (TEMPORÁRIO) — circuito de interrupção devido em 2026-03-01