Chat é a interface errada para agentes de IA

Chat é uma boa primitiva de entrada, mas um ambiente operacional ruim para agentes. Quando o software age ao longo do tempo — mantendo estado, chamando ferramentas, tomando decisões, falhando e se recuperando — a interface precisa mudar de conversação para operações. Os seis padrões de interface abaixo definem o que superfícies de controle de agentes realmente exigem.

A maioria dos agentes de IA é distribuída como janelas de chat. Claude Code é uma conversa no terminal. Cursor é uma conversa no editor. Codex roda conversas na nuvem. Devin envolve uma conversa ao redor de um navegador, terminal e editor. O enquadramento conversacional é tão dominante que “conversar com a IA” se tornou sinônimo de “usar a IA.” A metáfora fazia sentido quando o modelo de interação era prompt-resposta: você pergunta, ela responde, você avalia. Um turno. Dois turnos. Talvez dez.

A metáfora quebra no momento em que agentes operam de forma autônoma.

Meu loop Ralph roda Claude Code durante a noite. Contexto fresco por iteração, memória no sistema de arquivos entre sessões, hooks de parada que previnem encerramento prematuro. Uma única execução noturna produz de 8 a 15 iterações, cada uma com uma janela de contexto completa de 200K tokens. O sistema entregou 3.455 linhas de Python em produção ao longo de múltiplas sessões não supervisionadas.¹ Supervisionar essas sessões através de um transcript de chat rolável exigiria ler milhares de linhas intercaladas de chamadas de ferramentas, diffs de arquivos e traços de raciocínio. Ninguém faz isso. Ninguém consegue fazer isso. A interface de chat colapsa sob o peso da operação autônoma.

Profissionais estão aprendendo que a metáfora do chat está errada. O Codex da OpenAI roda headless na nuvem e retorna trabalho concluído. As Claude Routines da Anthropic executam workflows de múltiplas etapas com sessões revisáveis. O Devin divide a tela em navegador, terminal, editor e chat. Cada produto se afasta da conversa pura em direção a algo mais operacional. Nenhum chegou à solução completa. A lacuna entre “chat com diffs de arquivo” e “dashboard de operações de agentes” continua sendo o maior problema de UX não resolvido em ferramentas de IA.

Cinco maneiras pelas quais o chat falha para agentes

Sem linha do tempo de rastreamento

Uma sessão de agente de 90 minutos gera centenas de eventos: leituras de arquivo, escritas de arquivo, comandos bash, consultas de busca, spawns de sub-agentes, eventos de compactação e etapas de raciocínio. O chat apresenta esses eventos como um scroll linear de conversa. O formato torna impossível responder “o que aconteceu entre o minuto 30 e o minuto 45?” sem ler tudo que está no meio.

Meu sistema de hooks intercepta 15 tipos de eventos em cada chamada de ferramenta, produzindo telemetria estruturada que a interface de chat não exibe.² A telemetria existe. A visualização não. Quando depuro uma sessão noturna que falhou, eu faço grep em arquivos de log. Eu não rolo o chat.

Uma linha do tempo de rastreamento apresentaria eventos como uma sequência filtrável e com zoom. Mostre apenas as escritas de arquivo. Mostre apenas os comandos bash que modificaram o sistema de arquivos. Mostre os pontos de decisão onde o agente escolheu o caminho A em vez do B. Gravadores de dados de voo não apresentam eventos da cabine como um transcript de conversa. Interfaces de agentes também não deveriam.

Sem superfície de revisão de permissões

O modelo de permissões do Claude Code interrompe a conversa para solicitar aprovação. “Permitir este comando bash?” aparece inline com o raciocínio do agente, e o usuário precisa trocar de contexto — de ler análise para avaliar risco. O modelo de interrupção funciona para sessões interativas. Porém, ele falha completamente para operação autônoma, onde o agente precisa de aprovações em lote e permissões escalonadas por nível de risco.

Meus 95 hooks funcionam como uma camada programática de permissões. Comandos na lista de permissão passam silenciosamente. Padrões bloqueados interrompem a execução. Os hooks resolvem o problema de automação, mas resolvem com código, não com interface.³ Uma UI de gate de permissão apresentaria aprovações pendentes em uma fila, ordenadas por nível de risco, com aprovação ou negação em um clique. Operações de alto risco (force pushes, deploys em produção, comandos destrutivos) apareceriam de forma diferente de operações de baixo risco (leituras de arquivo, consultas de busca). A interface comunicaria o risco antes de o usuário avaliar o conteúdo.

