O ChatGPT conhece DevOps. Ele explica conceitos de Kubernetes, sugere padrões de Terraform e ajuda a depurar mensagens de erro.

Mas não consegue dizer por que os SEUS pods estão caindo às 3 da manhã.

Este guia apresenta os padrões para construir agentes de IA que vão além do conselho genérico: agentes que entendem a sua infraestrutura específica e conseguem agir de forma relevante.

Por que agentes verticais superam a IA genérica

O problema da IA genérica

Pergunte ao ChatGPT “Como corrijo um crash loop de pod no Kubernetes?” e você receberá uma resposta completa, cobrindo todas as causas possíveis. Isso ajuda a aprender, mas não a resolver o SEU problema às 2 da manhã.

A IA genérica oferece:

Explicações amplas, que servem para todo mundo
Sugestões que podem não caber na sua arquitetura
Nenhum contexto sobre os seus sistemas
Risco de alucinação nos detalhes específicos

A abordagem do agente vertical

Os agentes verticais invertem esse modelo:

Aspecto	IA genérica	Agente vertical
Escopo	Tudo	Um domínio
Contexto	Nenhum	Sua infraestrutura
Resultado	Conselho genérico	Passos acionáveis
Alucinação	Risco maior	Menor (domínio restrito)

Um agente de monitoramento que conhece a SUA infraestrutura consegue dizer:

“O pod X está em crash loop porque o connection pool do banco de dados esgotou”
“Isso aconteceu duas vezes no mês passado, depois do pico de tráfego de terça-feira”
“O runbook 7.3 trata desse caso. Quer que eu aplique?”

A filosofia de agentes da Webera

Não construímos uma única IA que faz tudo. Construímos 9 especialistas, cada um fazendo uma coisa com excelência:

Sentinel — Monitoramento e observabilidade
Guardian — Segurança e compliance
Optimizer — Custo e desempenho
Conductor — CI/CD e deploy
Dispatcher — Alertas e roteamento
Navigator — Descoberta e documentação
Keeper — Segredos e gerenciamento de acesso
Warden — Auditoria e governança
Forge — Preparação de aplicações

Cada agente é um especialista profundo no seu domínio, com contexto sobre os SEUS sistemas.

Parte 1: Anatomia de um agente de infraestrutura

Todo agente eficaz precisa de três coisas: Por quê, Como e O quê.

O Por quê: identidade e missão

Antes de escrever qualquer código, defina:

Quem é este agente? Dê a ele um nome e uma personalidade
Que problema ele resolve? Um problema específico, não vários
Como é o sucesso? Resultados mensuráveis

Exemplo: Sentinel (agente de monitoramento)

identity:
  name: Sentinel
  tagline: "Watching while you sleep"
  mission: Ensure no issue goes undetected
  success_metrics:
    - Zero surprise outages
    - Mean time to detection < 5 minutes
    - False positive rate < 10%

O Como: princípios de operação

Defina como o agente toma decisões:

O que ele pode fazer sozinho? Operações somente de leitura, mudanças fora de produção
O que exige aprovação? Mudanças em produção, exclusões
Com quem ele colabora? Outros agentes, pessoas

O Quê: responsabilidades específicas

Liste o que esse agente faz, concretamente:

O conhecimento de domínio de que ele precisa
Os workflows que ele executa
Os resultados que ele produz
Os materiais de referência que ele usa

Parte 2: Autoridade de decisão, o padrão crítico

Sem limites claros de autoridade, os agentes ou pedem permissão para tudo (inútil) ou agem sozinhos em tudo (perigoso).

A matriz de autoridade

Tipo de ação	Nível de autoridade
Descoberta somente leitura	Autônomo
Avaliação e análise	Autônomo
Mudanças fora de produção	Autônomo
Propostas para produção	Autônomo para propor
Execução em produção	Exige aprovação
Excluir ou remover qualquer coisa	Exige aprovação

Implementando a matriz

Veja como um agente bem projetado trata uma solicitação:

Solicitação: “Configure o monitoramento da produção”

AUTÔNOMO: Descobrir a infraestrutura atual
AUTÔNOMO: Avaliar o que está faltando
AUTÔNOMO: Propor a stack de monitoramento
EXIGE APROVAÇÃO: Executar as mudanças em produção
AUTÔNOMO: Verificar e documentar

O agente faz o raciocínio; as pessoas aprovam a ação.

