O produto ganhou uma segunda interface — para o agente de IA

Ana quer mudar o endereço de entrega

Ana comprou uma mochila numa loja on-line, pagou e só depois percebeu que a entrega estava marcada para o endereço antigo. Ela escreve para o agente de IA:

Anamensagem para o agente de IA

Encontre meu último pedido pago e mude o endereço. Se ele já tiver sido enviado, fale com o suporte.

Para Ana, a tarefa inteira cabe em duas frases. O agente que se vire com o resto.

O caminho mais óbvio é abrir o site da loja para ele. Para uma pessoa, está tudo no lugar de sempre: aqui está a lista de pedidos, ali o selo verde “Pago”, depois o endereço de entrega e o botão “Alterar”. O olho encontra o que importa, a mão leva o cursor até lá. Alguns segundos.

Para o agente, cada um desses passos vira uma tarefa separada: carregar a página, encontrar o último pedido pago, localizar o status da entrega, ligar o texto ao botão certo, clicar e conferir o resultado.

Nós, humanos, largamos com uma vantagem enorme. Eu, por exemplo, sou ultramegamultimodal. Percebo ao mesmo tempo o texto, a cor, a posição dos elementos, o formato conhecido do cartão do pedido e o contexto da página inteira. O cursor é quase uma continuação da mão.

A IA recebe o site de outro jeito. O navegador monta a página num DOMDOM, ou Document Object Model, é a árvore de elementos que o navegador monta a partir do HTML: títulos, links, campos e botões. Ela serve de base para uma árvore de acessibilidade com nomes, funções e estados dos elementos. O que o agente realmente enxerga depende das ferramentas de navegador que ele usa., e as ferramentas do agente entregam ao modelo texto, uma árvore de elementos, uma captura de tela ou tudo isso de uma vez. Mesmo quando o modelo enxerga a imagem, ainda precisa ligar o botão visível ao elemento que a ferramenta do navegador consegue controlar. Um olhar humano vira várias chamadas e verificações.

A própria loja já sabe o número do pedido, o estado da entrega e a regra “depois do envio, o endereço não pode mais ser alterado”. Ela transformou esses dados numa página para uma pessoa; agora o agente tenta reconstruí-los a partir da tela.

A loja também pode ter uma entrada de serviço: a API. Por ela, programas conversam direto com a loja — “encontre o pedido”, “mostre o status”, “mude o endereço”. MCPMCP (Model Context Protocol) é uma forma aberta de oferecer ao agente de IA as ferramentas de um serviço, seus parâmetros e resultados. é uma forma organizada de oferecer esses comandos ao agente de IA, com nomes, explicações e campos claros. Um comando pode substituir várias páginas, campos e cliques. Em vez de passear pelo site, dois programas têm uma conversa curta.

Eu cheguei a essa conclusão bem antes do Codex: um site funciona de um jeito para mim e de outro completamente diferente para um programa. Com a chegada dos agentes de IA, isso virou uma questão de produto.

Antes, o desenvolvedor pensava em como uma pessoa encontraria uma função, apertaria um botão e veria o resultado. Agora a mesma função ganha uma segunda rota: como a pessoa delega o trabalho ao agente de IA, quais dados ele recebe, o que pode alterar e como presta contas no final.

O navegador continua sendo uma saída universal. Se o serviço não oferece outra entrada, o agente pelo menos tenta clicar nos botões. Pela API ou pelo MCP, ele chega direto aos mesmos pedidos e às mesmas regras. O nome mais próximo que encontrei para essa entrada foi agent surface, uma superfície para agentes.

Ao lado da tela aparece uma segunda representação do produto. A pessoa recebe páginas, formulários e botões. O agente recebe capacidades e estados legíveis por máquina. Por baixo, continuam os mesmos pedidos, pagamentos e regras.

É disso que trata este artigo: como projetar um produto ao mesmo tempo para uma pessoa com cursor e para o agente de IA dela. Que interfaces o agente vai precisar, até onde uma boa API já resolve e o que ainda precisa ser projetado à parte.

Eu já estava pronto para escrever um post sobre isso no meu canal do Telegram e fui procurar, junto com uma IA, quem tinha estudado o assunto antes. Encontrei os Web Verbs da Microsoft Research, o estudo Beyond Browsing e o experimento aberto da Reflex.

Resumindo: fazer a IA trabalhar com um serviço pelo navegador é um jeito bem ruim de interagir com ele. Eu procurei uma demonstração pública direta disso e não encontrei. Então montei uma loja falsa para Ana e testei um agente em algumas tarefas usando o navegador, uma boa API, ferramentas geradas automaticamente e ferramentas MCP desenhadas em torno do pedido do usuário.

