Observabilidade em agentic UX

A primeira vez que usei o Claude Code, lancei-lhe uma tarefa não trivial: arrumar a minha pasta de Downloads. Esperava ver um spinner durante 30 segundos e um “feito” no fim. O que vi foi diferente.

Antes de mexer em nada, mostrou um plano: “vou agrupar por tipo de ficheiro, criar pastas, mover, depois confirmar contigo”. Confirmei. À medida que executava, ia listando: “agora estou a ler a pasta”, “agora estou a criar pastas”, “agora estou a mover x para y”. No fim, um histórico completo de tudo o que fez. Pude pausar a meio. Pude cancelar. Pude perguntar porque é que ele tomou uma decisão.

Isto é observabilidade. E é, na minha experiência, a competência de UX mais subestimada em agentic UX. Sem ela, a confiança morre na primeira tarefa não trivial.

O problema: o agente é uma caixa preta

Num produto tradicional, o utilizador vê tudo. Carrega num botão, vê o resultado. Há feedback imediato e visível.

Num agente, há atrasos. Há trabalho em segundo plano. Há decisões que o sistema toma sem perguntar. Se nada disto é visível, três coisas acontecem por ordem:

1. O utilizador desconfia.
2. O utilizador pede confirmação para cada passo, perdendo o valor da automação.
3. O utilizador desiste.

A heurística clássica do Nielsen, visibility of system status, não é negociável. Em produtos agentic, é mais crítica do que nunca, e mais difícil de aplicar.

Os cinco pilares da observabilidade

1. Plano antes de executar. O agente expõe o plano e pede confirmação. Não tem de ser longo. “Vou fazer A, B, C. Continuo?” Dá ao utilizador um momento de override antes que a IA gaste tokens (ou mude ficheiros).

2. Estado em tempo real. À medida que executa, o agente diz o que está a fazer. Não no fim. Durante. Linhas como “a ler ficheiro x” ou “a consultar a base de dados” são suficientes. Não precisam de design elegante; precisam de existir.

3. Atribuição em multi-agent. Quando há vários agentes, dizer qual está a falar ou a agir. Pode ser leve, sem mudar de avatar a cada turno, mas alguma forma de dizer “isto veio do agente de billing” ajuda muito quando algo corre mal.

4. Pausa e cancelamento. O utilizador pode parar a meio. Sem perder contexto. Sem ter de reiniciar a conversa. O Claude Code faz isto bem: podes interromper a meio de um comando, dizer “espera, na verdade muda isto”, e o agente ajusta sem perder o reasoning anterior.

5. Histórico auditável. Tudo o que o agente fez fica registado. O utilizador pode voltar e ver o passo onde algo correu mal. Em produtos onde há custo (tokens), o histórico inclui também o custo de cada ação.

Como o Claude Code aplica os cinco

Vale a pena estudar como peça de design.

• Plano: ao receber uma tarefa não trivial, mostra um plano numerado. Pede confirmação ou ajustes.
• Estado em tempo real: a cada passo, mensagens como “Reading file…”, “Editing line 42…”, “Running tests…”. Texto, não animação.
• Atribuição: quando usa sub-agentes, identifica-os. “Spawning research agent…”
• Pausa: a barra de input nunca fica bloqueada. Podes escrever a meio de uma execução, e o agente ajusta. É um detalhe que muda a sensação completamente.
• Histórico: cada interação fica visível, cada comando executado fica registado. Em texto, scrollable.

Nada disto é magia. É decisão consciente de tornar visível o que normalmente fica escondido.

Onde a observabilidade falha

Três anti-patterns que vejo regularmente:

Spinner sem texto. Um círculo a rodar durante 40 segundos não é observabilidade. É opacidade animada. O utilizador não sabe se está perto, longe, ou se travou.

Animações de “thinking” sem conteúdo. O agente mostra três pontinhos a oscilar. Não diz o que está a pensar. Em tarefas curtas, passa. Em tarefas longas, começa a parecer condescendente.

Logs só para developers. A equipa tem logs detalhados num terminal interno; o utilizador vê uma frase genérica. A observabilidade tem de chegar à interface, não ficar nos backend logs.

O custo psicológico de não ter observabilidade

Há um cálculo silencioso que o utilizador faz cada vez que delega numa IA: “se isto correr mal, sei a tempo de impedir?” Sem observabilidade, a resposta é “não”. Resultado: o utilizador delega menos, pede tarefas menores, perde o valor da automação.

Quando há observabilidade boa, o utilizador delega mais. Confia que vê o que está a acontecer. Confia que pode parar. A produtividade real, com o agente como copiloto ou agente autónomo, depende mais da observabilidade do que da capacidade técnica do modelo.

Combinando com os outros temas

Observabilidade não vive sozinha. Faz par com capability discovery: ajuda a descobrir o que é possível, observabilidade ajuda a confiar enquanto acontece. E em multi-agent, observabilidade torna-se ainda mais crítica, porque há mais peças móveis. Cobre-se isso em Orquestração multi-agente.

Mais sobre o pano de fundo no guia Design for AI. Sobre os princípios éticos que reforçam a importância da transparência, ver Princípios éticos no Design para IA.