Por que isso importa

Considere dois cenários:

Cenário A: sem matriz de autoridade O agente recebe um alerta de CPU alta. Ele escala? Investiga? Acorda alguém? Sem limites claros, ou ele não faz nada de útil ou faz algo perigoso.

Cenário B: matriz de autoridade clara O agente recebe o alerta. Ele investiga e correlaciona com os deploys recentes DE FORMA AUTÔNOMA. Propõe um rollback, com evidências, DE FORMA AUTÔNOMA. EXIGE APROVAÇÃO antes de executar o rollback.

O segundo agente é útil E seguro.

Parte 3: Injeção de contexto, a SUA infraestrutura e não conselhos genéricos

A diferença entre “o ChatGPT conhece DevOps” e “nossos agentes conhecem a SUA infraestrutura” é o contexto.

O padrão do arquivo de contexto

Os agentes precisam de conhecimento estruturado sobre os SEUS sistemas:

# .webera/context.yaml
infrastructure:
  cloud: aws
  region: us-east-1
  account_id: "123456789012"

  kubernetes:
    version: "1.28"
    cluster: "production-eks"
    namespaces:
      - name: api
        criticality: high
      - name: workers
        criticality: medium

  databases:
    - type: postgresql
      version: "15"
      name: "primary-db"
      rds_instance: "db.r6g.xlarge"

services:
  - name: api
    repository: "company/api"
    criticality: high
    dependencies: [primary-db, redis]
    sla_target: "99.9%"

  - name: worker
    repository: "company/worker"
    criticality: medium
    dependencies: [primary-db, rabbitmq]

Por que o contexto vence o prompt

Sem arquivo de contexto:

User: "Why is my API slow?"
Agent: "There could be many reasons. Check your database queries,
       network latency, CPU usage..."

Com arquivo de contexto:

User: "Why is my API slow?"
Agent: "Your API service depends on primary-db (PostgreSQL 15 on
       db.r6g.xlarge). Checking CloudWatch metrics... Connection
       pool is at 95% capacity. This matches the pattern from last
       Tuesday's incident. Recommend increasing pool size per
       runbook 4.2."

A diferença é a especificidade acionável.

Mantendo o contexto atualizado

Os arquivos de contexto devem ser:

Versionados — No seu repositório git
Descobertos automaticamente — Os agentes podem atualizá-los (com aprovação)
Validados — Verificados por schema para evitar erros

Parte 4: Colaboração entre agentes

Agentes isolados são limitados. Sistemas de agentes são poderosos.

O padrão de handoff

Os agentes trabalham juntos por meio de handoffs bem definidos:

Sentinel (monitoring) ──detects issue──► Dispatcher (routing)
Dispatcher ──routes to──► On-call engineer

Guardian (security) ──secures──► Conductor (pipelines)
Optimizer (cost) ◄──metrics from── Sentinel (monitoring)

Projetando handoffs

Cada handoff precisa de:

Gatilho claro — Quando o handoff acontece?
Passagem de contexto — Quais informações são transferidas?
Confirmação — Como o agente receptor confirma?

Exemplo de handoff:

handoff:
  from: sentinel
  to: dispatcher
  trigger: alert_threshold_exceeded
  context:
    - alert_type
    - affected_service
    - metrics_snapshot
    - suggested_runbook
  acknowledgment: dispatcher_received

Exemplo do mundo real

1. Sentinel detects: High error rate on API service (5xx > 1%)
2. Sentinel outputs:
   - Alert with context (service, metrics, timeframe)
   - Correlation with recent events
   - Suggested runbook
3. Sentinel suggests: "Engage Dispatcher to route this alert"
4. Dispatcher receives: Alert + context
5. Dispatcher checks: Runbook exists for this scenario
6. Dispatcher decides: Route to API team based on on-call schedule
7. Dispatcher notifies: Slack + PagerDuty with full context

Nenhuma intervenção humana até o passo 7. Mas as pessoas continuam no controle.

Parte 5: Personalização por cliente

O mesmo agente deve se comportar de forma diferente em contextos diferentes.

Por que a personalização importa

Cliente A: focado em SOC 2, controle de mudanças rigoroso, exige aprovação para tudo
Cliente B: andar rápido, quebrar coisas (mas consertar rápido), autônomo fora de produção

Mesmo agente, comportamento diferente.

