E se o próximo usuário da sua interface não for humano?

Durante décadas, projetamos interfaces supondo que uma pessoa estaria diante da tela. Ela encontraria uma função, preencheria campos, compararia opções e confirmaria uma ação.

Agora, parte dessas tarefas começa em outro lugar. Uma pessoa pede algo a um assistente, que consulta um serviço ou produto sem abrir a interface gráfica. Chama uma IA dentro do aplicativo em que já trabalha. Delega a um agente a navegação por sites. Ou conversa com um aplicativo que já nasceu como agente.

O tema deste artigo é esse: agentes navegando em interfaces, de que formas eles chegam ao seu produto, o que leem e o que precisa estar bem desenhado para que a tarefa funcione.

A pergunta do título parece falar de máquinas. Este artigo defende o contrário: você não está atendendo um robô; está atendendo pessoas, com desejos, pressa, dúvidas e dinheiro em jogo. O agente é um intermediário. O que muda é o desenho do caminho entre o que a pessoa quer e o que de fato acontece.

Cinco caminhos de navegação agêntica

Chamar tudo de "usar um aplicativo com IA" esconde diferenças importantes. Há pelo menos cinco caminhos (e a cada momento surgem mais possibilidades: quando comecei a escrever este artigo, eu conhecia apenas três), e cada um muda onde a pessoa começa, quem executa e quem decide.

Os caminhos coexistem. Um agente chamado no Slack pode usar uma ferramenta MCP e, em outra etapa, operar um site. Este texto percorre os cinco e, depois, trata do que vale para todos: confirmação, guardrails, ritmo e a experiência do próprio agente (AX). Cada caminho é uma área de estudo própria e estou condensando aqui o que precisa para iniciar.

Caminho 1: a IA dentro do aplicativo que você já usa

No Slack, o Claude Tag pode ser mencionado em um canal, divide a tarefa em etapas, usa as ferramentas conectadas e responde em uma conversa. Em canais, trabalha com a identidade (definida por skills e pelo arquivo AGENTS.md) e os acessos definidos pela organização. Em mensagens diretas, responde em privado, com as ferramentas pessoais de quem pediu. Os administradores escolhem ferramentas por canal, definem limites de gasto e veem o registro de ações com o solicitante (anúncio oficial; documentação).

Para UX, a consequência é que identidade e visibilidade passam a ser parte da experiência. Quem está falando aqui, a pessoa ou a IA? Com a conta de quem? Quem vê a resposta?

Um segundo exemplo, bem mais público: o @grok no X (o antigo Twitter). Qualquer pessoa pode mencionar o Grok em uma conversa ou comentário, e ele responde ali mesmo, à vista de todos que acompanham o fio. O pedido mais comum virou bordão: "@grok, isso é verdade?".

Um estudo, sobre 169.137 posts que acionam o Grok, viu um uso amplo e raso (76,8% das pessoas o chamaram uma única vez), respostas rápidas que alcançam pouca gente e uma sobreposição pequena com as Notas da Comunidade (Bobek, Demirel e Pröllochs, arXiv, 19/05/2026).

O contraste com o Claude Tag é útil para quem desenha. No Slack, a organização decide quem a IA representa, que ferramentas usa e quem vê a resposta. No X, a IA entra em uma conversa pública, responde para todos e não age em nome de quem a chamou: ela informa, e a resposta passa a fazer parte do debate, inclusive quando erra. Mesma ideia (a IA chamada por uma menção, dentro do ambiente habitual), consequências de interface bem diferentes.

Uma recomendação de estudo: os Claude Artifacts, o recurso em que a IA devolve, ao lado da conversa, um conteúdo próprio (documento, página, painel interativo) que a pessoa abre, edita e reutiliza, em vez de só texto corrido (o que são os Artifacts). Para quem desenha interfaces, é um bom laboratório de como uma resposta de IA pode virar interface.

Caminho 2: o aplicativo acessado dentro de uma IA

Antes de olhar os exemplos, vale explicar o que é um MCP.

O MCP (Model Context Protocol) foi anunciado pela Anthropic como um padrão aberto para conectar assistentes de IA a sistemas externos. A comparação oficial é com uma porta USB-C: um encaixe único para ligar assistentes a dados e ferramentas (anúncio; introdução oficial).

Para designers: o MCP é um cardápio padronizado que um serviço entrega ao assistente: "estas são as ações que sei fazer, estes são os dados que posso mostrar". O assistente lê o cardápio e decide qual ação chamar durante a conversa.

