Orquestração multi-agente para designers

Quando uma tarefa é simples, um agente chega. Quando é complexa, um agente sozinho falha: aluciana, perde contexto, contradiz-se. A solução é dividir o trabalho por vários agentes especialistas e orquestrar a colaboração entre eles.

Mais barato em termos de tokens. Mais fácil de controlar a qualidade. Mais resiliente a alucinações. E, importante para nós, com implicações de UX bem específicas que mudam consoante o padrão de orquestração escolhido.

Por que vários agentes em vez de um

Imagina um agente único que tem de saber tudo sobre uma empresa: produto, suporte, billing, compliance, design, código. O context window dele fica cheio de regras a competir umas com as outras. As probabilidades de alucinar disparam.

Quando divides o mesmo trabalho por agentes especialistas (um para suporte, outro para billing, outro para design), cada um tem um contexto mais focado, menos regras, menos tools. A qualidade sobe e o custo desce, porque chamadas a modelos com contextos menores são mais baratas.

Há quase sempre um ganho secundário: cada agente pode usar o modelo certo para o seu nível de complexidade. Tarefas triviais correm em modelos pequenos e rápidos; tarefas complexas correm em modelos grandes. Usar Claude Opus para reformatar uma string é desperdício.

Os sete padrões de orquestração

1. Sequential. Um agente depois do outro. O output do A entra no B. Exemplo: agente de design produz mockups, agente de acessibilidade revê, agente de engenharia gera código. Padrão simples, fácil de explicar. Implicação UX: progresso linear, fácil de mostrar como timeline.

2. Parallel. O agente duplica-se para correr partes em simultâneo. Exemplo: o Claude Code, ao processar muitos ficheiros, abre vários sub-agentes que leem em paralelo e juntam os resultados. Implicação UX: progresso simultâneo. Vários cards a avançar ao mesmo tempo. Pede uma forma de mostrar trabalho concorrente sem sobrecarregar.

3. Hierarchical. Um supervisor delega em especialistas. Exemplo: tu falas com a Julia (supervisor); a Julia decide se é melhor chamar o agente de busca, o de comparação ou o de filtros. Implicação UX: o utilizador fala com uma persona, mas vê resultados de várias. A tentação é esconder; o melhor é dar atribuição leve (“usei o agente X para esta parte”).

4. Hand-off. O supervisor faz routing por tipo de pedido. Cada flow vai para o seu agente, sem voltar. Exemplo: pergunta sobre billing vai para o agente de billing e fica lá. Implicação UX: transições têm de ser suaves. O utilizador pode achar que está a falar com a mesma pessoa quando, na verdade, a conversa mudou de mãos. Confirmar a transição com microcopy ajuda.

5. Swarm. Vários agentes negoceiam em tempo real, sem hierarquia clara. Útil para problemas dinâmicos. Implicação UX: real-time edits, ajustes mid-flight, mensagens vindas de múltiplos pontos. Difícil de visualizar; pede uma metáfora forte (varas a flutuar, agentes em conversa privada).

6. React (reasoning + acting). O agente pensa, age (usa uma tool), observa, ajusta. Mais um padrão de execução do que de coordenação, mas combina com qualquer dos outros. Implicação UX: mostrar pensamento e ação como passos separados. O Claude Code faz isto bem, com “thinking” depois “acting”.

7. Magentic. Orquestrador dinâmico que ajusta o plano à medida. Combina elementos do hierarchical com swarm: há um plano, mas ele é redesenhado em real-time conforme a observação. Implicação UX: pede um sistema de status que sobreviva ao plano mudar a meio.

Como a orquestração escolhida muda a interface

Cada padrão pede coisas diferentes da interface. Três decisões críticas:

Atribuição. Em hierarchical e hand-off, o utilizador deve saber qual agente lhe está a responder? A minha resposta default é “sim, leve”. Não com um avatar diferente cada vez, que cansa, mas com uma referência subtil: “verifiquei isto no agente de billing”. Cria confiança e ajuda a debug quando algo corre mal.

Progresso. Em sequential, basta uma timeline. Em parallel, precisas de mostrar trabalho concorrente. Em swarm, mostrar progresso é quase impossível em sentido tradicional, e o melhor é abstrair (“agentes a trabalhar, 3 conversas em curso”).

Controlo. Em sequential e hand-off, o utilizador pode pausar facilmente entre etapas. Em parallel e swarm, pausar é mais complicado e pede decisões: pausa todos os sub-agentes? Só o principal? O design tem de explicitar.

Um exemplo concreto: descoberta conversacional de restaurantes

Imagina uma descoberta conversacional de restaurantes com IA. O sistema usa um padrão hierarchical com hand-off por flow. Um supervisor (chama-se-lhe Planner) recebe a query do utilizador e decide qual o flow correto. Quando o flow é encontrar uma refeição, faz hand-off para um agente de guided search, que tem as suas próprias tools de filtragem por cuisine, distância, restrições alimentares e ranking.

A escolha não é por elegância arquitetural. É prática: separar a busca permite ter prompts mais focados, alucinação mais controlada, e custos mais previsíveis. Cada agente pode ter o seu próprio modelo, sua própria base de prompts, sua própria velocidade.

Do ponto de vista de UX, a transição é invisível para o utilizador, que continua na mesma conversa. Mas a equipa preserva atribuição internamente para debug, observabilidade, e evolução das regras de cada agente.

O que isto pede de ti como designer

Três competências novas:

1. Saber ler um diagrama de orquestração. Mesmo que não o desenhes, vais trabalhar a par com data science e engenharia em diagramas de fluxo de agentes. É o novo flowchart.
2. Decidir o nível de transparência. Quanto da orquestração mostras ao utilizador? Quanto escondes? Não há resposta universal. Depende do produto, do utilizador, da maturidade do mercado.
3. Mapear pontos de quebra. Em hand-offs, em swarms, em parallels, há sempre momentos onde o sistema pode parecer confuso para a pessoa. Esses são os teus moments of truth.

Mais sobre o pano de fundo no guia Design for AI. Sobre como dar transparência ao que cada agente está a fazer, ver Observabilidade em agentic UX.