4.3 — Arquitetura de Agentes Investigativos: Loops Probabilísticos para o Desconhecido

Objetivo da Aula

Diferenciar tarefas com playbook fixo de tarefas investigativas, cujo caminho de solução é desconhecido de antemão

Desenhar a anatomia de um loop investigativo: hipótese, ação, observação, atualização de crença

Definir critérios de parada para um loop de agente que não tem número fixo de passos

Tratar o orçamento de iteração como controle arquitetural, não apenas como limite de custo

Reconhecer quando um problema só parece investigativo, mas na verdade tem um playbook escondido

Por que isso importa

Os capítulos 4.1 e 4.2 resolveram o lado determinístico do trabalho de um agente: capacidades com resposta certa, empacotadas em skills, compartilhadas sem duplicação. Mas nem todo problema que um agente enfrenta tem uma skill esperando por ele. “Por que a taxa de erro deste serviço subiu 40% nas últimas duas horas” não é uma tarefa com formato de entrada e saída fixo — é uma investigação. Você não sabe, ao começar, quantos passos vai levar, nem quais arquivos, logs ou métricas vai precisar consultar. Só sabe o objetivo final: encontrar a causa raiz.

Um agente investigativo é desenhado exatamente para esse tipo de espaço de busca aberto: ele orquestra suas próprias ações, decidindo a cada passo o que investigar em seguida com base no que descobriu no passo anterior. Isso já apareceu na Parte 1, capítulo 1.6, como padrão de loop (ReAct, Ralph Loop). Aqui a questão muda de “qual padrão de loop existe” para “como desenhar um agente cujo loop é a própria arquitetura da solução, não um detalhe de implementação”.

Impacto direto no seu trabalho: todo sistema autônomo em produção que investiga algo — debugging de incidente, triagem de causa raiz, análise exploratória de dados desconhecidos — vive ou morre pela qualidade do critério de parada. Um loop investigativo sem controle de orçamento não é uma feature poderosa, é um incidente esperando para acontecer: ele pode rodar indefinidamente, consumindo tokens e ações reais no sistema, atrás de uma resposta que talvez não exista da forma que o agente está procurando.

Conceitos Fundamentais

O espectro determinístico → investigativo

É útil pensar nas capacidades de um agente como pontos num espectro, não como categorias estanques. Skills (4.1) ficam num extremo. Loops investigativos ficam no outro. No meio, workflows fixos e loops leves de poucos passos.

A decisão de arquitetura não é escolher um ponto fixo do espectro para o sistema inteiro — é reconhecer, tarefa a tarefa, onde ela cai. Um bom harness usa skills para as partes determinísticas mesmo dentro de uma investigação (por exemplo, uma skill de “consultar métricas do serviço X” é chamada repetidamente pelo loop investigativo, mas a decisão de qual métrica consultar e quando parar é probabilística).

Anatomia do loop investigativo

Um agente investigativo repete um ciclo de quatro fases até atingir uma condição de parada: formular hipótese, agir para testá-la, observar o resultado, atualizar a crença sobre qual é a causa provável.

estado = { objetivo, historico_de_acoes = [], crenca_atual = null,
           confianca = 0.0, iteracao = 0 }

enquanto não atingiu_criterio_de_parada(estado):
    hipotese = formular_hipotese(estado.objetivo, estado.historico_de_acoes)
    acao = escolher_acao_para_testar(hipotese)
    observacao = executar(acao)                 # ex: consultar logs, rodar query

    estado.historico_de_acoes.append({acao, observacao})
    estado.crenca_atual, estado.confianca = atualizar_crenca(
        estado.crenca_atual, observacao
    )
    estado.iteracao += 1

retornar { causa_provavel: estado.crenca_atual,
           confianca: estado.confianca,
           trilha_de_evidencia: estado.historico_de_acoes }

Repare que o loop não decide de antemão quantas iterações vai precisar — cada observação pode confirmar, refutar ou ramificar a hipótese corrente, e o próximo passo depende do resultado do passo anterior. É exatamente essa dependência sequencial e não pré-determinada que caracteriza um loop investigativo, em oposição a um workflow fixo que apenas executa passos numa ordem já conhecida.