Dois exemplos mostram o caminho em ação. Escolha qual ler.

Isso levanta uma pergunta de UX que os dois exemplos deixam em aberto: a pessoa sabe o que pode pedir? O cardápio existe para o modelo. Quem usa o chat vê uma caixa de texto vazia. Como apresentar, de forma amigável, tudo o que um MCP ou uma CLI disponibiliza? Há caminhos a testar: sugestões contextuais ("quer ver suas faturas vencidas?"), exemplos de pedidos, uma resposta clara para "o que você sabe fazer?" e a indicação, a cada resposta, de qual ferramenta foi usada e com quais parâmetros. O Pix com IA do Nubank resolve parte disso com uma barra fixa no topo da Área Pix, que convida a pedir além de quando interage com alguma das opçoes já aplica uma máscara na resposta indicando a estrutura da mensagem e deixando estável a resposta do modelo. Esse tipo de convite explícito, em vez de um campo em branco, é o que faz a capacidade ser descoberta.

Nota do autor: e depois da capacidade descoberta, qual o próximo passo? Nem todos tem o que chamo de IC, índice de curiosidade, ainda mais em tarefas mundanas e do dia a dia, a maioria das pessoas passam mais tempo fora dos seus serviços/sites.

Caminho 3: a IA operando interfaces feitas para humanos

Na terceira relação, o agente usa uma interface originalmente destinada a pessoas. Existem pelo menos três formas de ele "ler" a página, e elas importam para quem desenha o produto.

• Pixels. O agente recebe capturas de tela e controla mouse e teclado, como no Computer Use da Anthropic (documentação). É mais lento, caro e sujeito a erro. (Uma das técnicas de leitura de imagem se chama visão computacional, ou computer vision).
• DOM. O agente lê o HTML da página: aninhamento, identificadores e classes.
• Árvore de acessibilidade. É a representação que leitores de tela usam: papéis (botão, link, título), nomes e estados dos elementos interativos, sem o ruído do CSS.

O exemplo deste caminho é a página inicial da Apple Brasil. Imagine que a pessoa pede ao agente: "descubra quais modelos de iPhone estão à venda". Uma pessoa olharia o menu no topo e clicaria em "iPhone". O agente, rodando o navegador sem janela, recebe outra coisa: uma lista em ordem, que começa com o título "Apple", depois uma região de navegação chamada "Global" e, dentro dela, pares como link "iPhone" e botão "Menu iPhone". É com esses nomes que ele decide o próximo passo. Se o link se chamasse só "link", ou se o menu não estivesse marcado como navegação, a pessoa veria o mesmo menu na tela, mas o agente teria de adivinhar. Mais abaixo, em "O que é um navegador headless", estão as capturas reais dessa leitura.

O guia do Google "Build agent-friendly websites" descreve exatamente essas entradas (capturas, HTML, árvore de acessibilidade e ferramentas WebMCP) e diz que os agentes modernos combinam DOM e árvore para listar os elementos interativos, cruzando com a renderização visual para entender o layout (web.dev). O guia da Pesquisa Google sobre recursos de IA generativa diz o mesmo:

“

agentes de navegador podem analisar capturas, inspecionar o DOM e interpretar a árvore de acessibilidade (Search Central).”

O Nielsen Norman Group chega à mesma divisão em três modos e recomenda rótulos claros, HTML semântico, ARIA e hierarquia lógica (NN/g, 10/04/2026).

• O Googlebot renderiza a página com um navegador headless (um Chromium sem interface) e indexa o HTML renderizado, com o DOM resolvido (documentação do Search).
• O índice de busca não usa o ARIA, mas a navegação agêntica sim. Até a primeira metade de 2024, ao menos (Search Engine Roundtable).
• O Google documenta que agentes de navegador combinam capturas, DOM e árvore de acessibilidade. Na sessão técnica "Build your website for the agentic era", do Google I/O 2026 (19 de maio), um integrante da equipe de IA do Chrome descreve essas três formas de ler a página, diz que a árvore de acessibilidade é a mesma que os leitores de tela usam e afirma que, se o site funciona bem com leitor de tela, ele está "pelo menos na metade do caminho" da prontidão para agentes (página da sessão). Em junho, a equipe do Chrome repetiu que agentes dependem da árvore de acessibilidade como principal modelo de dados (Chrome para desenvolvedores, 22/06/2026).
• Só o ARIA não basta. A página precisa estar organizada para ser lida: um bom índice de leitura, com títulos em ordem lógica, regiões (landmarks) bem marcadas, nomes claros e um fluxo previsível. Itens comuns, como a navegação por Tab e um SEO bem definido, ajudam, mas não são o foco aqui; um site pode ter tudo isso e ainda ser confuso para quem lê em sequência, seja pessoa ou agente.