Sem navegador de memória

A compactação de contexto apaga o que o agente sabia. A janela de 200K tokens enche, o sistema resume turnos anteriores e a informação desaparece. Minhas medições ao longo de 50 sessões mostraram que a qualidade do output degrada por volta de 60% de utilização do contexto, muito antes do limite rígido acionar a compactação.⁴ A pesquisa sobre degradação de memória da Microsoft Research e da Salesforce confirmou o problema estrutural: queda média de 39% na performance da interação de turno único para multi-turno em 15 LLMs e mais de 200.000 conversas simuladas.⁵

O usuário não tem visibilidade sobre o que sobreviveu à compactação e o que não sobreviveu. O agente esqueceu o contrato de API estabelecido 40 minutos atrás? O grafo de dependências do módulo sobreviveu ao último resumo? A interface de chat não fornece nenhuma maneira de responder a essas perguntas. Um navegador de memória mostraria o que o agente mantém atualmente no contexto, o que foi compactado, o que foi perdido e o que persiste na memória do sistema de arquivos. O padrão de sistema de arquivos como memória do loop Ralph compensa a perda por compactação, mas o operador ainda não consegue inspecionar a memória de trabalho do agente sem ler arquivos de estado brutos.

Sem medidor de orçamento de contexto

O consumo de tokens é invisível. O usuário não sabe se a janela de contexto está 40% cheia ou 90% cheia. O primeiro sinal de exaustão é a degradação do output: instruções esquecidas, sugestões repetidas, visão de túnel em um único arquivo onde o agente mantinha coerência em múltiplos arquivos minutos antes.⁴ Quando o usuário percebe, o dano à qualidade já se acumulou ao longo de vários turnos.

Um medidor de orçamento de contexto mostraria o uso de tokens em tempo real, a exaustão projetada com base na taxa de consumo atual da tarefa e o limite de compactação. O medidor funcionaria como um indicador de combustível: não o tipo de informação que você verifica a cada segundo, mas o tipo de informação que você precisa antes de se comprometer com uma operação longa. “Esta tarefa de refatoração vai consumir aproximadamente 80K tokens; seu orçamento restante é de 60K” muda o cálculo de decisão do usuário. Nenhuma interface de chat fornece essa informação.

Sem auditoria de chamadas de ferramentas

Agentes executam ferramentas com argumentos que o usuário nunca inspeciona. Um comando bash é executado. Um arquivo é escrito. Uma API é chamada. A interface de chat mostra o nome da ferramenta e às vezes o output. Os argumentos (as instruções reais que o agente enviou para a ferramenta) passam rolando em um formato que desencoraja a leitura.

O modo de falha não é hipotético. Um desenvolvedor relatou que o Claude Code deletou toda a configuração de produção, incluindo o banco de dados e 2,5 anos de snapshots.⁶ O agente executou comandos destrutivos sem prompt de confirmação e sem interceptação por hook. O incidente se deve a uma falha de interface: o usuário não conseguiu revisar eficientemente o que o agente estava prestes a fazer.

Uma superfície de auditoria de chamadas de ferramentas apresentaria cada invocação de ferramenta com seus argumentos completos, diffs antes/depois para operações de arquivo, e capacidades de rollback para ações destrutivas. O evidence gate aborda o problema de verificação na camada de output, exigindo que agentes citem caminhos de arquivo, resultados de testes e nomes de padrões antes de marcar o trabalho como concluído. Uma auditoria de chamadas de ferramentas aborda o mesmo problema na camada de execução, antes que o dano seja feito.

Seis padrões de interface para operações de agentes

O chat falha porque trata operações de agentes como conversa. Os seis padrões a seguir tratam operações de agentes como operações.

1. Linha do tempo de rastreamento

Um log cronológico de eventos com detalhes expansíveis em cada nó. Cada leitura de arquivo, escrita de arquivo, comando bash, chamada de API, spawn de sub-agente, evento de compactação e ponto de decisão aparece na linha do tempo. Os usuários filtram por tipo de evento, fazem zoom em intervalos de tempo e expandem eventos individuais para ver argumentos e outputs completos.

