← Todos os Posts

Agentes precisam de superfícies de supervisão

A OpenAI agora descreve o aplicativo Codex como um centro de comando para gerenciar vários agentes, executar trabalhos em paralelo e supervisionar equipes coordenadas ao longo do ciclo de vida do software.1 Essa direção de produto confirma a mudança de interface: o problema difícil deixou de ser “o agente consegue agir?” e passou a ser “o humano consegue supervisionar a ação em escala?”

Agentes precisam de superfícies de supervisão: lugares onde uma pessoa consegue ver o estado, revisar riscos, aprovar ferramentas sensíveis, inspecionar rastreamentos, recuperar falhas e validar o resultado com evidências. Um chat melhor ajuda na expressão. Superfícies de supervisão governam o trabalho.

Resumo rápido

O chat continua útil para registrar intenção. Ele falha como única superfície para trabalho autônomo porque as execuções de agentes incluem chamadas de ferramentas, permissões, rastreamentos, memória, caminhos que falharam e alegações de conclusão. A documentação do Codex cloud da OpenAI descreve tarefas em segundo plano em ambientes isolados, monitoramento de progresso em tempo real, citações de logs de terminal e evidências de saídas de testes.2 O Agents SDK da OpenAI expõe aprovações com humano no processo e rastreamento integrado para chamadas de ferramentas, transferências, proteções e eventos personalizados.34 Os hooks do Claude Code da Anthropic expõem pontos do ciclo de vida como PreToolUse, PostToolUse, PermissionRequest e Stop.5

A lição de produto: supervisão não é um modal no fim. É um conjunto de superfícies que acompanham o agente enquanto o trabalho acontece.

Principais conclusões

Para equipes de produto de agentes: - Crie uma fila de supervisão antes de adicionar mais um polimento ao chat. A fila deve mostrar execuções bloqueadas, ações arriscadas, evidências vencidas, verificações com falha e artefatos prontos para revisão. - Trate aprovações, rastreamentos e recuperação como UX principal. O usuário não deve reconstruir o estado das ferramentas a partir de uma transcrição.

Para engenheiros de design: - Dê um nível de visibilidade a cada ação do agente: silenciosa, resumida, interruptiva ou bloqueada. Trabalho somente leitura não deve parecer uma alteração em produção. - Projete o objeto de revisão, não só a mensagem. Um objeto de revisão contém a carga útil da ferramenta, o motivo do risco, o diff, as evidências e a próxima ação.

Para equipes que estão adotando agentes de programação: - Meça se um operador consegue responder: o que está em execução, o que está aguardando, o que mudou, o que falhou, o que precisa de aprovação e o que continua sem verificação. - Use o chat para delegação. Use superfícies de supervisão para responsabilidade.

O que é uma superfície de supervisão?

Uma superfície de supervisão é uma interface de usuário para trabalho responsável de agentes.

Ela não tenta mostrar cada token. Ela mostra as partes que determinam se o agente deve continuar:

Superfície Pergunta do usuário
Fila de execuções Quais agentes precisam de atenção?
Painel de estado Em que fase está cada execução?
Fila de aprovações Quais chamadas de ferramentas precisam de decisão humana?
Linha do tempo de rastreamento O que aconteceu, e em que ordem?
Painel de evidências O que comprova o resultado?
Controles de recuperação Como pausar, retomar, tentar de novo, bifurcar ou reverter?
Pacote de revisão O que posso aprovar, rejeitar ou devolver?

A diferença em relação ao chat é o acesso direto. O chat diz “leia a rolagem”. Uma superfície de supervisão diz “inspecione a parte arriscada e decida”.

Isso importa quando uma pessoa executa vários agentes. Um único agente pode continuar conversacional por um tempo. Cinco agentes de longa duração viram operações. A interface precisa priorizar, resumir e direcionar a atenção.

Por que o chat falha como superfície operacional?

O chat falha porque tem o formato errado para trabalho em movimento.