O que é um navegador headless

Um navegador headless ("sem cabeça") é um navegador comum, como o Chrome, que roda sem janela. Ele carrega a página, executa o JavaScript, monta o HTML final e responde por comando, em vez de por clique. É assim que robôs de busca e agentes "visitam" um site. Para ver na prática, rodei no terminal o Chrome em modo headless contra a página inicial da Apple Brasil: o primeiro comando devolve o HTML já montado, e o segundo, com Playwright, devolve a árvore de acessibilidade, que é o que um agente lê. Repare que, ali, ele não "vê" cores nem imagens: vê papéis e nomes (título, navegação, link "Mac", botão "Menu Mac").

O diagrama abaixo mostra a mesma página de exemplo lida de duas formas: pela árvore, na ordem do DOM (azul), e pela tecla Tab, que percorre só os controles que recebem foco (âmbar). Leitores de tela costumam oferecer, além disso, atalhos para saltar entre regiões (landmarks) e entre títulos. Agentes de navegador, segundo o guia do Google, podem combinar essa árvore com o DOM e a captura de tela. Um exemplo do diagrama: um link sem nome acessível, como um logotipo só com ícone, entra na árvore apenas como "link", e o leitor ou o agente não sabe para onde ele leva.

Além de ler a página, o site pode oferecer ferramentas. É a ideia do WebMCP, um padrão proposto que a mesma sessão apresentou no Google I/O. Em termos simples: em vez de o agente olhar a tela e adivinhar onde clicar, o próprio site entrega a ele uma lista de ações prontas, como "buscar produto", "calcular frete" ou "finalizar compra". O site registra essas ações em JavaScript (a linguagem que faz a página reagir) ou por atributos em formulários HTML (marcações extras nos campos que dizem o que o formulário faz), e o agente as chama diretamente.

Alguns termos que aparecem na sessão, traduzidos:

• Não substitui o MCP. O MCP clássico fica em um servidor, sempre disponível. O WebMCP vive na aba aberta do navegador, herda o login e o contexto de segurança da pessoa (o agente age "como ela", na sessão dela) e as ferramentas são descobertas durante a visita.
• Ferramenta atômica. Uma ação por ferramenta, pequena e com um só propósito ("adicionar ao carrinho"), em vez de uma ferramenta gigante que faz dez coisas.
• Nome e descrição são contexto. O agente lê o nome e a descrição de cada ferramenta para decidir se a usa. Para ele, isso é texto de interface, não documentação interna: escrever "calcula o frete" é parte do design.
• Valores legíveis. Frete "expresso", e não "tipo 1". O que o agente lê é o que ele repete à pessoa.
• Erros descritivos. Em vez de "erro 422", dizer "o CEP precisa ter 8 dígitos", para o modelo conseguir se corrigir sozinho.

A sessão também recomenda tornar as ações visíveis na interface, para a pessoa poder verificar o caminho que o agente seguiu.

Conclusões de UX para quem não programa. Mesmo sem escrever código, há decisões suas aqui: (1) liste as ações principais do produto em verbos claros, porque elas viram as ferramentas; (2) dê a cada ação um nome e uma frase que qualquer pessoa entenderia, pois o agente lê a mesma frase; (3) defina quais ações pedem confirmação humana e quais não; (4) escreva as mensagens de erro como orientação, não como código; (5) mostre na tela o que o agente fez, para a pessoa conseguir conferir. Isso é desenho de interface, só que para dois leitores ao mesmo tempo.

O Lighthouse, ferramenta do Chrome que muita gente já usa, ganhou uma categoria experimental, a "Navegação agêntica". Em vez de uma nota de 0 a 100, mostra uma razão de verificações aprovadas, como "2/2". Ela reúne um subconjunto de auditorias de acessibilidade (nomes e rótulos, integridade da árvore e visibilidade), o deslocamento de layout (CLS), a presença de um arquivo llms.txt na raiz do domínio e, para quem participa do origin trial, o registro de ferramentas WebMCP. A documentação afirma que os agentes dependem da árvore de acessibilidade como principal modelo de dados (Lighthouse: Navegação agêntica). É um sinal de para onde a medição está indo, mas é só um subconjunto, como mostra o caso a seguir.

Leitura visual do DOM e da renderização