E tudo isso leva a uma ideia ainda mais estranha: a interface que conhecemos também pode deixar de ser permanente. Chegaremos lá mais perto do fim.

De UI/UX para AI/AX

UI é a interface para a pessoa; UX é a experiência dela com o produto. Neste título, AI é a minha abreviação para Agent Interface, a interface do agente. AX é Agent Experience, a experiência do agente com o produto.

Há muito tempo projetamos UI e UX para pessoas: tanto o que aparece na tela quanto o caminho inteiro entre a intenção e o resultado. Agora o agente precisa desse mesmo par. A Agent Interface mostra as capacidades do produto. Agent Experience mede o quanto é fácil encontrar a ação certa, entender uma restrição e continuar depois de um erro.

Na interface humana, a loja diz para Ana: “O pedido já foi entregue à transportadora; não é mais possível mudar o endereço”. Com uma boa AX, o agente recebe o mesmo significado num formato próprio para a máquina: o endereço está bloqueado, este é o motivo e o próximo passo disponível é falar com o suporte. A regra deixa de ficar escondida num botão cinza ou numa mensagem que apareceu por três segundos e sumiu.

Daqui em diante, vou chamar essa entrada de agent surface, ou interface para agentes. Seria ótimo chamá-la de AI, mas essas letras já significam inteligência artificial. A mesma ideia também aparece com outros nomes: Agent Runtime Surface, Agent-Native e Web VerbsO Agent Runtime Surface propõe publicar para o agente o estado e as ações disponíveis. No Agent-Native, uma única descrição de ação serve para a interface, a API e as ferramentas do agente. Os Web Verbs da Microsoft Research descrevem ações com entradas, resultados e condições de execução claras..

Resumindo, uma função passa a ter duas representações. A pessoa vê um botão permanente ou um formulário montado para uma situação específica; o agente de IA recebe uma ação direta, com descrição e condições claras. O pedido, as regras e as permissões continuam compartilhados.

À pergunta habitual “Como uma pessoa vai usar esta função?” junta-se outra: “Como ela vai delegar esta função ao seu agente?”

Quatro entradas para a loja da Ana

Enfim, eu fiz um experimento. Assim este texto tem alguma coisa além da minha opinião — embora a resposta já parecesse óbvia. Mesmo assim, vale olhar os resultados. Eles são divertidos.

As quatro versões tinham os mesmos clientes, pedidos, pagamentos e regras. Só mudava a entrada usada pelo agente.

A terceira entrada testava o caminho mais rápido de integração: pegar uma boa API e mostrá-la automaticamente ao agente. A quarta verificava se um MCP montado em torno da tarefa do usuário trazia algum ganho relevante.

Eu fiz uma boa API comum: nomes claros, documentação e erros que davam para entender. Senão seria roubar no experimento.

O mesmo agente de IA usou as quatro entradas, sempre no modelo Gemini 3.5 Flash. Ele recebeu dez tarefas, desde mudar o endereço até devolver dinheiro e falar com o suporte. Executou cada uma pelas quatro entradas, cinco vezes: 10 tarefas × 4 entradas × 5 tentativas = 200 execuções.

No geral, uma boa API já basta

O agente recebeu 50 tarefas por cada uma das quatro entradas. A API, as ferramentas geradas automaticamente e o MCP concluíram as 50 com sucesso. Pelo site comum, o agente conseguiu 39 de 50.

Eu repeti o teste do navegador separadamente com o AntigravityAntigravity é uma ferramenta de navegador que mostra ao agente um mapa da página com botões e campos numerados., que oferece um conjunto diferente e mais completo de ferramentas para controlar sites. Na primeira série, o agente recebia principalmente o texto da página e procurava os botões pelo nome. O Antigravity mostrava um mapa da página com botões e campos numerados. O resultado subiu para 47 de 50.

Na tabela, uma ação é um passo do agente: uma requisição à API, uma chamada de ferramenta, a passagem para outra página ou um clique. A mediana é o tempo em que metade das tarefas já tinha terminado.

Agora, o principal: uma boa API já basta para o agenteEm outras palavras, não é preciso criar uma implementação MCP para cada site ou produto quando já existe uma API aberta e bem descrita.. Com ela, ele completou 50 tarefas de 50, gastando cerca de três ações e dez segundos em cada uma. Também foi o método direto mais barato: menos de dois centavos por tarefa.

O MCP encurtou muito pouco o caminho: algo como um terço de ação e um segundo. Ana diz “mude o endereço”, e o agente já enxerga a ferramenta “alterar endereço de entrega” com suas condições de execução. Com a API, ele precisa encontrar a requisição adequada e preencher o número do pedido e o endereço novo.

