Camada de Veredicto: A Necessidade de Estruturar Decisões para Agentes de IA

Um agente de liberação interno terminou um deploy um pouco depois das 2 da manhã e então não tinha nada que pudesse ler.

Os painéis estavam verdes. Mas verde é algo que você vê, não algo que você busca. O próximo passo do agente, continuar a implantação ou pausar e esperar por um humano, dependia de um julgamento que existia apenas em uma tela que ninguém estava olhando. Então, ele fez a única coisa segura disponível para ele. Ele parou e esperou que alguém acordasse e confirmasse o que os gráficos já estavam mostrando.

Essa lacuna ficou comigo. O pipeline era automatizado de ponta a ponta, exceto pelos quinze minutos logo após o deploy, onde ele silenciosamente voltava para uma pessoa. Alguém ainda precisava olhar para os sinais de execução e decidir se a coisa que acabou de ser enviada estava se comportando.

Eu havia construído uma camada de veredicto para essa janela exata. Ela lia sinais de deploy brutos: taxas de erro, latência, tipos de exceção, metadados de deploy. Ela emitia um de três estados. ESTÁVEL, OBSERVAR, RISCO. O problema não era o veredicto. O problema era que eu a havia construído para um humano ler, e o agente que realmente precisava da resposta às 2 da manhã não conseguia acessá-la.

O segundo leitor para o qual eu não havia projetado

Eu havia assumido que a decisão pós-deploy tinha um consumidor: o operador. Em uma equipe pequena, isso é frequentemente verdade. Uma pessoa conhece o deploy, vê os painéis, toma a decisão em poucos segundos.

Mas no momento em que qualquer coisa a jusante do deploy é automatizada, seja um agente de liberação, um controlador de rollout progressivo, ou um fluxo de trabalho que promove uma build de canário para total, essa automação se torna um segundo leitor da mesma decisão. E ela não lê da maneira que um humano lê.

Um humano dá uma olhada em um painel de latência e infere que o aumento às 02:04 se alinha com o rollout. Um agente não pode dar uma olhada. Ele não pode inferir a partir de uma renderização. Ele precisa da conclusão como um valor no qual pode ramificar, não uma imagem que precisa interpretar.

Essa é a parte que eu havia colapsado. O veredicto existia, mas existia em uma forma que apenas um de seus dois leitores poderia usar.

Por que um painel não serve a isso

Um painel é uma renderização para um leitor com olhos, atenção e contexto. Ele assume que alguém já sabe qual deploy foi feito, qual painel importa e como é o normal para este serviço.

Um agente chega sem nada disso. Entregar a ele um painel é entregar uma fotografia de uma resposta e pedir que ele leia a resposta de volta. Mesmo quando os dados por trás do painel estão disponíveis através de uma API, o que vem de volta geralmente é um sinal mais bruto: séries temporais, fluxos de eventos, as mesmas entradas que o humano estava interpretando. A interpretação, a parte que fecha a decisão, ainda não está na resposta. Estava na cabeça do operador.

Então, o agente está preso no mesmo lugar em que o humano estava, exceto pior, porque ele não pode nem fazer a correspondência intuitiva que um engenheiro cansado faz à primeira vista.

O que o veredicto tinha que se tornar

A solução não era um novo painel. Era fazer do veredicto um objeto estruturado em vez de uma mensagem.

Um humano lendo o veredicto quer uma frase: a API de checkout parece boa, siga em frente. Um agente lendo o mesmo veredicto quer campos nos quais pode ramificar: veredicto: OBSERVAR, um nível_decisório, as apis_afetadas, uma ação_recomendada, e os passos_do_operador a seguir.

Mesmo veredicto. Duas codificações dele. O estado diz a um humano o que aconteceu e diz a um agente qual ramificação tomar. Os metadados dizem a um humano o que olhar e dizem a um agente o que fazer a seguir ou quando re-verificar. Uma vez que o veredicto carregasse ambos, nenhum leitor precisaria traduzir para o outro.

Essa é a mudança que importava. Não adicionar um recurso — mudar o que um veredicto é. Ele parou de ser uma coisa renderizada para uma pessoa e se tornou uma coisa que dois tipos de leitores poderiam consumir da mesma fonte de verdade.

Por que uma superfície de leitura, e por que MCP