Ferramenta de leitura visual do DOM e da renderização da página, usada na apresentação desta palestra.

Nota 100 e 85 problemas: o que a ferramenta não vê

A consultoria de acessibilidade Tudo é Acessibilidade relatou um caso que ajuda a calibrar o otimismo. Um cliente lançou um novo site. Ao rodar ferramentas automáticas como o PageSpeed Insights, a nota de acessibilidade era 100, e a categoria "Navegação agêntica" aparecia como 2/2. Em uma varredura manual, sem ferramentas de análise profunda e só na página inicial, a equipe encontrou 85 problemas com criticidade.

Por agrupamento, os problemas se dividiam assim: UI e design visual, 34 (40%); UX e interação, 22 (26%); comunicação e conteúdo, 19 (22%); estrutura semântica, 7 (8%); outros, 3 (4%).

A consultoria acrescenta que agentes "enxergam" esses problemas e que isso pode atrapalhar o trabalho deles. Mas o que é ruído e o que realmente serve a um agente?

Notas do autor: é ruído o que não ajuda a tarefa e confunde a leitura, como textos repetidos, rótulos vagos ("clique aqui"), elementos decorativos anunciados como conteúdo, sobreposições e ordem de leitura trocada. É útil o que diz o que existe e o que faz: títulos, regiões, nomes de controles, estados (aberto, selecionado, com erro) e mensagens claras. E nada disso deve prejudicar o uso humano nem a acessibilidade: o ajuste feito para o agente não pode esconder conteúdo de quem usa leitor de tela, nem criar um texto só para robôs que a pessoa não vê. O critério é o mesmo: se ajuda a leitura de todos, fica; se só serve a um lado, desconfie.

Algumas leituras minhas, que são hipóteses e não achados da consultoria:

• A ferramenta mede um subconjunto. As verificações de acessibilidade do Lighthouse rodam sobre o axe-core. As estimativas de quanto as ferramentas automáticas detectam variam bastante: a Deque, fabricante do axe-core, reporta 57% dos problemas por contagem (Deque); um estudo da Evinced, também fornecedora, achou 22,6% usando só o axe-core (Evinced).
• No caso, a maior parte não é estrutura. Só parte dos problemas eram de estrutura semântica, onde a automação é mais forte. O resto era visual, de interação e de conteúdo, que pedem julgamento principalmente humano.
• Enxergar não é avaliar. Um agente lê a árvore e a imagem para agir. Quando não consegue, o sintoma é uma tarefa que trava, não um relatório. E uma ferramenta verifica regras (existe um rótulo?), não sentido (o rótulo engana?), o que a consultoria avalia em outras partes do documento também.

Também não há estudo controlado que meça quanto cada tipo de problema atrapalha um agente. Mas o caso sustenta o ponto de fundo deste artigo: uma nota alta é um sinal, não uma garantia, e quem decide se a experiência serve a uma pessoa, ou a um agente a serviço dela, ainda é alguém que olha, principalmente quando essas ferramentas mudam a cada 6 meses.

Documentação com duas portas: para pessoas e para agentes

Quem lê a documentação de um produto nem sempre é uma pessoa diante de uma página. Cada vez mais é uma pessoa que pede a um agente para ler por ela. Alguns produtos já desenham a página com duas portas.

A documentação da Stripe é um exemplo. Em cada página há controles como "Ask about this page", "Copy for LLM" e "View as Markdown", além de um painel "Install agent tools" com opções para Claude Code, Codex e Cursor. Segundo a própria documentação, qualquer endereço de docs.stripe.com devolve a página em Markdown se você acrescentar .md ao final. Há também um servidor MCP (mcp.stripe.com), um catálogo de skills instaláveis em formato legível por máquina e um comando de CLI para configurar o agente (stripe agent setup) (Stripe: Agents and AI; casos de uso). A página chega a se dirigir a agentes de programação, explicando como criar um ambiente de testes sem cadastro. É AX no primeiro sentido, o do agente como usuário, e é também uma facilidade para quem usa o agente.

Fiz algo parecido no design system da Faculdade Phorte. Cada página do styleguide tem "Perguntar sobre esta página", "Copiar para IA" e "Ver como Markdown", com opções para abrir a conversa no Claude ou no ChatGPT já apontando para a versão em Markdown. O menu mostra o estado de cada documento (pronto, em andamento, planejado) e há entradas separadas "para quem desenvolve" e "para quem desenha" (styleguide). A ideia foi preparar o produto para usuários avançados, que já trabalham com um agente ao lado.