A diferença foi pequena porque a API comum também explicava honestamente como trabalhar com ela. A descrição dizia qual requisição alterava o endereço e quais dados eram necessários. Se o pacote já tivesse saído, a loja devolvia o erro ADDRESS_LOCKED_AFTER_DISPATCH — “endereço bloqueado depois do envio” — e já sugeria criar um chamado de suporte.

As ferramentas geradas automaticamente também concluíram todas as 50 tarefas. O programa simplesmente pegava a descrição da API e transformava cada requisição numa ferramenta separada para o agente. É uma forma rápida de conectar um serviço existente. O agente ainda precisa montar o pedido de Ana usando várias ferramentas, por isso o caminho ficou um pouco mais longo.

No navegador, o agente teve que repetir todo o trabalho humano: abrir páginas, procurar o pedido, entrar no cartão, encontrar o botão e conferir se alguma coisa mudou depois do clique. O primeiro conjunto de ferramentas levou ao resultado em 39 dos 50 casos. O Antigravity chegou a 47.

Neste teste, o Antigravity quase reduziu pela metade o tempo de cada tarefa, embora o agente tenha feito ainda mais ações: 14 em média, contra três pela API. Boas ferramentas de navegador aceleram o caminho pela interface humana. O caminho continua longo.

Uma boa API comum já pode ser uma ótima interface para agentes. Para começar, basta descrever com clareza as requisições, os campos necessários e os erros que indicam o próximo passo. Ferramentas MCP separadas ajudam quando um pedido do usuário precisa ser dividido entre várias requisições.

Pronto, podemos encerrar a demonstração de que obrigar um agente a passear pelo site quando existe uma entrada direta é uma bela porcaria. O navegador continua sendo uma saída universal, e boas ferramentas realmente ajudam. Em tempo, número de ações e dinheiro, ainda é um desvio por uma interface feita para pessoas.

Depois de visitar a loja, o agente precisa de um recibo

Resolvida a questão do navegador. Na série principal, o agente completou a tarefa em 189 das 200 execuções. Só 93A avaliação estrita exigia uma resposta completa e valores exatos de um vocabulário fechado. Uma formulação com o mesmo sentido ainda podia falhar. Portanto, 93 de 200 mede a obediência ao contrato, não a proporção de respostas verdadeiras. terminaram com uma resposta final totalmente exata.

Voltemos à Ana. Digamos que o pedido já tenha saído. O agente mantém o endereço e cria um chamado de suporte — ou seja, faz tudo certo. Depois escreve: “Pronto, encaminhei a questão para o suporte”.

Ana ainda tem dúvidas: o endereço ficou mesmo igual? O pedido continua lá? Aconteceu alguma coisa com o pagamento? O agente encontrou essas informações pelo caminho, mas só metade chegou até a pessoa.

Depois de uma ação comum, o site mostra uma confirmação. O agente precisa de um recibo parecido:

Ana pode receber esse recibo numa interface clara, enquanto o modelo o recebe como campos com nomes conhecidos. O ideal é que a própria loja preencha esses campos a partir do resultado real da operação.

Agora compare o recibo com a resposta do agente: “Pronto, encaminhei a questão para o suporte”. Só dá para entender que o chamado foi criado. O endereço continuou igual, o pedido já tinha saído e o pagamento foi preservado — nada disso chegou até Ana.

Portanto, a interface para agentes precisa devolver quatro partes: o resultado da ação, o estado preservado, o motivo da restrição e o próximo passo disponível. Aí o agente só repassa fatos prontos para a pessoa.

Para emitir esse recibo, o serviço precisa conhecer, num só lugar, a ação, o estado e as regras. A partir dessa base dá para montar a tela de confirmação da Ana, a resposta da API e o relatório do agente.

Interfaces personalizadas do futuro

O recibo do capítulo anterior já é uma interface pequena, montada para uma tarefa da Ana. Ele contém apenas o que ela precisa agora: o endereço, o motivo da recusa e o número do chamado. É aqui que a coisa fica mais interessante.

Uma interface convencional sempre acaba sendo um compromisso. O designer estuda o público, escolhe os principais cenários e constrói uma rota para milhares de pessoas. Para algumas ela encaixa naturalmente; outras passam um tempão procurando um botão conhecido, e outras fecham a página. Mesmo uma boa interface funciona melhor para uns do que para outros.

Com agentes, a escala da personalização muda. A loja pode montar uma tela para uma pessoa e uma tarefa no momento da solicitação. Para Ana, que quer mudar o endereço, aparecem o pedido, os dois endereços e a confirmação. Se ela estiver escolhendo uma mochila, a tela se monta em torno dos parâmetros importantes para ela e mantém por perto as ações que ajudam na decisão.

A aparência também pode ser pessoal. Ana pode pedir ao agente: “Mostre todos os serviços com letras grandes, nas minhas cores e sem animação”. No celular, talvez prefira um caminho curto com um único botão; no monitor do trabalho, uma comparação detalhada. A mesma loja pode parecer diferente para ela até mesmo ao longo do dia.