A linha do tempo resolve o problema do “o que aconteceu?” que a depuração post-hoc atualmente requer análise de arquivos de log para responder. O problema do agente invisível (agentes consumindo recursos sem visibilidade do operador) se torna visível quando cada ação aparece em uma linha do tempo filtrável com métricas de consumo de recursos anexadas.

2. UI de gate de permissão

Uma fila de aprovações pendentes, ordenadas por nível de risco. Operações destrutivas (deploys em produção, migrações de banco de dados, force pushes) são exibidas com bordas vermelhas e exigem confirmação explícita. Operações somente leitura (leituras de arquivo, consultas de busca) são auto-aprovadas ou aprovadas em lote. A superfície do gate mostra o comando completo, a avaliação de risco e o motivo declarado pelo agente para a ação.

A aprovação em lote transforma o modelo de interação. Em vez de interromper a conversa 47 vezes durante uma sessão noturna, o gate de permissão apresenta “aqui estão as 12 operações que excederam seu limite de auto-aprovação” em uma única superfície de revisão. O usuário processa todas as 12 em dois minutos em vez de trocar de contexto 12 vezes ao longo de seis horas.

3. Navegador de memória

Um display de três painéis: contexto ativo (o que o agente mantém atualmente), resumos compactados (o que foi resumido e quando) e memória do sistema de arquivos (o que persiste no disco entre sessões). Cada painel é pesquisável. Os usuários podem promover itens compactados de volta ao contexto ativo ou marcar memórias do sistema de arquivos como obsoletas.

O navegador torna o estado de conhecimento do agente inspecionável. Quando o agente produz output que contradiz uma decisão anterior, o operador pode verificar se a decisão anterior sobreviveu à compactação. O problema de degradação de memória do agente não desaparece com um navegador. O navegador torna a degradação visível, diagnosticável e parcialmente recuperável.

4. Medidor de orçamento de contexto

Um contador de tokens em tempo real mostrando a utilização atual, a exaustão projetada com base na taxa de consumo contínua e o limite de compactação. O medidor inclui um detalhamento: quantos tokens são prompt de sistema, quantos são histórico de conversa, quantos são outputs de ferramentas, quantos são conteúdo de arquivos. O detalhamento revela para onde o orçamento está indo. Frequentemente, outputs de ferramentas consomem 60-70% da janela.

O medidor muda o comportamento. Minhas práticas de gerenciamento de janela de contexto (compactação proativa, delegação a sub-agentes, memória baseada em sistema de arquivos) surgiram da medição do consumo de tokens ao longo de 50 sessões. Um medidor em tempo real torna essas mesmas medições disponíveis para todos os usuários em tempo real, transformando o gerenciamento de contexto de uma prática de especialista em uma restrição de recurso visível.

5. Revisão de chamadas de ferramentas

Uma superfície de inspeção para cada invocação de ferramenta. Operações de arquivo mostram diffs antes/depois. Comandos bash mostram o comando completo, o diretório de trabalho e o código de saída. Chamadas de API mostram payloads de request e response. Cada chamada de ferramenta inclui um botão de rollback que reverte a operação (para operações reversíveis) ou sinaliza a operação para revisão manual (para operações irreversíveis).

A superfície de revisão serve duplo propósito: supervisão em tempo real durante sessões interativas e auditoria post-hoc durante execuções autônomas. A camada de verificação da dark factory explora como sistemas autônomos lidam com verificação sem presença humana. A revisão de chamadas de ferramentas é o complemento com presença humana, fornecendo a superfície de inspeção que possibilita confiança informada em vez de confiança cega.

6. Fila de supervisão

Um dashboard multi-agente que exibe alertas prioritários em sessões concorrentes. Ao executar múltiplos agentes (um agente de refatoração, um agente de escrita de testes, um agente de documentação), a fila agrega seus status, destaca falhas e direciona decisões human-in-the-loop para uma única superfície.

A fila de supervisão importa porque o uso de agentes escala horizontalmente. Um desenvolvedor rodando um agente é uma conversa. Um desenvolvedor rodando cinco agentes em cinco tarefas é operações. A interface para operações é um dashboard, não cinco janelas de chat. A fila prioriza por urgência: um deploy em produção falhando aparece acima de uma questão de formatação de documentação.