Três observações de desenho, que são leituras minhas:

• A mesma informação em dois formatos. HTML para a pessoa, Markdown limpo para o agente, sem o ruído do layout.
• Controles visíveis e nomeados. A pessoa sabe que a página "fala com IA" e escolhe quando usar.
• Estado do conteúdo explícito. Marcar o que está pronto e o que está em andamento ajuda pessoas e agentes a não confiar em uma página incompleta.

Há também uma tensão. Para um agente, texto dirigido a agentes numa página é conteúdo encontrado. A Stripe o usa de forma legítima, mas é o mesmo canal por onde chega uma prompt injection. Cabe ao cliente do agente decidir em quais fontes confiar, e ao produto deixar claro o que é instrução oficial.

Um relato pessoal, sem fonte: ao visitar um site, apareceu um formulário perguntando se eu era um robô, com perguntas que, na prática, ajudariam uma IA a navegar. Perdi o rastro e não consegui localizar a fonte, então trato como relato e não como evidência.

Caminho 4: o aplicativo é a própria IA

No quarto caminho, não há "interface por trás". A conversa é o produto.

O Pix com IA do Nubank é o caso mais nítido no Brasil. O banco anunciou, em 10 de dezembro de 2024, a expansão do recurso no aplicativo, com pedidos por texto, áudio e imagem. O tutorial oficial, atualizado em junho de 2025, documenta a jornada: Área Pix, valor e destinatário, conferência dos dados, confirmação e senha de quatro dígitos (comunicado de lançamento; tutorial). O banco divulgou economia de até 60% no tempo de transação.

Os números de adoção são grandes. Os resultados do 4T25 (25 de fevereiro de 2026) informam que o Pix com IA superou 10 milhões de usuários ativos mensais (resultados), e o relatório do 1T26 repete os 10 milhões (Mobile Time).

Há uma leitura minha sobre esse número, que é uma hipótese e não um dado: é plausível que muitas dessas pessoas nem tenham percebido que usavam IA. Não encontrei pesquisa que meça isso, e o lançamento foi rotulado como "Pix com IA", o que aponta no sentido contrário. Um número de usuários ativos não mede percepção. Mas a hipótese mostra o ponto central do desenho agêntico: o objetivo é reduzir a fricção e o tempo da tarefa. E isso tem dois lados.

• A pessoa chega ao resultado mais rápido, com menos campos e menos telas.
• A pessoa também presta menos atenção ao que está fazendo. Em tarefas simples, ótimo. Em tarefas com dinheiro, o tempo que a fricção ocupava era, às vezes, tempo de conferir.

A literatura de fatores humanos chama isso de complacência e viés de automação (Parasuraman e Manzey, 2010). A Anthropic, ao explicar por que criou um modo automático para o Claude Code, afirma que usuários aceitam 93% dos pedidos manuais de permissão (Anthropic, 25/03/2026); é dado deles, sobre desenvolvedores, não sobre consumidores em pagamentos, mas é um indício de como a confirmação vira rotina. Ao reduzir o atrito, o desenho precisa compensar com guardrails, tema da seção seguinte.

Outro exemplo é o Ailo, do iFood, lançado em outubro de 2025. Segundo a imprensa, uma atualização de 16 de julho de 2026 permitiu a compra completa com um clique, com Pix; há também um aplicativo Ailo em beta, separado do app principal (Canaltech; Mobile Time). Um relato de engenharia descreve um agente único com instruções que mudam conforme a etapa do pedido, e o iFood fala em "arquitetura híbrida inspirada na lógica de skills" (ZenML). Não encontrei confirmação de que o Ailo use MCP ou CLI.

O Pierre também é uma aplicação-agente: o chat do app é o produto. Os "agentes" dele, porém, são outra coisa do que se poderia supor. São monitores com gatilho, como Albert (cobranças suspeitas ou duplicadas) e Marie (resumo mensal). A pessoa cria os seus descrevendo em linguagem natural o que quer acompanhar, de 1 a 10 conforme o plano, e eles não fazem Pix (central de ajuda). Sobre o modelo de IA, o harness e o uso interno de MCP, nada é declarado.

Caminho 5: o celular como agente

Daqui para a frente, o próprio sistema operacional vai chamar os apps. Em 3 de novembro de 2026, a Apple abriu a desenvolvedores o Siri AI com App Intents, em beta; (Apple Developer News). No Android, o AppFunctions faz o app virar uma espécie de servidor MCP no dispositivo, para o Gemini descobrir e executar funções, em prévia experimental (documentação). O "Android CLI" lançado no I/O é outra coisa: uma ferramenta para agentes que programam apps.