Um veredicto estruturado ainda precisa de uma porta pela qual o segundo leitor possa passar.

Um endpoint REST simples é o óbvio, e funciona. Um agente pode chamar GET no veredicto mais recente e ler os campos. Mas os tempos de execução do agente falam cada vez mais um protocolo mais específico para buscar contexto e chamar ferramentas, e para esses tempos de execução, o MCP é a porta nativa. Assim, ao lado da superfície REST, há um servidor MCP que o agente pode consultar da mesma forma que consulta qualquer outra ferramenta. Pergunte pelo veredicto mais recente, receba de volta o objeto estruturado, ramifique sobre ele.

Na prática, isso se parece com uma chamada no pipeline. O agente termina o deploy, pede o veredicto mais recente, lê o estado e decide. Uma chamada get_verdict em vez de uma captura de tela que ninguém abriu.

Eu quero ter cuidado sobre o que isso é e o que não é. O servidor MCP é uma porta, não o produto. O trabalho da camada de veredicto é ler sinais de deploy e decidir ESTÁVEL, OBSERVAR ou RISCO. O MCP é apenas uma das maneiras pelas quais a resposta é entregue a um leitor que não tem olhos. No momento em que você deixa a porta se tornar a identidade da coisa, você começa a construir uma "ferramenta de IA" e para de construir a camada de verificação que era o ponto real.

Uma superfície de leitura não é uma superfície de controle

Aqui está o limite que impede isso de dar errado.

O agente lendo o veredicto é um consumidor da decisão, não uma coisa que o veredicto controla. Relivio produz o veredicto. Ele não decide o que acontece a seguir. O agente, ou a política que a equipe escreveu para ele, lê ESTÁVEL e continua, lê RISCO e pausa, lê OBSERVAR e re-verifica em alguns minutos. Essa política pertence à equipe, não à camada de veredicto.

Eu aprendi isso da maneira difícil em uma versão anterior, onde a camada de veredicto ultrapassou essa linha e tentou controlar os deploys. Isso erodiu silenciosamente a confiança, porque uma vez que uma camada tanto julga quanto age, você não pode dizer qual chapéu ela está usando quando algo dá errado. Expor o veredicto como uma superfície de leitura mantém os chapéus separados de propósito. O veredicto é legível. O que fazer sobre isso permanece sob a responsabilidade de quem possui o deploy.

Assim, a superfície MCP é deliberadamente somente leitura em espírito. Um agente puxa um veredicto. Ele não é informado pela Relivio sobre o que fazer, e a Relivio não pode conduzir o rollout pela porta dos fundos de "o agente leu RISCO, então eu pausei". O agente o pausou. A política da equipe disse para fazê-lo. O veredicto era apenas a entrada.

O que pode dar errado

Alguns modos de falha aparecem uma vez que um veredicto tem um leitor de máquina.

O veredicto é lido como um comando. Um agente lendo RISCO e parando abruptamente toda vez, sem uma camada de política entre eles, transforma um julgamento em um portão automático. Essa é a falha de acoplamento novamente, apenas realocada no agente. O veredicto deve ser uma entrada para uma política, não um gatilho conectado diretamente a uma ação.

A superfície de leitura cresce verbos de escrita. É tentador adicionar "e também permitir que o agente reconheça, ou adie, ou sobrescreva o veredicto através da mesma superfície." Cada um desses é um verbo de controle se infiltrando em uma superfície de leitura. Uma vez que eles estão lá, a camada volta a possuir decisões que não deveria.

O protocolo se torna o posicionamento. Como o MCP está em alta, é fácil começar a descrever toda a coisa como um servidor MCP. Então as pessoas o classificam como "ferramentas de agente" e perdem que o valor é o veredicto, que é tão útil lido por um humano através de uma chamada REST ou uma mensagem no Slack. O protocolo é encanamento. O julgamento é o produto.

Nenhuma dessas falhas é barulhenta. Cada uma delas move silenciosamente a camada de volta para ser algo que estava tentando não ser.

Onde isso deixa

A camada de veredicto agora tem dois leitores que atende de propósito. Um humano lê uma mensagem curta e segue em frente. Um agente ou fluxo de trabalho puxa o objeto estruturado, através de REST ou através do MCP quando o tempo de execução fala isso, e ramifica.