O trabalho de agentes produz eventos: planos, buscas, leituras de arquivos, escritas em arquivos, comandos de shell, ações no navegador, chamadas de API, execuções de testes, caminhos rejeitados, novas tentativas que falharam e evidências finais. Uma transcrição pode conter esses eventos, mas não consegue organizá-los por risco, fase ou responsabilidade.

O anúncio do aplicativo Codex da OpenAI nomeia essa mudança diretamente. Desenvolvedores agora delegam trabalho, executam tarefas em paralelo e supervisionam agentes entre projetos; as superfícies antigas de IDE e terminal não servem bem para esse modo.1 Essa formulação importa porque supervisão exige outro layout, diferente de criar prompts. O operador precisa de um quadro, não de uma rolagem.

As diretrizes de interação humano-IA da Microsoft, de 2019, ainda oferecem a base de design: sistemas de IA devem comunicar status, apoiar correção e lidar com falhas ao longo do tempo de interação.6 Agentes tornam essas diretrizes antigas operacionais. Status agora significa “qual chamada de ferramenta está pendente?”. Correção agora significa “rejeite e retome esta execução”. Falha agora significa “mostre o comando que falhou, a suposição que mudou e o caminho de reparo”.

O erro é tratar supervisão como atrito. Supervisão ruim adiciona atrito. Supervisão boa reduz carga cognitiva porque coloca a decisão no lugar certo.

O que a fila de execuções deve mostrar?

A fila de execuções deve mostrar atenção, não atividade.

Um feed de atividades conta ao usuário tudo o que aconteceu. Uma fila de supervisão mostra o que exige julgamento. A fila pode comprimir a maioria dos eventos em alguns estados:

Estado da execução O que o operador precisa
Planejando Objetivo, escopo, ferramentas prováveis, critérios de aceitação
Agindo Ferramenta atual, alvo, efeito colateral esperado
Aguardando Aprovação, credencial, informação faltante, bloqueio externo
Verificando Comando de teste, checagem de fonte, rota renderizada, barreira de revisão
Reparando Verificação com falha, hipótese alterada, próxima tentativa
Pronta para revisão Artefato, diff, evidências, lacunas não resolvidas
Bloqueada Motivo, responsável, opção de reinício

A documentação do Codex cloud da OpenAI descreve tarefas que podem rodar em segundo plano, inclusive em paralelo, dentro de seus próprios ambientes na nuvem.2 Trabalho paralelo em segundo plano muda o modelo de atenção. O usuário não deve ficar consultando cada execução. O sistema deve encaminhar trabalhos bloqueados, arriscados e prontos para revisão para um só lugar.

A fila deve evitar falsa urgência. Uma falha de lint em um branch de rascunho e uma divergência em um deploy de produção não merecem o mesmo peso visual. A interface deve reservar interrupções para ações irreversíveis, lançamentos públicos, operações sensíveis de segurança e decisões em que o agente não tem contexto suficiente para continuar com responsabilidade.

Como as aprovações devem funcionar?

Aprovações devem funcionar como uma fila de objetos de revisão, não como uma sequência de interrupções modais.

O fluxo com humano no processo do Agents SDK da OpenAI pausa a execução até que uma pessoa aprove ou rejeite chamadas de ferramentas sensíveis. A documentação descreve aprovações pendentes como interruptions, com RunState usado para serializar e retomar após as decisões.3 A mesma página observa que a aprovação se aplica a ferramentas de agente aninhadas e ferramentas MCP, não apenas ao agente de nível superior atual.3

A documentação de hooks do Claude Code da Anthropic expõe o mesmo formato de design por outro ângulo. PreToolUse roda antes de uma chamada de ferramenta e pode bloqueá-la. PermissionRequest dispara quando uma caixa de diálogo de permissão aparece. PostToolUse e PostToolUseFailure disparam depois de ferramentas bem-sucedidas ou com falha, e Stop dispara quando o Claude termina de responder.5

Esses primitivos apontam para a superfície certa:

Campo de aprovação Por que pertence à UI
Nome da ferramenta Identifica a classe de capacidade
Argumentos Mostra o que o agente quer fazer
Alvo Nomeia arquivo, banco de dados, host, rota, conta ou branch
Nível de risco Define peso visual e procedural
Motivo do agente Explica por que a chamada pertence ao plano
Efeito colateral esperado Separa leitura, escrita, rede, deploy, gasto ou exclusão
Decisão Aprovar uma vez, sempre aprovar, rejeitar, adiar, reescrever

A superfície de aprovação certa deixa leituras de baixo risco passarem em silêncio, agrupa decisões de risco médio e interrompe para mudanças de alto risco. O usuário não deve aprovar um comando de shell enquanto lê um parágrafo. O usuário deve aprovar uma operação tipada com contexto suficiente para continuar responsável.

O que uma superfície de rastreamento deve provar?

Uma superfície de rastreamento deve provar sequência, causa e consequência.

A documentação de rastreamento do Agents SDK da OpenAI diz que o rastreamento registra uma execução entre gerações de LLM, chamadas de ferramentas, transferências, proteções e eventos personalizados, e depois apoia depuração, visualização e monitoramento em desenvolvimento e produção.4 Essa descrição transforma o rastreamento em um primitivo de produto, não apenas em instrumentação para desenvolvedores.

O rastreamento de supervisão deve responder a cinco perguntas:

Pergunta Detalhe necessário no rastreamento
O que o agente viu? Arquivos, fontes, prompts, contexto recuperado
O que ele fez? Chamadas de ferramentas, argumentos, saídas, estados de saída
O que mudou? Diffs, artefatos gerados, estado externo
Por que ele mudou de direção? Verificações com falha, permissões negadas, novas evidências
O que comprova a conclusão? Comandos, links de fontes, rotas ativas, status de revisão

O rastreamento não precisa de raciocínio privado. Ele precisa de evidência operacional. Um usuário não precisa de chain-of-thought oculta para avaliar um lançamento. O usuário precisa da saída do comando, status da rota, estado do cache, linhas do D1, barreira de tradução, checagens de fonte e lacuna restante de revisão nativa.

Essa distinção protege confiança e critério. Mostrar detalhes internos demais transforma a interface em ruído. Mostrar de menos transforma o produto em teatro.

Como a recuperação deve entrar no fluxo?

A recuperação pertence ao lado do evento que falhou.

Sistemas de agentes falham o tempo todo no trabalho normal: um comando de instalação expira, um formatador altera arquivos não relacionados, um smoke test no navegador encontra um cache antigo, uma barreira de tradução rejeita um locale ou um link de fonte retorna 403 para um script. Uma boa superfície de supervisão trata esses momentos como estados esperados.

Os controles de recuperação devem permanecer concretos:

Controle Uso responsável
Pausar Interromper novos efeitos colaterais preservando o estado
Retomar Continuar após aprovação ou correção externa
Tentar de novo Repetir uma etapa com falha usando entrada alterada
Bifurcar Explorar um plano alternativo sem sobrescrever o primeiro
Reverter Desfazer mudanças locais reversíveis
Escalar Pedir revisão a um humano ou outro agente
Fechar com lacuna Finalizar apenas com trabalho não resolvido explícito

O anúncio do aplicativo Codex da OpenAI descreve agentes trabalhando em cópias isoladas do código, para que usuários possam explorar caminhos diferentes e fazer checkout das mudanças localmente enquanto um agente continua.1 Esse isolamento ajuda na recuperação, mas a interface ainda precisa mostrar qual caminho venceu, qual caminho falhou e qual trabalho continua inseguro para merge.

O produto nunca deve fazer o usuário reconstruir a recuperação a partir de logs brutos. A etapa que falhou já conhece seu comando, diretório de trabalho, saída e alvo. A superfície deve colocar a próxima ação responsável naquele evento.

O que torna uma superfície de supervisão digna?

Uma superfície de supervisão se torna digna quando reduz trabalho sem reduzir responsabilidade.

