Design agêntico é design de superfície de controle
A maior parte do trabalho de interface para IA ainda trata o agente como uma caixa de texto mais inteligente. O design agêntico parte de outra premissa: quando um software pode agir ao longo do tempo, chamar ferramentas, mexer em arquivos, gastar dinheiro ou alterar o estado de produção, o problema de design passa a ser um problema de superfície de controle.
Design agêntico é a disciplina de tornar o software autônomo visível, interrompível, inspecionável, reversível e digno de confiança. O produto não é a transcrição do chat. O produto é a superfície que permite que uma pessoa entenda o que o agente está fazendo, decida o que ele pode fazer em seguida e verifique o que ele já fez.
Esse enquadramento importa porque agentes não falham como formulários, dashboards ou copilotos comuns. Um formulário falha no envio. Um dashboard falha ao mostrar dados desatualizados. Um copiloto falha ao sugerir um texto ruim. Um agente falha em movimento: toma o caminho errado, escolhe a ferramenta errada, perde a evidência certa, perde contexto, exagera nas permissões, para cedo demais ou acerta localmente enquanto enfraquece o produto como um todo.
O design precisa sair do polimento de prompts e ir para o controle operacional.
Resumo rápido
Design agêntico não é “UX para IA” em abstrato. É o design de superfícies de controle para sistemas que agem. A Microsoft já tratava a interação humano-IA como um problema próprio de design de interface anos antes dos agentes de código atuais, e o Google PAIR mantém esse mesmo fio centrado nas pessoas em suas orientações de design para IA.12 Os produtos modernos de agentes tornam essa necessidade mais evidente: a OpenAI descreve o Codex como um agente em nuvem que trabalha em um ambiente isolado, enquanto Claude Code expõe mecanismos de interceptação capazes de barrar chamadas de ferramentas antes da execução.54
A conclusão prática: produtos com agentes precisam de superfícies para status, permissões, rastreamentos, memória, evidência, reversão e supervisão. O chat pode continuar sendo uma entrada. Ele não pode continuar sendo a interface inteira.
Principais conclusões
Para designers de produto: - Projete o estado do agente antes de projetar a entrada de prompt. O usuário precisa saber se o agente está planejando, agindo, bloqueado, esperando, verificando ou concluído. - Trate a revisão de permissões como um fluxo de trabalho principal. Uma chamada de ferramenta arriscada não deve parecer uma interrupção casual de chat.
Para quem constrói agentes: - Registre detalhes de execução suficientes para alimentar uma superfície de rastreamento. Só os nomes das ferramentas não bastam; a superfície precisa de argumentos, saídas, estados finais, caminhos de arquivos e efeitos colaterais. - Torne interrupção e recuperação recursos de primeira classe. O usuário deve conseguir pausar, inspecionar, redirecionar, reverter ou criar uma ramificação de um agente sem ler a transcrição inteira.
Para equipes adotando agentes: - Não meça a qualidade da interface pela fluidez do chat. Meça se o operador consegue responder: o que aconteceu, por quê, com qual permissão e com qual evidência? - Mantenha o gosto no processo. Uma ação correta do agente ainda pode prejudicar a coerência, a dignidade ou a qualidade do produto.
O usuário mudou
O usuário de um produto com agentes não é apenas alguém que escreve prompts. O usuário se torna um operador.
Quem escreve um prompt pede uma resposta. Um operador supervisiona um processo. Quem escreve um prompt se preocupa se o texto soa certo. Um operador se preocupa se o sistema mexeu nos arquivos certos, usou as fontes certas, preservou as restrições certas e parou na hora certa.
Essa diferença muda a interface. Caixas de prompt otimizam expressão. Superfícies de controle otimizam estado, risco, tempo e prova.
Software tradicional pode esconder o processo porque o usuário aciona diretamente a maioria das mudanças de estado. Um botão diz “Enviar”. O usuário clica. O app envia. Software com agentes insere um ambiente de execução decisório entre intenção e ação. O usuário pede um resultado, e o sistema escolhe um caminho. A interface precisa revelar esse caminho o suficiente para que o usuário continue responsável pelo resultado.
As diretrizes de interação humano-IA da Microsoft apontam nessa direção. Elas cobrem o comportamento de sistemas de IA ao longo do tempo de interação: definir expectativas, combinar com o contexto social, mostrar status, apoiar correções e lidar com falhas.1 A lição antiga se aplica bem aos agentes, mas os agentes elevam o risco porque o comportamento da IA não termina mais em uma recomendação. O comportamento pode virar uma chamada de ferramenta.
Design agêntico começa pelo estado
Um bom design agêntico torna o estado visível antes de pedir confiança.
Um agente tem mais estados do que “pensando” e “concluído”:
| Estado do agente | O que o usuário precisa |
|---|---|
| Planejando | Caminho pretendido, premissas, ferramentas prováveis |
| Pesquisando | Termos de busca, fontes, lacunas, próxima consulta |
| Agindo | Chamada de ferramenta, argumentos, alvo, efeito colateral esperado |
| Bloqueado | Permissão ausente, credencial ausente, requisito pouco claro |
| Verificando | Comando de teste, fonte de evidência, critério de aceitação |
| Recuperando | Etapa com falha, caminho de nova tentativa, premissa alterada |
| Concluído | Artefato, evidência, lacuna não resolvida |
A maioria dos produtos de chat comprime esses estados em um único indicador animado de carregamento. Um indicador diz que o sistema ainda não parou. Ele não diz se o agente está lendo, escrevendo, esperando, tentando de novo ou travado.
O estado agêntico precisa de um vocabulário mais rico. A superfície deve mostrar a fase atual, a última ação relevante, a próxima ação pretendida e o motivo pelo qual o agente ainda não terminou. Uma boa superfície de status reduz a ansiedade do usuário porque troca mistério por movimento inspecionável.
A pergunta difícil de design é a densidade. Um agente sério pode gerar milhares de eventos durante uma execução longa. Mostrar todos os eventos cria ruído. Esconder todos os eventos cria confiança cega. A superfície de controle precisa resumir por padrão e expandir sob demanda.
Permissão é material de design
Permissão não é uma página de configurações. Permissão é um dos materiais centrais do design agêntico.
Agentes agem por meio da autoridade que o usuário concede. Escritas em arquivos, comandos de shell, ações no navegador, chamadas de API, etapas de deploy, operações de pagamento e ações que afetam clientes carregam riscos diferentes. A interface precisa tornar esse risco legível no momento da decisão.
A referência de mecanismos de interceptação do Claude Code mostra a forma primitiva dessa ideia: um interceptador PreToolUse pode inspecionar um comando Bash e retornar uma decisão que nega uma operação destrutiva antes que a chamada de ferramenta seja executada.4 Esse mecanismo prova o formato de design. Uma superfície de controle pode organizar operações pendentes por risco, mostrar o comando completo ou o payload da ferramenta, explicar o motivo da chamada e permitir que o usuário aprove, negue, adie ou reescreva a solicitação.
A mudança central: a revisão de permissões deve virar uma fila, não uma interrupção.
Interrupções funcionam para uma ou duas decisões. Elas falham quando o agente executa 40 operações ao longo de uma tarefa longa. Uma fila de permissões permite que o usuário aprove em lote ações de baixo risco, pause ações de alto risco e revise todo o perfil de risco em um único lugar. O usuário deixa de ser puxado para lá e para cá entre ler a prosa do agente e avaliar comandos.
A apresentação de risco também exige gosto. Bordas vermelhas, ícones de alerta e fricção modal podem ajudar. Também podem treinar o usuário a aprovar alertas no automático quando tudo parece urgente. A interface deve reservar o alarme visual para ações irreversíveis ou visíveis externamente. Uma busca somente leitura não deve vestir a mesma roupa de uma migração em banco de dados de produção.
Rastreamento é a nova arquitetura da informação
Design agêntico precisa de arquitetura de rastreamento.
Um rastreamento é o registro ordenado do que o agente fez: prompts, chamadas de ferramentas, argumentos, arquivos lidos, arquivos alterados, comandos executados, fontes abertas, saídas de testes, decisões de permissão, novas tentativas e evidência final. Uma transcrição de chat pode conter partes desse registro, mas uma transcrição não é arquitetura da informação. É uma rolagem.
A superfície de rastreamento deve responder rapidamente a quatro perguntas:
| Pergunta | Requisito da superfície de rastreamento |
|---|---|
| O que aconteceu? | Linha do tempo com filtros por tipo de evento |
| Por que aconteceu? | Motivo declarado pelo agente anexado a cada ação |
| O que mudou? | Diffs, artefatos, efeitos colaterais e caminhos tocados |
| O que sustenta o resultado? | Links de evidência, saídas de comandos, citações e lacunas não resolvidas |
Essa superfície se conecta diretamente à barreira de evidência. Uma resposta final que diz “os testes passaram” deve apontar para o comando de teste e o status de saída. Um artigo público que cita um paper deve apontar para a fonte exata e para o alinhamento da afirmação. Um relatório de migração que afirma paridade deve apontar para o caminho específico do usuário que ainda funciona.
A pesquisa recente sobre rastreamentos de execução aponta na mesma direção. Em Rastreamentos de execução de agentes são o contrato do ambiente de execução, argumentei que a resposta final é a unidade mais fraca para confiar. O rastreamento é mais forte porque preserva o caminho da intenção para a ação e para a evidência.
Memória precisa de um explorador
Design agêntico também precisa de design de memória.
Agentes carregam contexto ao longo do tempo. Parte desse contexto fica na janela ativa. Parte fica em resumos compactados. Parte fica em arquivos, anotações, vector stores, bancos de dados ou instruções do projeto. Parte desaparece. O usuário raramente vê essa fronteira.
Essa invisibilidade cria uma falha de design. Quando um agente contradiz uma decisão anterior, o usuário não consegue saber se o agente discordou, esqueceu, resumiu mal ou nunca carregou a memória relevante. O chat faz a memória parecer contínua mesmo quando o ambiente de execução mudou o que o modelo consegue ver.
Um explorador de memória deve expor três camadas:
| Camada de memória | Pergunta do usuário |
|---|---|
| Contexto ativo | O que o agente pode usar agora? |
| Memória armazenada | O que o agente pode recuperar se precisar? |
| Memória compactada ou desatualizada | O que o sistema comprimiu, omitiu ou marcou como incerto? |
Esse explorador não precisa revelar chain-of-thought privado. Ele precisa revelar memória operacional: instruções, restrições, caminhos de fontes, decisões, artefatos e resumos que o sistema usará para orientar ações futuras.
Busca pertence à mesma família de design. O resultado grep/vector do artigo anterior mostrou que a qualidade da busca depende do ambiente de execução, do caminho de entrega e da capacidade do modelo de fechar o ciclo com a ferramenta, não só do recuperador.6 Se a busca vive no ambiente de execução, a visibilidade da busca pertence à interface. O usuário precisa saber o que o agente buscou, o que ele não encontrou, o que abriu e por que a próxima consulta mudou.
Supervisão não é microgerenciamento
Produtos com agentes muitas vezes tratam supervisão humana como fricção. Um design agêntico forte trata supervisão como o produto.
O NIST descreve o AI Risk Management Framework como uma forma de incorporar considerações de confiabilidade ao design, ao desenvolvimento, ao uso e à avaliação de sistemas de IA.3 Essa formulação importa. Confiabilidade não entra apenas no treinamento do modelo. Ela entra no design, no uso e na avaliação.
Para agentes, supervisão significa que o usuário consegue:
- ver o que o agente está fazendo;
- interromper antes de uma ação irreversível;
- inspecionar o caminho da evidência;
- recuperar-se de um caminho com falha;
- comparar caminhos alternativos;
- aprovar ou rejeitar o artefato final;
- entender o que permanece sem verificação.
Microgerenciamento pede que o usuário aprove cada tecla. Supervisão dá ao usuário o controle certo na altitude certa. Um engenheiro sênior não precisa observar cada arquivo lido. Esse engenheiro precisa ver uma migração de banco de dados proposta, uma nova tentativa após teste com falha, uma afirmação pública alterada ou um comando que toca o estado de produção.
Boas superfícies de supervisão preservam o fluxo ao tirar detalhes de baixo risco da via principal e trazer momentos de alto risco para o foco. O desafio de design não é “mais visibilidade”. O desafio é visibilidade calibrada.
A camada de gosto ainda importa
Design agêntico pode cumprir todos os requisitos operacionais e ainda assim parecer errado.
Uma fila de permissões pode expor os fatos certos enquanto faz o usuário se sentir punido. Uma linha do tempo de rastreamento pode conter todos os eventos enquanto torna a compreensão impossível. Um explorador de memória pode mostrar todos os itens armazenados enquanto destrói a confiança do usuário com excesso de ruído. Um medidor de status pode dizer a verdade enquanto faz o sistema parecer quebrado.
O gosto decide como a superfície carrega risco, confiança, incerteza e prova. Gosto é um sistema técnico: restrições, critérios de avaliação, reconhecimento de padrões e coerência. O design agêntico precisa dos quatro.
Restrições decidem o que o agente pode fazer sem revisão. Critérios de avaliação decidem o que o artefato final precisa provar. Reconhecimento de padrões identifica o fluxo de trabalho que parece bem-sucedido, mas soa frágil. Coerência pergunta se o trabalho do agente melhorou o produto como um todo ou apenas completou a tarefa local.
Essa última pergunta fica mais importante conforme agentes ficam mais baratos. IA torna a produção abundante. A abundância aumenta o valor da recusa, da edição, da coerência e do gosto. A melhor interface agêntica não vai maximizar ações. Ela vai ajudar o operador a decidir quais ações merecem acontecer.
Um checklist mínimo de design agêntico
Comece com sete superfícies:
| Superfície | Requisito mínimo |
|---|---|
| Status | Fase atual, última ação, próxima ação, bloqueador |
| Permissão | Fila por nível de risco com payload completo da ferramenta |
| Rastreamento | Linha do tempo filtrável com argumentos, saídas e efeitos colaterais |
| Evidência | Afirmações mapeadas para fonte, comando, teste ou lacuna não resolvida |
| Memória | Contexto ativo, contexto armazenado, resumos compactados |
| Recuperação | Pausar, retomar, tentar de novo, reverter, ramificar e cancelar |
| Supervisão | Visão entre agentes de trabalho bloqueado, arriscado e concluído |
Nenhuma dessas superfícies exige uma interface de ficção científica. A primeira versão pode ser feita com tabelas simples, linhas expansíveis e filtros sem graça. Animação sofisticada importa menos do que estado honesto. A superfície de controle deve dizer a verdade rapidamente.
A pergunta de design para cada recurso de agente fica simples:
O que a pessoa precisa ver, decidir, interromper ou verificar antes que a próxima ação do agente se torne real?
Se a interface não consegue responder a essa pergunta, o produto ainda depende de teatro de confiança.
Resumo rápido
Design agêntico é design de superfície de controle. O chat continua útil como primitivo de entrada, mas trabalho autônomo precisa de estado visível, filas de permissão, rastreamentos, exploradores de memória, superfícies de evidência, controles de recuperação e visões de supervisão. Microsoft, Google e NIST apontam para design de IA centrado nas pessoas e confiabilidade como responsabilidades do produto, não apenas propriedades do modelo.123 Ferramentas de agentes tornam o ponto concreto: o ambiente de execução já tem mecanismos de interceptação, containers, rastreamentos, arquivos, comandos e efeitos colaterais.45 A interface precisa tornar essas partes legíveis.
O produto com agentes vencedor não será aquele com o chat mais simpático. Será aquele que oferece aos operadores a superfície mais clara, precisa e confiável para trabalho autônomo.
FAQ
Design agêntico é diferente de UX de IA?
Sim. UX de IA cobre qualquer experiência que use aprendizado de máquina ou IA generativa. Design agêntico cobre sistemas que agem ao longo do tempo. A diferença é agência: chamadas de ferramentas, permissões, mudanças de estado, memória, efeitos colaterais e recuperação. Essas propriedades exigem superfícies de controle, não apenas textos úteis ou entrada de prompt.
Todo produto com agentes precisa das sete superfícies?
Não. A área de superfície deve acompanhar o risco. Um assistente de escrita de baixo risco pode precisar de status, evidência e histórico de revisões. Um agente de código ou operações precisa de permissão, rastreamento, recuperação, memória e supervisão. Um agente que afeta clientes precisa de controles ainda mais fortes de auditoria e aprovação.
Por que não manter tudo no chat?
Chat é sequencial e só cresce no fim. Supervisão de agentes precisa de acesso aleatório, filtragem, comparação, revisão em lote e inspeção de estado. Blocos recolhíveis de chat podem melhorar a legibilidade, mas não substituem uma fila de permissões, uma linha do tempo de rastreamento, um explorador de memória ou uma superfície de recuperação.
Qual é a primeira superfície de controle a construir?
Construa o rastreamento primeiro. Sem o rastreamento, todas as outras superfícies viram suposição. O rastreamento fornece os dados para evidência, permissões, recuperação, auditoria e supervisão. Um produto pode começar com uma tabela simples de eventos e melhorar o design ao longo do tempo.
Referências
-
Saleema Amershi et al., “Guidelines for Human-AI Interaction,” Microsoft Research, CHI 2019. Fonte primária para as 18 diretrizes de interação humano-IA, o processo de validação com 49 profissionais de design e o enquadramento do comportamento da IA como um problema de design de interface. ↩↩↩
-
Google People + AI Research, “People + AI Guidebook,” e “People + AI Research,” Google Design. Fonte para o enquadramento de design de IA centrado nas pessoas e para a orientação tática do guia. ↩↩
-
National Institute of Standards and Technology, “AI Risk Management Framework,” NIST, 26 de janeiro de 2023, com atualizações posteriores de perfil para IA generativa. Fonte para incorporar confiabilidade ao design, ao desenvolvimento, ao uso e à avaliação de produtos, serviços e sistemas de IA. ↩↩
-
Anthropic, “Hooks reference,” Claude Code Docs. Fonte para o ciclo de vida dos mecanismos de interceptação,
PreToolUse, comportamento de matcher e decisões de permissão que podem negar chamadas de ferramentas antes da execução. ↩↩↩ -
OpenAI, “Introducing Codex,” OpenAI, maio de 2025. Fonte para o modelo de execução em nuvem do Codex, a descrição de container isolado e o enquadramento de tarefas de engenharia de software em segundo plano. ↩↩
-
Blake Crosley, “Busca de agentes é um problema de ambiente de execução,” blakecrosley.com, 15 de maio de 2026. Fonte para a análise do autor que conecta a qualidade da busca ao ambiente de execução, à entrega de resultados e ao comportamento do ciclo com ferramentas. ↩