Exemplo numérico: debugging autônomo de um incidente

Considere um agente investigando por que a taxa de erro de um serviço subiu. O traço abaixo é ilustrativo do tipo de progressão que um loop investigativo percorre:

Iteração 1
  hipótese: "deploy recente introduziu regressão"
  ação: consultar histórico de deploys das últimas 4h
  observação: nenhum deploy nas últimas 6h
  confiança na hipótese: 0.10 (refutada, quase descartada)

Iteração 2
  hipótese: "dependência externa está degradada"
  ação: consultar latência e taxa de erro de serviços downstream
  observação: serviço de pagamento com latência 3x acima do normal
  confiança na hipótese: 0.65 (evidência favorável, ainda não confirmada)

Iteração 3
  hipótese: "timeout configurado é menor que a nova latência
             do serviço de pagamento"
  ação: consultar configuração de timeout do client HTTP
  observação: timeout = 500ms; p95 de latência do serviço de
              pagamento subiu para 800ms no mesmo período
  confiança na hipótese: 0.92 (forte correlação temporal e causal)

Critério de parada atingido: confiança >= 0.90
Causa provável reportada: "timeout de 500ms incompatível com
  degradação de latência do serviço de pagamento (p95: 800ms)"

Três iterações, cada uma informada pela anterior. Um workflow fixo jamais chegaria a essa sequência específica, porque ele não sabia de antemão que precisaria checar timeout de HTTP client — essa ação só fez sentido depois que a observação da iteração 2 apontou para o serviço de pagamento.

Restringindo o conjunto de ações do loop

Um agente investigativo com acesso irrestrito a qualquer ação do sistema tem um fator de ramificação artificialmente inflado — nem toda ação disponível é relevante para toda investigação, mas se todas estão visíveis, o modelo gasta parte do seu raciocínio descartando opções óbvias a cada iteração. A prática recomendada é curar, por domínio de investigação, um subconjunto de skills e ferramentas que o loop pode invocar — o mesmo catálogo do capítulo 4.2, agora resolvido para o escopo específico de "investigação de incidente de produção":

escopo_investigativo("incidente_producao") = [
    consultar_metricas_servico,
    consultar_logs_estruturados,
    consultar_historico_deploys,
    consultar_configuracao_atual,
    consultar_status_dependencias_externas
]
# note o que NÃO está na lista: skills de escrita/modificação
# (alterar configuração, reiniciar serviço) ficam fora do
# escopo do loop investigativo — investigação é só leitura;
# ação corretiva é uma decisão humana ou um agente separado,
# com aprovação própria (tema da Parte 1, RBAC no agent loop)

Restringir o loop investigativo a ações de leitura não é apenas uma questão de reduzir o espaço de busca — é também uma fronteira de segurança: um agente que só observa não pode causar um segundo incidente ao tentar corrigir o primeiro com base numa hipótese ainda não confirmada.

Aprofundamento Técnico

Orçamento de iteração como circuit breaker, não só como custo

É tentador tratar o limite de iterações de um loop investigativo puramente como controle de custo — “não deixa gastar mais que X dólares em tokens nesta investigação”. Isso é verdadeiro, mas incompleto. O orçamento de iteração é, antes de tudo, um circuit breaker contra um modo de falha específico de agentes autônomos: o loop que não converge porque a hipótese inicial estava errada e o agente nunca reconhece isso, ficando preso testando variações da mesma hipótese ruim.

função atingiu_criterio_de_parada(estado):
    se estado.confianca >= LIMIAR_CONFIANCA:
        retornar verdadeiro          # convergiu

    se estado.iteracao >= MAX_ITERACOES:
        retornar verdadeiro          # circuit breaker: para,
                                       # reporta "inconclusivo"

    se nao_houve_ganho_de_confianca(estado, ultimas_n=3):
        retornar verdadeiro          # estagnação: para antes
                                       # do limite máximo

    retornar falso