A versão fácil adiciona mais painéis. A versão digna remove dúvida. O usuário deve obter respostas mais rápidas para as perguntas que importam:

  • Qual execução precisa de mim?
  • Qual ação pode causar dano?
  • Qual resultado tem prova?
  • Qual resultado tem apenas prosa?
  • Qual branch deve sobreviver?
  • Qual lacuna continua sem solução?

O AI Risk Management Framework do NIST enquadra confiabilidade como algo que as equipes incorporam ao design, desenvolvimento, uso e avaliação de produtos e sistemas de IA.7 Superfícies de supervisão vivem exatamente nessa interseção. Elas fazem o design carregar risco operacional. Fazem o uso produzir evidências. Fazem a avaliação ficar visível antes de o usuário aprovar.

O MCP amplia a mesma responsabilidade. O Model Context Protocol conecta aplicações de IA a fontes externas de dados, ferramentas e fluxos de trabalho, para que agentes acessem informações e executem tarefas.8 Mais ferramentas conectadas significam uma superfície de ação maior. Superfícies de ação maiores exigem melhor supervisão, não mais fé.

O padrão de design deve continuar simples: um produto de agentes não deve maximizar movimento autônomo. Deve maximizar progresso responsável.

Como começar a criar uma?

Comece pela menor superfície de supervisão útil:

  1. Lista de execuções: uma linha por agente ativo, com fase, idade, bloqueio e próxima decisão.
  2. Fila de aprovações: um objeto por chamada de ferramenta sensível, com argumentos, alvo, risco e controles para aprovar/rejeitar/adiar.
  3. Tabela de rastreamento: uma linha por evento significativo, filtrável por leitura, escrita, shell, navegador, fonte, teste, deploy e revisão.
  4. Painel de evidências: uma tabela de alegação para prova para o resultado final.
  5. Menu de recuperação: pausar, retomar, tentar de novo, bifurcar e fechar com lacuna a partir do evento que falhou.

A primeira versão pode parecer sem graça. Tabelas, filtros, marcadores e linhas expansíveis vencem uma transcrição elegante que esconde risco. O problema de critério vem depois que a arquitetura da informação fica honesta: reduza ruído, reserve cores de alerta, agrupe eventos de baixo risco, exponha cargas úteis de alto risco e mantenha a aprovação final vinculada a provas.

Design agêntico é design de superfície de controle. A interface do agente é a camada operacional. HTML pode preservar informações espaciais que o Markdown descarta. Superfícies de supervisão combinam esses enquadramentos: elas transformam trabalho autônomo em operações inspecionáveis, espaciais e responsáveis.

Resumo final

Agentes não precisam tanto de uma transcrição melhor quanto precisam de superfícies de supervisão. Uma interface séria de agentes precisa de uma fila de execuções, uma fila de aprovações, uma linha do tempo de rastreamento, um painel de evidências e controles de recuperação. A documentação da OpenAI, da Anthropic, da Microsoft, do NIST e do MCP aponta para o mesmo formato de produto: sistemas autônomos precisam de status visível, governança de ferramentas, rastreamentos revisáveis e decisões humanas no nível certo de visibilidade.1345678

O chat pode continuar como a faixa de delegação. A supervisão precisa se tornar a superfície de trabalho.

FAQ

O que é uma superfície de supervisão de agentes?

Uma superfície de supervisão de agentes é uma UI para monitorar e controlar trabalho autônomo de agentes. Ela mostra estado da execução, aprovações pendentes, rastreamentos de ferramentas, evidências, falhas e controles de recuperação. O chat coleta intenção. Uma superfície de supervisão ajuda o operador a decidir o que o agente pode fazer em seguida e se o resultado merece aprovação.

Por que o chat não basta para agentes de IA?

O chat é sequencial e só cresce por acréscimo. Trabalho de agentes precisa de acesso direto a estado, risco, aprovações, rastreamentos, diffs, saída de testes e lacunas não resolvidas. Uma transcrição pode registrar esses eventos, mas não consegue priorizá-los por risco nem direcionar a atenção humana entre agentes paralelos.