A página da Apple Intelligence mostra como isso aparece para a pessoa. A Siri AI "pode realizar ações em apps como Mensagens, Música, Lembretes e outros", e o Mensagens e o Mail sugerem ações rápidas a partir do contexto da conversa (Apple Intelligence). Repare no texto de cada botão: "Create a reminder", "Create a note", "Resume my podcast", "Add to Reminders". Por trás, são funções que os apps declaram ao sistema, o mesmo tipo de cardápio de um MCP ou de uma CLI (algo como createReminder(titulo, data)). Na frente, viram verbo + objeto, na língua de quem usa. É UX writing aplicado a ferramentas: o nome da ação é a interface. Segundo a própria página, as sugestões no Mensagens estão disponíveis em inglês e chegam em uma atualização futura.

Isso muda o trabalho do designer. Em vez de desenhar telas e fluxos para usuários, define-se o que o aplicativo oferece ao agente do sistema e como cada oferta se confirma. É o futuro próximo, não o presente: nada disso está disponível para o usuário comum hoje. E sempre haverá novas possibilidades.

Um debate em aberto: botão ou protocolo?

Nem todo mundo concorda que ler a tela seja o futuro. Em um episódio do podcast Papo na Arena (nº 137), um dos apresentadores chama o agente que clica em botões de gambiarra transitória e prevê um protocolo nativo, como API ou MCP, comparando a fase atual aos primeiros aplicativos móveis, que só adaptavam o desktop. Outro duvida: interfaces e protocolos devem coexistir, como interfaces e APIs coexistem hoje, e as pessoas tendem a terceirizar o que podem, o que muda o papel das interfaces sem acabá-las. É conversa de produto, com opiniões e números lembrados de memória, não pesquisa (episódio).

Dois pontos do episódio conversam com este artigo. O primeiro: o agente aperta os botões, mas quem vê o resultado ainda é uma pessoa. O segundo: adaptar software para agentes lembra o que o design de acessibilidade já faz, e a acessibilidade pode ser fonte de inspiração. também apontam que ser encontrado e escolhido pelo agente do usuário é "o SEO desta era" (alguns chamam de GEO, já acho que seria outro caminho), e que a documentação passa a ser lugar onde os agentes checam informações.

Usuários comuns e usuários avançados

Os cinco caminhos servem públicos diferentes, e o desenho precisa reconhecer isso.

A pessoa comum quer terminar a tarefa sem aprender o sistema. Para ela, o ideal é pouco texto, uma confirmação clara e o mínimo de decisões. Já o usuário avançado pode operar vários agentes, com contas e permissões diferentes no mesmo contexto: um agente com a conta pessoal, outro com a conta da empresa, um terceiro só de leitura.

Para esse público, a ambiguidade é o risco principal: em qual conta isso vai acontecer?

Daí uma proposta de desenho, que é minha e não uma prática documentada: o comando deve carregar os parâmetros que mudam o risco. Em vez de "faça um Pix para a Ana", o pedido mais seguro é "usando a conta X, faça um Pix para a Ana" (como Pierre que acessa várias contas via OpenFinance). E a tela de confirmação mostra esses campos já resolvidos (conta de origem, destinatário, valor, janela de horário), em vez de uma frase corrida.

Procurei produtos que descrevam esse padrão de escolha de conta por comando e não achei documentação de design. O Itaú ia.i e o Iniciador descrevem confirmação explícita antes da conclusão do Pix, mas não tratam de múltiplas contas (Itaú ia.i; Iniciador). Vale, então, tratar como hipótese a ser testada.

Para avançados, mais etapas de confirmação nem sempre são melhores. A teoria do expertise reversal, da psicologia da instrução (Kalyuga e colegas, 2003), indica que apoios úteis a novatos podem atrapalhar quem já domina o assunto. Não encontrei estudo que a teste com agentes mas reforço sobre o estudo da Anthropic sobre o AutoMode. Um desenho possível: avançados definem limites prévios (tetos, janelas, contas permitidas) e confirmam só o que sai deles; iniciantes confirmam mais, mas em campos claros. Em ambos, a decisão final de uma ação irreversível continua sendo da pessoa.

Guardrails: o que fazer quando a fricção cai

Com o atrito menor, o desenho precisa de proteções. Quatro perguntas organizam o assunto.