O que existe hoje

Nenhum produto construiu o dashboard completo de operações. Vários construíram partes.

Claude Code fornece a camada programática mais forte. Hooks interceptam 15 tipos de eventos com decisões de permitir/negar/modificar. O comando /cost mostra o uso de tokens da sessão. O sistema de contexto CLAUDE.md fornece memória no sistema de arquivos. Contudo, a superfície é um terminal. Sem linha do tempo visual. Sem fila de permissões. Sem navegador de memória. A infraestrutura existe sem a interface.⁷

Cursor construiu diffs inline, uma revisão primitiva de chamadas de ferramentas para operações de arquivo. A superfície de diff mostra o estado antes/depois e suporta aceitar/rejeitar no nível de chunk. O padrão está correto, porém é limitado: diffs cobrem escritas de arquivo, mas não comandos bash, chamadas de API ou coordenação de sub-agentes.

Devin é o que mais se aproxima de uma UI de operações. O produto divide a tela em navegador, terminal, editor e chat: quatro superfícies que tornam diferentes aspectos do comportamento do agente visíveis simultaneamente. O layout em painéis reconhece que a conversa sozinha é insuficiente. Por outro lado, os painéis são apresentação, não superfícies de controle. O usuário assiste o agente trabalhar. O usuário não enfileira aprovações, inspeciona o estado da memória ou audita argumentos de ferramentas através desses painéis.⁸

Claude Routines (lançado em abril de 2026) executam workflows de múltiplas etapas em background, e cada execução cria uma sessão revisável do Claude Code. A superfície de revisão é uma linha do tempo de rastreamento: os usuários podem revisar o que o agente fez após o fato. O padrão valida o argumento central: execução em background requer uma superfície de revisão que não seja a conversa original.⁹

OpenAI Codex roda headless na nuvem e retorna diffs. O modelo de isolamento (ambiente sandboxed por tarefa) elimina algumas preocupações de permissão, mas introduz outras: o usuário abre mão de toda supervisão em tempo real em troca de segurança sandboxed. Sem linha do tempo dedicada de operações ou superfície de controle mid-run. A troca revela a tensão de design: autonomia total ou supervisão total, sem nada entre os dois.¹⁰

A lacuna entre essas soluções parciais e uma interface completa de operações de agentes define a próxima fronteira competitiva em ferramentas de IA.

Interfaces de agentes são um problema de design

Os padrões de interface acima são especificações de engenharia. Construí-los requer julgamento de design que especificações de engenharia sozinhas não conseguem fornecer.

Como um gate de permissão comunica risco? Cor sozinha é insuficiente: vermelho significa “perigoso” em contextos ocidentais e “prosperidade” em contextos chineses. Escolha de ícone, posicionamento espacial, timing de animação e tom do texto contribuem para a avaliação de risco do usuário. Um gate de permissão que tecnicamente exibe a informação correta, mas a comunica mal, vai treinar os usuários a clicar em “aprovar” sem ler. O gate se torna teatro.

Como um medidor de orçamento de contexto comunica urgência sem induzir ansiedade? Um medidor que fica vermelho a 80% de utilização pode causar compactação prematura. Um medidor que permanece verde até 95% pode causar exaustão surpresa. As curvas de limite, as transições de cor e o timing das notificações são decisões de gosto com consequências operacionais.

Como uma linha do tempo de rastreamento lida com densidade de informação sem sobrecarregar o usuário? Uma sessão autônoma de 12 horas gera milhares de eventos. Mostrar todos os eventos produz ruído. Filtrar para eventos “importantes” exige que a interface defina importância — um julgamento que varia por usuário, tarefa e modo de falha.

Essas são as mesmas perguntas que Dieter Rams respondeu para eletrônicos de consumo e que Kenya Hara respondeu para design de informação. As perguntas não são novas. O domínio é. Gosto é um sistema técnico: restrições, critérios de avaliação, reconhecimento de padrões e verificações de coerência que se decompõem em infraestrutura de engenharia. O design de interfaces de agentes requer infraestrutura de gosto construída especificamente para UX operacional: a capacidade de comunicar risco, confiança, incerteza e estado de recursos através de superfícies visuais que suportam tomada de decisão rápida sob pressão de tempo.

