Novos Verbos: Os Primitivos de Interação da Era Agentic
O artigo anterior desta série terminou com uma pergunta implícita.
Se os produtos agentic precisam de controle granular — se controle binário não é controle de verdade, se intervenção precisa ser proporcional ao risco — então o que exatamente o usuário precisa fazer?
Quais são as ações?
Quais são os elementos de interface que as suportam?
O que muda no vocabulário de interação quando o usuário deixa de executar e passa a supervisionar?
Essas perguntas parecem técnicas.
Na prática, são perguntas de linguagem.
Toda era de computação produziu um vocabulário de interação próprio.
Estamos no início de uma nova era, e o vocabulário ainda não foi formalizado.
Este artigo tenta começar essa formalização.
Os verbos antigos e por que não bastam mais
O modelo de interação que dominou as últimas três décadas de software foi construído sobre um conjunto pequeno e poderoso de primitivos.
Clicar seleciona, confirma e dispara ações. Digitar insere dados e instruções. Arrastar reorganiza e relaciona. Deslizar navega e descarta. Tocar faz tudo isso em superfícies menores.
Esses verbos foram extraordinariamente eficazes porque o mundo que descrevem é simétrico e síncrono.
O usuário age. O sistema responde imediatamente. O usuário vê o efeito. O usuário age de novo.
Cada ciclo tem feedback claro, escopo delimitado e reversibilidade alta.
Clicar em "deletar" pode ter um "desfazer". Digitar texto errado pode ser corrigido antes de salvar. Arrastar um arquivo para o lugar errado pode ser desfeito.
O usuário é o agente causal de tudo que acontece.
Em um sistema orientado a agentes, essa estrutura colapsa.
O usuário define uma intenção. O agente executa uma sequência de ações — às vezes dezenas delas — de forma assíncrona. O resultado aparece depois, possivelmente muito depois.
Entre intenção e resultado, ações foram tomadas sobre dados reais, sistemas reais, pessoas reais.
Clicar, digitar e arrastar não descrevem nada que acontece nesse intervalo.
São verbos do operador.
O supervisor precisa de verbos diferentes.
Os novos primitivos: um vocabulário para supervisão
O vocabulário de interação agentic está surgindo de forma fragmentada — em ferramentas de developer, em plataformas de automação, em sistemas de aprovação corporativa.
Ainda não existe padronização.
Mas os primitivos emergentes podem ser organizados em três grupos funcionais.
Primitivos de controle de fluxo
Esses verbos controlam o andamento da execução.
Aprovar — autorizar uma ação específica antes que o agente a execute. Diferente de "confirmar um resultado", aprovar acontece no momento da decisão, não depois do fato. O usuário vê o que o agente pretende fazer e libera ou bloqueia.
Pausar — suspender a execução em um ponto específico para que o usuário possa revisar o estado atual. Diferente de cancelar: o progresso é preservado. O agente aguarda.
Retomar — continuar a execução a partir de um estado pausado, com ou sem ajustes.
Rejeitar — vetar uma ação específica sem cancelar o fluxo inteiro. O agente registra a rejeição, pode tentar uma abordagem alternativa ou pular aquela etapa, e continua o restante do trabalho.
Escalar — redirecionar uma decisão para outro usuário. O agente pausa aquela ramificação do fluxo, notifica o responsável indicado e aguarda resposta antes de continuar.
Primitivos de ajuste e correção
Esses verbos permitem modificar o curso da execução sem precisar recomeçar.
Ajustar — modificar um parâmetro, instrução ou restrição antes que o agente continue. O usuário não cancela nem aprova como está — ele edita antes de liberar.
Reverter — desfazer uma ação já executada e restaurar o estado anterior. Exige que o sistema mantenha snapshots de estado e que o agente saiba operar em modo de rollback.
Redirecionar — alterar o objetivo ou abordagem do agente no meio da execução, sem partir do zero. O contexto acumulado é preservado; apenas a direção muda.
Restringir — adicionar um limite operacional a partir daquele ponto. "A partir daqui, não modifique arquivos fora desta pasta." "Não envie comunicações externas sem nova aprovação." O agente incorpora a restrição e a aplica ao restante da execução.
Primitivos de visibilidade
Esses verbos dão acesso ao estado interno da execução.
Inspecionar — abrir uma visão detalhada de um ponto específico da execução: o que o agente sabia, o que considerou, o que decidiu e por quê. É o equivalente funcional do "ver raciocínio" — mas estruturado como interface, não como texto livre.
Comparar — visualizar o antes e o depois de uma ação específica. Qual era o estado? O que mudou? Essa é a semântica do diff aplicada além do código.
Sinalizar — marcar uma ação para revisão posterior sem interromper o fluxo. O agente continua; aquele item fica em uma fila de revisão humana.
Auditar — navegar pelo histórico completo de execução de forma não linear, buscando por tipo de ação, período, risco ou resultado.
Esses onze primitivos não são exaustivos.
Mas representam o vocabulário mínimo que um produto precisa para que o usuário exerça supervisão real — não supervisão performática.
A diferença entre um produto que tem todos eles e um produto que só tem "aprovar" e "cancelar" é a diferença entre delegar e abdicar.
O que domínios maduros já resolveram
A indústria de software está chegando tarde a uma conversa que outros campos tiveram décadas atrás.
Qualquer sistema onde humanos supervisionam automação de alto risco já enfrentou exatamente esse problema.
E resolveu, ainda que de forma imperfeita.
Aviação: mode awareness e exception-based alerting
O cockpit de vidro moderno é um dos exemplos mais estudados de design de supervisão humana.
O problema central que ele resolve não é exibir mais informação — é exibir a informação certa no momento certo, sem sobrecarregar o piloto.
Dois princípios emergiram como fundamentais.
O primeiro é mode awareness: o piloto sempre sabe em qual modo o piloto automático está operando, quais restrições estão ativas e o que o sistema fará diante de cada condição. A falta de mode awareness está na raiz de vários acidentes graves — o piloto acredita que o sistema está fazendo X enquanto ele está fazendo Y.
O segundo é exception-based alerting: o cockpit não alerta o piloto sobre tudo que está acontecendo. Alerta sobre o que desvia do normal e exige atenção. O silêncio do sistema é informação — significa que tudo opera dentro dos parâmetros esperados.
Esses dois princípios traduzem diretamente para produtos agentic.
O usuário precisa saber em qual modo o agente está operando e quais restrições estão ativas.
O produto não deve notificar sobre cada ação executada — deve notificar sobre o que desvia do esperado ou ultrapassa um limiar de risco.
Controle industrial: hierarquia de visibilidade e gestão de alarmes
Sistemas SCADA — usados para monitorar e controlar infraestrutura industrial — desenvolveram uma disciplina de design que o software de consumo ignora quase completamente.
O primeiro princípio é hierarquia de visibilidade: o operador navega entre visões em diferentes níveis de granularidade. Visão geral do sistema → área específica → unidade → componente. Cada nível revela mais detalhe. O operador não é forçado a ver tudo ao mesmo tempo.
O segundo é gestão de alarmes: o consórcio ASM (Abnormal Situation Management) estabeleceu que inundação de alarmes é tão perigosa quanto ausência de alarmes. Quando o operador recebe centenas de alertas simultâneos, a capacidade de distinguir o crítico do irrelevante colapsa.
A regra prática resultante: um alarme deve ser acionado apenas quando exige ação humana. Informação que não requer ação não é alarme — é dado de monitoramento passivo.
Para o designer de produto agentic, a pergunta equivalente é direta:
Cada notificação que este produto emite requer ação do usuário?
Se a resposta for não, não é notificação. É ruído que treina o usuário a ignorar tudo.
Medicina: resumo contextual e pontos de intervenção
Em unidades de terapia intensiva, profissionais de saúde supervisionam múltiplos pacientes com dezenas de parâmetros monitorados continuamente.
O desafio de design é idêntico ao do software agentic: como manter o profissional informado sem sobrecarga, e como tornar os pontos de intervenção óbvios e rápidos.
Duas soluções foram desenvolvidas.
A primeira é o resumo contextual: durante rounds, o profissional não vê todos os dados brutos — vê uma síntese inteligente que destaca desvios, tendências e itens que precisam de decisão. O detalhe fica disponível, mas não é o ponto de entrada.
A segunda é a distinção entre modos de monitoramento e modos de intervenção: a interface muda de estado quando o profissional indica que vai agir sobre um paciente. O contexto relevante emerge. Os controles de ajuste ficam acessíveis. Isso elimina a confusão entre "estou vendo" e "estou agindo".
O padrão comum nos três domínios é o mesmo.
Sistemas de supervisão maduros não tentam expor tudo o tempo todo.
Eles expõem o estado normal de forma silenciosa, destacam desvios de forma proporcional e tornam os caminhos de intervenção óbvios e rápidos quando necessários.
O SaaS agentic vai precisar chegar ao mesmo lugar.
O audit trail é um produto, não um log
Todo sistema agentic produz alguma forma de histórico de execução.
O problema é para quem esse histórico foi projetado.
Na maioria dos casos, o audit trail existe para três audiências:
- Compliance — o que aconteceu para fins regulatórios
- Engenharia — o que falhou para fins de debugging
- Segurança — o que foi acessado para fins de auditoria forense
Essas são audiências técnicas e retrospectivas.
O usuário de produto — que precisa entender o que o agente fez, navegar até um ponto específico, reverter uma decisão ou justificar uma ação para um cliente — não está nessa lista.
Isso precisa mudar.
Um audit trail projetado como produto tem propriedades muito diferentes de um log técnico.
Linguagem de usuário, não de sistema.
Um log técnico diz: POST /api/v2/contacts/bulk-update — 200 OK — 47 records modified.
Um audit trail de produto diz: "O agente atualizou 47 contatos com o novo segmento de preço. 3 contatos tinham dados incompletos e foram ignorados."
A diferença não é cosmética. É a diferença entre informação que o usuário consegue processar e informação que exige tradução técnica para fazer sentido.
Narrativa, não sequência.
Logs são sequenciais por natureza — linha após linha em ordem cronológica.
Execuções agentic têm estrutura narrativa: intenção → planejamento → execução → resultado → exceções.
Um audit trail de produto organiza os eventos em torno dessa estrutura, não em torno do timestamp.
Diff como primeiro cidadão.
Para qualquer ação que modifica estado, o usuário precisa ver o antes e o depois sem precisar reconstituir isso manualmente.
O diff — familiar para desenvolvedores em contexto de código — precisa se tornar um primitivo de visualização para qualquer tipo de dado modificado por agentes.
Registro atualizado, configuração alterada, conteúdo modificado: o usuário aponta para a ação e vê exatamente o que mudou.
Pontos de rollback marcados.
Nem todo estado pode ser restaurado — e o produto precisa ser honesto sobre isso.
Mas onde a reversão é possível, ela precisa ser visível no próprio histórico, não enterrada em configurações.
O usuário navega até o ponto de execução onde quer reverter e a ação está ali, disponível, com clareza sobre o que será restaurado e o que não pode ser recuperado.
Profundidade sob demanda.
A visão padrão do audit trail mostra o resumo — o que aconteceu em linguagem de usuário.
O usuário que quiser mais detalhe desce um nível: vê as ações individuais.
O usuário que quiser ainda mais desce outro nível: vê o raciocínio do agente, as ferramentas invocadas, os dados consultados.
Cada camada adicional de profundidade é opcional e contextual — não forçada sobre todos os usuários o tempo todo.
A diferença entre um log técnico e um audit trail de produto não é apenas de apresentação.
É de audiência, de intenção e de responsabilidade.
Um log registra o passado.
Um audit trail de produto mantém o usuário capaz de agir sobre ele.
Context design: a nova disciplina
Existe um nome emergindo para o conjunto de práticas que torna execução agentic legível, navegável e acionável para usuários.
Context design.
Não é UX design no sentido clássico — otimizar a interação humana com uma interface.
Não é data visualization — tornar dados numéricos compreensíveis visualmente.
É algo diferente: tornar o estado e o raciocínio de um sistema autônomo compreensíveis e acionáveis para um humano que não estava presente durante a execução.
Cinco princípios emergem como centrais.
Legibilidade — o usuário entende o que o agente fez sem conhecimento técnico do sistema. A execução é descrita em linguagem de domínio, não em linguagem de infraestrutura.
Navegabilidade — o usuário percorre o histórico de execução com a mesma facilidade com que percorre um documento. Pode ir direto ao ponto que interessa, expandir o que quer examinar, colapsar o que já entendeu.
Acionabilidade — cada fragmento de informação relevante tem um caminho de ação claro associado. O usuário que vê um problema não precisa sair da tela de histórico para corrigi-lo.
Proporcionalidade — a profundidade de informação exposta é proporcional ao risco e à relevância. Ações de baixo risco aparecem de forma compacta. Ações críticas aparecem com mais contexto e mais opções de intervenção.
Continuidade — o usuário consegue retomar o contexto a qualquer momento sem reconstruir tudo do zero. O estado da execução é persistente e descritivo o suficiente para que alguém que não acompanhou em tempo real consiga entender o que aconteceu.
Esses princípios não são novos em abstrato — aparecem em disciplinas como arquitetura de informação, design de sistemas e comunicação técnica.
O que é novo é a necessidade de aplicá-los ao produto de software de uso cotidiano.
Até agora, o usuário de SaaS nunca precisou entender o que o sistema estava pensando.
Agora precisa.
O que isso exige do engenheiro frontend
A transição para interfaces agentic não é apenas um desafio de design.
É um desafio técnico que recai diretamente sobre o engenheiro frontend.
O frontend clássico gerencia estado de interface — o que está selecionado, o que está visível, o que foi digitado. Esse estado é local, efêmero e síncrono com as ações do usuário.
O frontend agentic precisa gerenciar estado de execução — o que o agente está fazendo agora, o que fez antes, em qual etapa está, quais restrições estão ativas, o que pode ser revertido, o que não pode.
Esse estado é remoto, persistente e assíncrono com relação ao usuário.
A diferença é estrutural.
Streaming e sincronização em tempo real.
O usuário precisa ver o que o agente está fazendo enquanto ele faz.
Isso exige SSE, WebSockets ou equivalentes tratados como primitivos de produto — não como otimizações de performance. A UI precisa ser projetada para receber atualizações incrementais e apresentá-las de forma coerente, sem redesenhar a tela inteira a cada evento.
Versionamento de estado como requisito de produto.
Rollback não é uma feature opcional de power user.
É um requisito de governança.
O frontend precisa saber exatamente em qual versão do estado cada elemento de UI está baseado, e precisa conseguir navegar para versões anteriores de forma fluida.
Fluxos de aprovação e escalação como componentes de primeira classe.
Não são modais genéricos de confirmação.
São componentes que entendem contexto — qual ação está sendo aprovada, qual o risco associado, quem pode aprovar, qual o histórico dessa decisão.
Esses componentes precisam ser projetados, testados e mantidos com o mesmo cuidado que qualquer outra parte crítica do produto.
Classificação de risco na camada de apresentação.
O frontend precisa entender — ou receber do backend — a classificação de risco de cada ação e renderizar a interface de acordo.
Não é lógica de negócio que pertence só ao servidor.
É informação que determina o que o usuário vê, como vê, e o que pode fazer.
Novos domínios de referência.
O engenheiro frontend que quer entender como resolver esses problemas não vai encontrar as respostas apenas em tutoriais de React e artigos de Dribbble.
Vai precisar estudar:
- design de sistemas de controle supervisório
- princípios de gestão de alarmes industriais
- padrões de cockpit de aviação
- interfaces de monitoramento de infraestrutura crítica
Esses campos resolveram versões difíceis do mesmo problema há décadas.
As soluções não são diretamente transferíveis — contexto importa.
Mas os princípios são.
Conclusão
Esta série começou com um tweet sobre escrever código sem prestar muita atenção.
Chegou até aqui: os verbos que o usuário precisará para supervisionar sistemas que agem por ele.
O caminho foi longo, mas a lógica é linear.
O vibe coding acelerou a geração de código e expôs os limites de engenharia sem disciplina.
Os agentes assumiram operação antes exclusivamente humana e redesenharam o papel do desenvolvedor.
A interface perdeu centralidade operacional e virou camada de observabilidade.
O usuário precisou aprender a delegar em vez de operar — e os produtos precisaram aprender a suportar isso com governança real.
E agora chegamos ao vocabulário.
Os primitivos de interação que tornam a supervisão possível, os sistemas de referência que já resolveram problemas parecidos, a nova disciplina de context design e o que o engenheiro frontend precisará dominar para construir isso.
Mas existe uma tensão que ficou aberta ao longo de toda a série.
Quanto mais capaz o agente, menos o humano precisa entender.
E quanto menos o humano precisa entender, menos ele consegue intervir quando necessário.
Essa tensão não tem solução técnica definitiva.
Ela tem solução de design — interfaces que mantêm o humano informado sem sobrecarregá-lo, que tornam a intervenção possível sem exigir que ela seja constante, que preservam a agência humana sem exigir que o humano execute cada detalhe.
Resolver essa tensão é o trabalho de design mais importante da próxima década.
O frontend sempre foi a camada que conectava sistemas a pessoas.
Na era agentic, essa responsabilidade não diminuiu.
Ela ficou mais difícil — e mais importante.
Referências
Observação: algumas fontes citadas no artigo são pesquisas, artigos técnicos e publicações corporativas recentes. As referências abaixo seguem uma adaptação do padrão ABNT para materiais digitais e documentação online.
Série — artigos anteriores
FERNANDES, Caio. Vibe coding: entre a euforia e a ressaca técnica. [Publicado], maio 2026.
FERNANDES, Caio. Do Vibe Coding ao Agent Engineering. [Publicado], maio 2026.
FERNANDES, Caio. A Interface Morreu: O Software Agora Conversa com APIs, Não com Humanos. [Publicado], maio 2026.
FERNANDES, Caio. Delegar ou Abdicar: O Novo Problema Central do Design de Produto. [Rascunho], maio 2026.
Referências externas
BAINBRIDGE, Lisanne. Ironies of Automation. Automatica, v. 19, n. 6, p. 775–779, 1983. Disponível em: https://www.sciencedirect.com. Acesso em: mai. 2026.
ENDSLEY, Mica R. Toward a Theory of Situation Awareness in Dynamic Systems. Human Factors, v. 37, n. 1, p. 32–64, 1995.
ASM CONSORTIUM. Alarm Management: A Holistic Approach. ASM Consortium, 2009. Disponível em: https://www.asmconsortium.net. Acesso em: mai. 2026.
HOLLNAGEL, Erik. Cognitive Reliability and Error Analysis Method (CREAM). Elsevier, 1998.
NIELSEN, Jakob. AI Agents: The End of the UX You Know. Nielsen Norman Group, 2025. Disponível em: https://www.nngroup.com. Acesso em: mai. 2026.
SHNEIDERMAN, Ben. Human-Centered AI. Oxford University Press, 2022.
NORMAN, Don. The Design of Future Things. Basic Books, 2007.
ANTHROPIC. Claude Code: Agentic Coding. Anthropic, 2025–2026. Disponível em: https://www.anthropic.com/claude-code. Acesso em: mai. 2026.
MICROSOFT. GitHub Copilot Workspace: Technical Preview. GitHub, 2025. Disponível em: https://github.blog. Acesso em: mai. 2026.
VERCEL. v0 and Agentic UI Patterns. Vercel Blog, 2025. Disponível em: https://vercel.com/blog. Acesso em: mai. 2026.
NATIONAL TRANSPORTATION SAFETY BOARD (NTSB). Air France Flight 447 Accident Report. NTSB, 2012. Disponível em: https://www.ntsb.gov. Acesso em: mai. 2026.
FOWLER, Martin. LLMs and Software Engineering. Martin Fowler Blog, 2025. Disponível em: https://martinfowler.com. Acesso em: mai. 2026.
UNIÃO EUROPEIA. EU Artificial Intelligence Act (AI Act). Parlamento Europeu, 2024. Disponível em: https://artificialintelligenceact.eu. Acesso em: mai. 2026.