Fica ainda mais interessante quando o agente pessoal da Ana monta essa tela. Ele conhece os hábitos dela, recebe pelo MCP as capacidades da loja e escolhe os componentes adequados. Assim, a própria pessoa participa da configuração da interface apenas explicando ao agente o que é confortável.

Para a loja, isso também é uma ferramenta de marketing. Hoje os sites personalizam produtos, banners e ofertas por segmento. Aqui, todo o caminho se torna pessoal: quais blocos mostrar, quanto explicar, por qual ação começar e como levar aquela pessoa até o resultado. A loja ganha a chance de remover passos desnecessários e aumentar a conversão de cada usuário individualmente.

O Google chama essa direção de Generative UI: a interface é montada e reorganizada conforme a tarefa e o contexto do usuário. No projeto aberto A2UI, o agente escolhe as peças necessárias num catálogo preparado, e o aplicativo monta a tela.

O catálogo funciona como um design system: contém campos, cartões e botões prontos. Para cada peça, o visual e os estados já foram pensados — por exemplo, como o botão fica depois do clique ou como um campo mostra um erro. O agente decide quais peças a pessoa precisa agora e em que ordem colocá-las.

Acho que, nos próximos anos, designers de UI/UX vão projetar cada vez mais componentes, seus estados e as regras de montagem. Se esse modelo pegar, um produto terá tantas variações de interface quanto usuários e tarefas. O agente montará a tela final para uma pessoa, um dispositivo e um momento específicos.

Na base continuam as mesmas capacidades do produto: a loja sabe encontrar o pedido, quando o endereço pode ser alterado e como confirmar o resultado. Dessa base, o agente recebe uma ferramenta MCP e monta uma interface adequada para Ana.

Resta uma pergunta prática: onde guardar a descrição de todas essas capacidades e regras?

Primeiro, descreva como tudo deve funcionar

No desenvolvimento de software, já chegamos a uma mudança parecida. Usamos uma abordagem spec-driven: primeiro descrevemos como o produto deve funcionar; só depois entregamos a especificação ao agente de IA para que implemente.

Uma especificação, ou simplesmente spec, guarda o acordo sobre o funcionamento do produto. Nela ficam os cenários, estados, regras e um resultado verificável. O código pode ser reescrito, o agente trocado ou a tarefa levada para outro chat — quem assumir depois ainda entende exatamente o que o produto deve fazer.

Estamos até construindo um produto separado em torno dessa abordagem, para que aplicativos criados com IA possam evoluir e ser mantidos direito. A pessoa define a intenção, as specs guardam a estrutura do produto, o agente escreve o código e os testes verificam o resultado.

Com interfaces acontece a mesma mudança. Para montar uma tela personalizada, não basta entregar ao agente um catálogo de botões bonitos. Ele precisa saber o que o produto faz, em que estado está, quais regras estão valendo e como o resultado deve ser confirmado.

Para o pedido da Ana, uma pequena spec poderia ser assim:

• Objetivo: mudar o endereço do último pedido pago.
• Dados necessários: Ana, os pedidos dela, o estado da entrega e o novo endereço.
• Regra: antes do envio, o endereço muda; depois do envio, permanece igual.
• Permissões: o agente só trabalha com os pedidos de Ana e dentro do que ela pediu.
• Confirmação: para reembolsos e outras ações arriscadas, o agente chama Ana de novo.
• Resultado: a loja informa o que mudou e o que permaneceu igual.
• Se o endereço estiver bloqueado: criar um chamado de suporte e devolver o número.

A partir de uma descrição assim, dá para montar todo o resto:

Por isso, descrever processos, capacidades e estados se torna mais importante do que qualquer implementação isolada. O código ainda será reescrito várias vezes. A interface pode ser remontada para cada usuário. A spec preserva o sentido comum e impede que essas versões do produto se afastem umas das outras.

Acho que, nos próximos dois ou três anos, equipes de produto terão que cuidar dessas descrições com a mesma atenção que hoje dedicam ao código e ao design system. O designer de UI/UX projetará os componentes e as regras de montagem; o desenvolvedor, as capacidades e os contratos; e o agente poderá transformar tudo isso num produto funcional para uma pessoa específica.

Ana continua escrevendo as mesmas duas frases. O agente lê a descrição da capacidade, escolhe a ferramenta certa, respeita as regras, monta uma tela adequada e devolve um recibo.

A loja da Ana já não tem uma única porta principal. A pessoa vê uma tela, o agente vê capacidades e a interface é montada para a tarefa no momento da solicitação. Na base ficam dados, regras e ações. É isso que agora teremos que projetar.