A empresa que tratar interfaces de agentes como um problema de design — e não apenas uma lista de funcionalidades — construirá a interface em que operadores confiam para cargas de trabalho em produção. A empresa que tratar interfaces de agentes como um problema apenas de engenharia construirá um dashboard que é tecnicamente completo e operacionalmente inutilizável.

O próximo fosso competitivo

O modelo não é o fosso. Modelos de fronteira convergem em benchmarks de capacidade a cada trimestre. Fine-tuning e RLHF produzem diferenciação significativa, porém temporária. A camada de modelo é uma corrida por commodities com retornos decrescentes em vantagem competitiva.¹¹

A camada de contexto também não é o fosso. Janelas de contexto crescem de 128K para 200K para 1M tokens. Todo provedor acompanha em meses. Contexto mais longo melhora a capacidade, mas não diferencia produtos.

A superfície de controle é o fosso. A interface que torna operações autônomas de agentes visíveis, auditáveis e governáveis — essa superfície determina qual produto as empresas confiam para cargas de trabalho em produção. A adoção enterprise exige responder perguntas que interfaces de chat não conseguem: O que o agente fez? Por que o agente fez isso? Que permissões o agente exerceu? Que recursos o agente consumiu? Posso reverter as ações do agente? Posso provar a um auditor o que o agente fez?

Essas perguntas não são perguntas de prompting. São perguntas de operações. O produto que as responder vence o mercado que importa.

Meus 95 hooks são uma resposta programática a essas perguntas, construídos a partir do terminal, aplicados através de shell scripts, mantidos através de arquivos de configuração. Os hooks funcionam. Os hooks também representam o estado da arte: infraestrutura de nível especialista que nenhum usuário não-especialista vai replicar. O evidence gate verifica o output do agente. As camadas de observabilidade do agente invisível monitoram o comportamento do agente. As práticas de gerenciamento de janela de contexto mantêm a qualidade da sessão. Cada sistema aborda uma necessidade operacional real. Cada sistema existe como código, não como interface.

O próximo passo é óbvio. Transformar o código em superfícies de controle. Transformar os hooks em um gate de permissão. Transformar a telemetria em uma linha do tempo de rastreamento. Transformar as medições de tokens em um medidor de orçamento. Transformar a memória do sistema de arquivos em um estado de conhecimento navegável. Transformar o evidence gate em uma superfície de revisão de chamadas de ferramentas.

A infraestrutura já existe. A interface não. Construir a interface é um problema de design, um problema de engenharia e um problema de gosto. A equipe que resolver os três entrega o produto que define a próxima era da engenharia de IA.

FAQ

Por que não simplesmente melhorar o chat com formatação melhor?

Formatação melhor trata o sintoma. O problema é estrutural: chat é um meio sequencial e apenas-adição. Operações de agentes exigem inspeção de acesso aleatório (saltar para qualquer evento), visualizações concorrentes (ver o estado da memória ao lado de chamadas de ferramentas) e interação em lote (aprovar cinco operações de uma vez). Melhorias de formatação dentro do chat (seções recolhíveis, syntax highlighting, diffs inline) ajudam marginalmente, mas não conseguem fornecer acesso aleatório, visualizações concorrentes ou interação em lote dentro de um transcript rolável.

Gates de permissão podem substituir o julgamento humano?

Gates de permissão aumentam o julgamento ao apresentar decisões em um formato otimizado para avaliação rápida e precisa. O gate não decide. O gate exibe a decisão com contexto: o comando completo, o nível de risco, o raciocínio do agente e o impacto potencial. O humano decide mais rápido e com mais precisão porque a interface reduz a carga cognitiva de extrair a informação relevante de um scroll de conversa.

Como esses padrões se aplicam a agentes que não são de código?

Todo padrão se generaliza. Um agente de atendimento ao cliente precisa de uma linha do tempo de rastreamento (o que o agente disse ao cliente?), um gate de permissão (o agente pode emitir um reembolso acima de $500?) e uma auditoria de chamadas de ferramentas (que consultas ao banco de dados o agente executou?). Um agente de pesquisa precisa de um navegador de memória (que fontes o agente consultou?) e um medidor de orçamento de contexto (quanta capacidade de retrieval resta?). Os padrões são agnósticos de domínio porque os desafios operacionais (visibilidade, permissão, memória, recursos, auditoria, supervisão) são universais para software autônomo.

Fontes