O terceiro critério — estagnação — é tão importante quanto o limite máximo. Um agente que testou três hipóteses seguidas sem ganho de confiança provavelmente está num ramo improdutivo do espaço de busca; continuar até o limite máximo de iterações só adia a conclusão “inconclusivo”, gastando orçamento sem ganho de informação.

Confiança calibrada vs. confiança aparente

O maior risco de um agente investigativo não é ele não encontrar a causa — é ele reportar uma causa errada com alta confiança aparente. Um modelo de linguagem pode gerar uma explicação fluente e convincente para uma correlação espúria, e nada no texto gerado distingue isso de uma causa raiz de fato bem estabelecida.

A mitigação estrutural é não confiar na confiança que o próprio modelo declara em linguagem natural (“tenho certeza de que...”) como sinal de parada. A confiança do estado do loop, no pseudocódigo acima, deveria ser derivada de evidência estruturada — quantas observações independentes corroboram a hipótese, se existe uma relação temporal/causal verificável nos dados, não apenas do tom assertivo da resposta do modelo.

função calcular_confianca_estruturada(hipotese, observacoes):
    pontuacao = 0.0

    # cada critério soma pontuação, nenhum sozinho é suficiente
    se correlacao_temporal_verificavel(hipotese, observacoes):
        pontuacao += 0.35
    se numero_de_observacoes_independentes(observacoes) >= 2:
        pontuacao += 0.30
    se existe_precedente_historico_similar(hipotese):
        pontuacao += 0.20
    se nenhuma_observacao_contradiz(hipotese, observacoes):
        pontuacao += 0.15

    retornar min(pontuacao, 1.0)
    # note: a fluência textual da explicação do modelo
    # NÃO é um dos critérios — de propósito

Esse desenho deliberadamente separa "o modelo soa convincente" de "a evidência estruturada sustenta a hipótese". São coisas diferentes, e só a segunda deveria autorizar o loop a parar e reportar uma causa raiz com alta confiança.

Checkpoints de confirmação humana em investigações de alto impacto

Para investigações cujo resultado alimenta uma ação de impacto real — desligar um serviço, reverter um deploy, notificar um cliente — o critério de parada por confiança alta não deveria, sozinho, autorizar a ação seguinte. O padrão é o loop investigativo convergir para uma conclusão e um checkpoint humano (HITL, já visto na Parte 1) revisar a trilha de evidência antes de qualquer ação corretiva ser tomada com base nela.

se estado.confianca >= LIMIAR_CONFIANCA:
    se impacto_da_acao_decorrente == "alto":
        retornar { status: "aguardando_confirmacao_humana",
                   causa_provavel: estado.crenca_atual,
                   trilha_de_evidencia: estado.historico_de_acoes }
    senão:
        retornar { status: "concluido", causa_provavel: ... }

Isso não enfraquece a autonomia do agente investigativo — ele continua decidindo sozinho o que investigar e em que ordem. O que muda é que a trilha de evidência, não apenas a conclusão, é o que se entrega no final: um humano revisando três iterações com evidência estruturada decide muito mais rápido do que um humano investigando do zero.

registro_de_execucao = {
    objetivo: "causa raiz do aumento de taxa de erro",
    iteracoes: [
        { n: 1, hipotese: "...", acao: "...", observacao: "...",
          confianca_apos: 0.10 },
        { n: 2, hipotese: "...", acao: "...", observacao: "...",
          confianca_apos: 0.65 },
        { n: 3, hipotese: "...", acao: "...", observacao: "...",
          confianca_apos: 0.92 }
    ],
    criterio_de_parada_atingido: "confianca_minima",
    custo_total: { iteracoes: 3, tokens: 4200 }
}

Esse critério de quando um agente deve investigar sozinho e quando deve seguir um caminho conhecido prepara a próxima decisão de arquitetura: mesmo dentro de uma investigação legítima, algumas ações consomem contexto de forma desproporcional ao valor que trazem — e o harness precisa decidir quando isolar essas ações fora da thread principal do agente. É o tema do próximo capítulo.