O padrão de personalização

# Client-specific settings
agent_customization:
  sentinel:
    focus_areas:
      - "API latency"
      - "Database connections"
    ignore_namespaces:
      - "kube-system"
      - "monitoring"
    alert_threshold_multiplier: 1.5  # More lenient
    notes: "Previous P1 was API latency related - prioritize"

  guardian:
    compliance_focus:
      - "SOC2"
      - "HIPAA"
    backup_priority: "critical"
    approval_required_for: "all_changes"
    notes: "Healthcare client, strict compliance required"

Dicas de implementação

Consulte a personalização primeiro — Antes de qualquer ação, carregue as configurações do cliente
Use as notas como contexto — O histórico informa as decisões atuais
Na dúvida, o modo seguro — Sem personalização, use padrões conservadores

Parte 6: Construindo seu primeiro agente

Pronto para construir? Veja o passo a passo.

Passo 1: Escolha um domínio restrito

NÃO assim: “Agente de infraestrutura” Assim: “Agente de monitoramento e alertas”

Escopo restrito = especialização profunda = melhores resultados.

Passo 2: Defina a identidade (Por quê)

identity:
  name: [Agent name]
  tagline: [One-line mission]
  problem_solved: [Specific problem]
  success_criteria:
    - [Measurable outcome 1]
    - [Measurable outcome 2]

Passo 3: Defina a autoridade (Como)

authority:
  autonomous:
    - Read infrastructure state
    - Analyze metrics and logs
    - Generate reports
    - Propose changes
  requires_approval:
    - Execute production changes
    - Modify security settings
    - Delete resources
  handoffs_to:
    - [Other agent for related work]

Passo 4: Defina o conhecimento (O quê)

knowledge:
  domain_expertise:
    - [Technical area 1]
    - [Technical area 2]
  reference_materials:
    - [Documentation source]
    - [Runbook location]
  output_formats:
    - [Report type]
    - [Alert format]

Passo 5: Crie a injeção de contexto

Defina o que o agente precisa saber sobre cada infraestrutura:

Inventário de serviços
Dependências
SLAs e criticidade
Incidentes anteriores

Passo 6: Teste de forma incremental

Primeiro, somente leitura — Ele entende corretamente a infraestrutura?
Depois, análise — As avaliações dele são precisas?
Em seguida, propostas — As ações sugeridas são adequadas?
Por último, execução — Ele executa com segurança, mediante aprovação?

Parte 7: Armadilhas comuns

Armadilha	Problema	Solução
Amplo demais	O agente não sabe quando entrar em ação	Restrinja o domínio
Sem matriz de autoridade	Pede permissão para tudo	Defina as ações autônomas
Sem contexto	Conselho genérico, não específico	Injete o contexto da infraestrutura
Sem handoffs	O agente trabalha isolado	Defina as relações
Sem personalização	Mesmo comportamento para todos os clientes	Adicione configurações por cliente
Sem testes	Perigoso em produção	Teste de forma incremental

Por que construímos 9 agentes, e não 1

A tentação

“Construir uma IA que cuide de todo o DevOps.”

Parece eficiente. Um sistema para governar todos.

A realidade

Em domínios especializados, o vertical vence o horizontal:

Monitoramento exige uma especialidade diferente de segurança
Otimização de custos exige um contexto diferente de deploy
9 especialistas > 1 generalista

Cada um dos nossos agentes é um especialista profundo em uma única coisa. Eles colaboram quando necessário, mas não tentam fazer tudo.

Nossos agentes conhecem a SUA infraestrutura porque:

Leem seus arquivos de contexto
Aplicam suas personalizações
Seguem seus runbooks
Se integram às suas ferramentas
Aprendem com seus incidentes

O ChatGPT conhece DevOps. Nossos agentes conhecem a SUA infraestrutura.

Próximos passos

Opção 1: Construa o seu

Use este guia para criar agentes para as suas necessidades específicas. Comece restrito, teste a fundo e expanda aos poucos.

Opção 2: Use os nossos

Nossos 9 agentes já estão construídos, testados e calejados em dezenas de infraestruturas de clientes.

Agende uma conversa para ver como o nosso time de IA pode trabalhar com o seu.

Opção 3: Híbrido

Alguns clientes usam os nossos agentes enquanto constroem os próprios para domínios específicos. Teremos prazer em compartilhar padrões e colaborar.