1. É preciso avisar sempre que há IA e pedir conferência? Avisar, sim. Na União Europeia, desde 2 de agosto de 2026, o Artigo 50 do AI Act obriga a informar a pessoa de que ela interage com IA, salvo quando for óbvio. A obrigação é de divulgar; pedir conferência vem de outro lugar, a supervisão humana. O Nielsen Norman Group mostra que interfaces de chat desencorajam a checagem: verificar custa caro, o acabamento polido gera falsa confiança e avisos pequenos somem na rolagem (NN/g, 16/05/2025). Então, mais do que um aviso fixo, o que ajuda é mostrar os dados que importam em campos estruturados (valor, destinatário, conta), para a conferência ser fácil.

2. Que limites o produto deve impor? Limites de ação, que independem do que o modelo "entendeu". Exemplos de desenho: um teto de valor por operação (digamos, R$ 800 por Pix, como exemplo ilustrativo), um limite por período, uma quantidade máxima de ações por tarefa e uma etapa de confirmação humana obrigatória antes de ação irreversível (e, possivelmente, um seguro contra ações destrutivas feitas por agentes pessoais de IA; seguradoras como a Armilla já oferecem cobertura para erros de agentes em empresas). No Pix, a regra do Banco Central não obriga limite por transação desde 2023, mas exige limite por período, e o limite noturno de R$ 1.000 para pessoa física vem de 2021 (segundo notícias do governo federal; confira o texto vigente no site do Banco Central). O Itaú ia.i só conclui após "ok explícito", e o Iniciador exige biometria. O Chrome pausa e pede confirmação em compras, mensagens, login e sites sensíveis (Google, 28/01/2026). No Pierre, a documentação descreve um fluxo em que o "sim" digitado no chat não aprova uma compra: é preciso tocar na solicitação no aplicativo que provavelmente usa a técnica de artefacts, depois de ver valor, endereço e forma de pagamento. A autorização é um gesto, não uma frase.

3. Em que ambientes e com que limites de navegação o agente pode agir? Aqui entra a prompt injection, o risco de uma página ou mensagem lida pelo agente conter instruções que tentam redirecioná-lo. A Anthropic afirma que nenhum agente de navegador está imune (Anthropic, 24/11/2025). Simon Willison descreve a "trifeta letal": dados privados, conteúdo não confiável e comunicação externa na mesma tarefa (Willison). O desenho defensivo inclui: separar o que o agente pode ler do que pode escrever, restringir domínios e origens por tarefa (o Chrome faz isso com "conjuntos de origens" de leitura e de leitura e escrita, Google Security Blog, 08/12/2025) e conceder o mínimo de permissões. A lista OWASP Top 10 para aplicações com LLM tem edição 2026.

4. Como melhorar o modelo para ele não errar? Não existe uma alavanca única. A leitura mais honesta das fontes é a de camadas. A tabela abaixo é uma síntese minha com âncoras nas fontes:

Modelos mais inteligentes costumam ser mais lentos e caros; modelos rápidos respondem em instantes e erram mais em tarefas complexas. A escolha afeta a experiência. Os limites clássicos de Nielsen continuam valendo: 0,1 s dá sensação de instantaneidade; 1 s mantém o fluxo de pensamento; 10 s é o limite da atenção, quando se precisa de indicador de progresso (NN/g). Para respostas longas de IA, o mesmo grupo recomenda mostrar etapas, narração e tempo decorrido, em vez de uma barra de percentual falsa.

Daí a ideia de ajustar o ritmo de um agente rápido ao ritmo humano de leitura (simular a escrita, reduzir tokens por segundo ou criar um atraso artificial para dar sensação que ele pensou sobre). A evidência é dividida. Um estudo de 2018 em atendimento ao cliente viu que atrasos dinâmicos aumentaram a percepção de humanidade e a satisfação, mas com ressalva para contextos em que se espera rapidez (Gnewuch e colegas, ECIS 2018, lido só pelo resumo). Um estudo de 2026 viu que respostas após 2 s foram vistas como menos ponderadas que após 9 ou 20 s (Tan e colegas, CHI 2026, resumo). Por outro lado, a pesquisa sobre a "ilusão de trabalho" mostra que o que sustenta a confiança é ver o trabalho acontecendo (Buell e Norton, 2011), não esperar de enfeite, como é o funcionamento atual dos harness SOTA (state of the art, o que há de mais moderno).

Minha leitura, então, é que um atraso simulado não se justifica em tarefas que movem dinheiro, onde a rapidez é um valor. Já a confirmação deve aparecer parada, em campos, e não como texto em fluxo que a pessoa precise acompanhar em tempo real. Para referência, a leitura silenciosa de adultos fica perto de 238 palavras por minuto, em uma meta-análise de maioria inglesa; não achei norma para o português brasileiro.