O que as equipes devem construir primeiro?

As equipes devem construir primeiro uma fila de execuções e uma fila de aprovações. Essas duas superfícies revelam imediatamente trabalho bloqueado e ações sensíveis. Depois, adicione uma tabela de rastreamento, porque evidências, recuperação e revisão final dependem do registro de eventos.

Como uma superfície de supervisão é diferente de observabilidade?

Observabilidade ajuda criadores a depurar o sistema. Supervisão ajuda operadores a governar o trabalho enquanto ele acontece. As duas compartilham dados, mas atendem usuários diferentes. Um rastreamento de produção pode alimentar tanto uma visão de depuração para desenvolvedores quanto uma superfície de aprovação humana.

Todo agente precisa de aprovação humana?

Não. Todo agente precisa de supervisão calibrada. Leituras de baixo risco podem rodar em silêncio. Mudanças de risco médio podem ser agrupadas para revisão. Ações de alto risco devem pausar para aprovação. Lançamentos públicos, comandos destrutivos, ações que afetam clientes e movimentação de dinheiro merecem barreiras mais fortes.


Referências


  1. OpenAI, “Introducing the Codex app,” OpenAI, 2 de fevereiro de 2026, atualizado em 4 de março de 2026. Fonte para o aplicativo Codex como centro de comando multiagente, fluxos de trabalho paralelos de agentes, cópias isoladas de código, skills, Automations, filas de revisão, sandboxing, solicitações de permissão e enquadramento de supervisão. 

  2. OpenAI, “Codex web,” OpenAI Developers. Fonte para o Codex como agente de programação que pode ler, editar e executar código em tarefas em segundo plano na nuvem, incluindo trabalho paralelo em seu próprio ambiente na nuvem. 

  3. OpenAI, “Human-in-the-loop,” Agents SDK da OpenAI. Fonte para fluxos de aprovação que pausam a execução, retornam aprovações pendentes como interrupções, serializam e retomam RunState, e dão suporte a aprovações entre function tools, shell tools, apply-patch tools, servidores MCP, ferramentas MCP hospedadas e ferramentas de agentes aninhadas. 

  4. OpenAI, “Tracing,” Agents SDK da OpenAI. Fonte para rastreamento integrado de gerações de LLM, chamadas de ferramentas, transferências, proteções, eventos personalizados, traces, spans e monitoramento em desenvolvimento ou produção. 

  5. Anthropic, “Hooks reference,” Docs do Claude Code. Fonte para hooks de ciclo de vida do Claude Code, incluindo PreToolUse, PermissionRequest, PostToolUse, PostToolUseFailure, PostToolBatch, eventos de subagente e Stop

  6. Saleema Amershi et al., “Guidelines for Human-AI Interaction,” Microsoft Research, CHI 2019. Fonte para as 18 diretrizes de interação humano-IA geralmente aplicáveis e o estudo de validação com 49 profissionais. 

  7. National Institute of Standards and Technology, “AI Risk Management Framework,” NIST. Fonte para incorporar considerações de confiabilidade ao design, desenvolvimento, uso e avaliação de produtos, serviços e sistemas de IA. 

  8. Model Context Protocol, “What is the Model Context Protocol?” Fonte para o MCP como padrão open-source que conecta aplicações de IA a sistemas externos, incluindo arquivos locais, bancos de dados, ferramentas e fluxos de trabalho. 

Artigos relacionados

A interface do agente é a estrutura de execução

O design da interface de agentes é a camada operacional: permissões, memória, rastreamentos, evidências, recuperação e j…

11 min de leitura

Design agêntico é design de superfície de controle

Design agêntico não é uma caixa de chat mais bonita. É a superfície de controle que torna o software autônomo visível, i…

12 min de leitura

O Ralph Loop: Como Executo Agentes de IA Autônomos Durante a Noite

Construí um sistema de agentes autônomos com stop hooks, orçamentos de spawn e memória em sistema de arquivos. Aqui estã…

7 min de leitura