Capability discovery em experiências agentic

Numa interface tradicional, os botões mostravam-se. O utilizador não tinha de adivinhar que era possível filtrar por preço; via “Filtrar por preço” no ecrã. A interface era também o seu próprio menu de capacidades.

Numa experiência agentic, isto desaparece. O utilizador olha para uma caixa de texto e fica em branco. Pode pedir o quê? Quanto pode pedir? Em que tom? A IA tem capacidades incríveis, mas se a pessoa não sabe que existem, não as usa. E se não as usa, o produto falha.

Este é hoje um dos maiores desafios de UX para produtos com IA. Chama-se capability discovery, e há padrões concretos que ajudam.

Por que o problema é maior do que parece

Quem trabalha em IA vive numa bolha. Sabe que o GPT pode gerar ficheiros 3D para impressão, sabe que o Claude pode codar uma aplicação inteira a partir de uma conversa, sabe pedir um plano de viagem completo de Lisboa a Tóquio.

A maior parte dos teus utilizadores não sabe nada disto. Os pais, os colegas fora da bolha, alguns amigos: chegam a um chatbot e usam-no como um Google. Pergunta curta. Resposta curta. Frustração quando a resposta não é a que esperavam.

O problema agrava-se em multi-agent. Se o sistema tem 5 agentes especialistas, cada um com 10 tools, são 50 capacidades latentes que ninguém vai descobrir por iniciativa própria. Esperar que o utilizador “explore” é, na prática, garantir que 90% das capacidades nunca são usadas.

Cinco padrões que funcionam

1. Tarefas como exemplo. Em vez de uma caixa de texto vazia, dar 3 a 5 starter tasks típicas. “Planear uma viagem a Lisboa”, “Resumir este PDF”, “Comparar os dois ficheiros”. O utilizador clica numa, vê o resultado, percebe o género de coisas que pode pedir. É como um menu, mas curado.

2. Sugestões contextuais proactivas. Durante o flow, sugerir o próximo passo. Quando alguém termina de partilhar um documento com a IA, mostrar “Posso resumir, traduzir, ou extrair os pontos principais”. Não é spam: é capability discovery embebida no momento em que faz sentido.

3. Documentação leve no momento certo. Não é um help center separado. É uma frase que aparece quando relevante: “também posso fazer isto noutros idiomas, basta dizer”. A heurística do Nielsen “help and documentation” continua válida. Aplica-se de forma diferente: documentação contextual em vez de manual.

4. Histórico do utilizador como pista. Se a pessoa já usou uma capacidade rara, lembrá-la mais tarde. “Da última vez também fiz X. Queres que faça?” Transforma comportamento histórico em educação implícita.

5. Mostrar o que outros pediram. Sem violar privacidade, agregar pedidos comuns numa secção de exemplos. “As pessoas costumam pedir…”. Ajuda quem está a começar e dá um sinal de que o sistema é capaz.

O equilíbrio: capacidade vs. simplicidade

O instinto designer é minimizar a interface. Caixa limpa, prompt curto, deixar a IA falar. Funciona quando o utilizador já sabe o que pode pedir. Falha quando não sabe.

O outro extremo, listar todas as capacidades num menu vertical, devolve-nos à interface tradicional e perde-se a fluidez do conversacional. É o pior dos dois mundos.

O meio termo que tem funcionado: começar com sugestões visíveis e contextuais, e ir afinando à medida que o utilizador ganha à-vontade. Os power users acabam por preferir a caixa vazia. Os iniciados precisam dos rails. Não é um caso de “ou um ou outro”, é progressão.

O que isto pede de capability discovery em multi-agent

Quando há vários agentes, capability discovery torna-se um problema duplo. Primeiro, o utilizador tem de saber o que o sistema todo pode fazer. Segundo, idealmente, perceber qual agente está a tratar do quê (atribuição, abordada em Orquestração multi-agente).

Uma solução elegante é apresentar capacidades agregadas, não por agente. O utilizador não precisa de saber que existe um “agente de busca” e um “agente de comparação”. Precisa de saber que pode buscar e que pode comparar. A divisão interna fica como detalhe técnico.

Como medir capability discovery

Três métricas que acompanho:

1. Cobertura de tools por sessão. Quantas das tools disponíveis foram usadas? Se o número é baixo, há tools invisíveis.
2. Time-to-first-non-trivial-action. Quanto tempo até a pessoa pedir algo que não seja trivial (uma pergunta simples)? Se é alto, capability discovery está a falhar.
3. Padrão de pedidos repetidos. As pessoas pedem 3 ou 4 coisas e param? Sinal de que descobriram um subset pequeno e pararam de explorar.

Onde isto encaixa no resto

Capability discovery é uma das três peças centrais de agentic UX, ao lado de Observability e cost communication. Cobre-se o pano de fundo geral no guia Design for AI.

A heurística clássica de “help and documentation” do Nielsen continua a ser uma boa lente. A diferença é que, em produtos agentic, ajuda e documentação não são páginas separadas: são micro-momentos durante o uso. Vale a pena revisitar as 10 heurísticas com olhos de IA quando estiveres a desenhar para isto.