Estados, evidências e registro

Quando uma tarefa delegada leva tempo, a pessoa precisa distinguir pesquisa em andamento, proposta pronta, execução autorizada, bloqueio e conclusão comprovada. "Estou trabalhando nisso" oferece pouca supervisão; um bom estado diz o que já aconteceu, o que falta e que decisão depende da pessoa.

A confiança também depende da qualidade das evidências. "Encontrei", "preparei", "enviei" e "foi confirmado" são estados diferentes, e uma declaração do agente não substitui o retorno do sistema em que a ação deveria ocorrer. Cada ação relevante deveria gerar um registro proporcional à consequência: qual instrução a originou, quais parâmetros, qual autorização se aplicava e qual resultado foi recebido. A especificação do MCP recomenda que haja sempre um humano no circuito, com capacidade de negar invocações (especificação). A existência do protocolo, porém, não comprova a segurança de toda implementação.

E o que é AX?

O termo "Agent Experience" (AX) foi proposto por Mathias Biilmann, da Netlify, em 28 de janeiro de 2025, para a experiência que agentes têm ao usar um produto, numa linha que vai de UX (Don Norman) a DX (experiência de desenvolvedor) e daí a AX (Biilmann). A Microsoft publicou em 6 de outubro de 2026 sua definição, centrada em propensão (o agente encontra e escolhe sua tecnologia?) e eficácia (usa corretamente?) (Microsoft). Em reportagem da CIO, o próprio Biilmann resume que todo produto já tem uma AX, boa ou ruim, porque agentes já tentam usá-lo; o texto acrescenta que expor uma API por MCP não basta: o agente precisa de contexto, permissões certas e da sequência de uso das funções (CIO, 25/02/2026). A Liveblocks, que vende ferramentas de colaboração, liga AX a padrões que designers já conhecem: presença, cursores, comentários e ações visíveis em tempo real, para que pessoas acompanhem o que o agente faz (Liveblocks, 30/01/2025). E a documentação vira parte disso: arquivos como o llms.txt oferecem aos agentes um índice limpo das páginas de uma documentação (Fern, 09/02/2026).

Cuidado com o vocabulário: a mesma sigla circula com dois sentidos. Agent Experience é a experiência do agente como usuário. Agentic Experience é a experiência da pessoa que usa ou supervisiona agentes. Este artigo trata sobretudo do segundo, sem ignorar o primeiro.

O próprio Biilmann trata agentes como "extensões de humanos", e o argumento dele para AX é o benefício ao usuário humano. O Nielsen Norman Group aceita agentes como usuários, mas mantém a pessoa como medida do sucesso: o objetivo é a pessoa chegar ao que queria, não o agente concluir passos (NN/g, 30/10/2026). E há a crítica: o que é bom para o agente nem sempre é bom para a pessoa, e vice-versa; as falhas aparecem nas passagens de bastão entre os dois.

No fim, são pessoas

Se a interface falha com um agente, costuma falhar com uma pessoa; mas o inverso não vale automaticamente. O NN/g diz que, quer a pessoa use a tecnologia diretamente ou delegue a um agente, o papel de UX é garantir que o que se constrói sirva necessidades humanas (NN/g, 28/08/2026). Ben Shneiderman propõe, desde 2020, buscar ao mesmo tempo alta automação e alto controle humano, em vez de trocar um pelo outro (Shneiderman).

Esse é o ponto de partida e o de chegada. Por trás de cada agente existe alguém com um desejo (pagar uma conta, jantar, resolver uma pendência), com pressa, com medo de errar e com atenção limitada. Quando uma IA executa parte do caminho, precisamos projetar como a pessoa define o objetivo, reconhece o alcance da delegação, confere o que importa e consegue interromper.

O próximo operador da interface pode ser um agente. A experiência ainda precisa ser compreensível para quem lhe confiou a tarefa.

Nota de método. Artigo baseado em fontes oficiais e em pesquisa consultadas entre 03 de agosto e 9 de novembro de 2026. As jornadas foram reconstruídas a partir da documentação; não foram executados testes nos produtos. Exemplos identificados como hipotéticos são ilustrações. Funcionalidades documentadas e métricas divulgadas pelos fornecedores não equivalem a validação independente. As recomendações de UX e as leituras marcadas como minhas são interpretações; confira os dados críticos nas páginas citadas antes de reutilizá-los.