Personas Sintéticas em Arquitetura Multiagente: o que muda quando você para de confiar em "dois agentes de IA espertos"
No artigo anterior, contei como cheguei na minha primeira esteira de personas sintéticas com agentes de IA (um agente Pesquisador consolidando os dados e um agente UX Sênior simulando a entrevista).
Funcionou. Ajudou a refinar o protótipo antes de ir para validação com o time e ser testado posteriormente com usuários reais, bem como me ensinou mais sobre o negócio do cliente.
Mas, no fechamento daquele artigo, deixei uma porta aberta:
"O que abriu portas para explorar os testes em uma estrutura multiagentes: dividir os objetivos do teste em mais de um agente."
Esse texto é sobre o que aconteceu quando eu de fato abri essa porta e descobri que não era só adicionar mais agentes. Foi preciso repensar a arquitetura inteira.
1. Por que dois agentes começaram a não bastar
A esteira de dois agentes resolvia um problema específico: gerar uma persona a partir de dados e simular uma conversa com ela. Para um primeiro experimento, era o suficiente!
No entanto, o problema apareceu quando tentei usar o mesmo método em cenários diferentes:
E quando eu não tinha entrevistas? Só tinha hipóteses do time, dados secundários, uns benchmarks soltos. A persona "saía", mas saía com a mesma confiança visual de uma persona com dados reais. Perigoso!
E quando eu queria testar um conceito ainda não desenhado? O agente UX Sênior continuava simulando "uso de telas" porque era o que ele sabia fazer. Resposta nem sempre fazia sentido. E como saber se uma resposta veio dos dados ou foi inferida? Nem sempre dava. Às vezes o agente misturava as duas coisas em uma frase só, e eu tinha que voltar nos dados pra checar manualmente.
O primeiro artigo desta série (Acelerando e refinando testes de UX com AI e sistemas multi-agentes) já tinha alertado pra isso, num dos pontos finais: sem uma estrutura rigorosa, a IA tende a preencher lacunas com suposições genéricas. Eu vi a IA preencher uma lacuna com suposição como se fosse evidência, mais de uma vez, e percebi que prompts mais sofisticados não iam resolver.
O que precisava mudar não era o prompt, mas sim a arquitetura. Se você já passou por isso, sabe a sensação: a pergunta deixa de ser "como prompto melhor?" e passa a ser "como organizo o sistema todo?".
Na imagem: Visão geral da arquitetura atual do teste com usuários sintéticos, atualmente disponibilizado em formato de plugin.
2. A virada: pensar em camadas, não em agentes
A primeira coisa que tive que internalizar é que "multiagente" não é "muitos agentes conversando entre si". Pelo contrário.
A intuição inicial é colocar os agentes para se ajudarem: o Crítico de UI (User Interface) vê o que o Empático escreveu, o Modelador conversa com todo mundo, e por aí vai. Parece colaborativo. Na prática, contamina tudo.
Quando dois agentes de IA podem se ler, as inferências de um viram "fato" para o outro. O padrão é sempre o mesmo: o primeiro arrisca uma hipótese ("o usuário parece ansioso"); o segundo lê e trata como observação ("o usuário está ansioso"); o terceiro propõe ações baseadas em ansiedade. Quando você chega no fim do ciclo, a alucinação está costurada na persona como se fosse evidência.
A solução foi inverter a lógica. Em vez de agentes que conversam, camadas que isolam. Cada camada tem um papel único, recebe input de uma camada específica, e ninguém retroalimenta ninguém. O fluxo é unidirecional.
Saiu uma arquitetura de seis camadas:
Camada 1: Pré-Processador → estrutura os dados brutos
Camada 2: Skills analíticas → analisam em paralelo, orquestradas por um Supervisor
Camada 3: Modelador → consolida em persona
Camada 4: UX Sênior → simula a entrevista
Camada 5: Síntese → integra e avalia
Camada 6: Pesquisador → audita a rastreabilidade
O "Pesquisador" mudou de função entre os dois artigos (relembre a antiga estrutura aqui!). Antes ele criava as personas, agora ele audita o que foi criado. Foi uma das melhores decisões do projeto: separar quem faz de quem confere.
3. As três regras que sustentam a arquitetura
Ter seis camadas não significa nada sozinho. O que faz a coisa funcionar são as três regras que governam o fluxo entre elas.
3.1 Apenas uma camada toca os dados brutos
O Pré-Processador é o único agente com acesso direto às pastas de entrada (entrevistas, analytics, vídeos, telas, hipóteses, etc.). Todas as camadas seguintes operam exclusivamente sobre o output estruturado dele.
Por que isso importa? Porque dados brutos são interpretáveis demais. Quando vários agentes entram em contato com a transcrição original, cada um lê a mesma frase de um jeito. Quando só um agente lê e estrutura, todos os outros partem da mesma base, e qualquer divergência depois vira sinal de algo real, não de leitura diferente.
3.2 Skills da camada analítica não se leem
A camada 2 tem várias skills rodando em paralelo: Cronometrista (mede tempo e fricção), Empatia (mapeia emoções expressas observavelmente), Quantitativo (analytics), Crítico de UI, Hipóteses, Benchmarks, e por aí vai. Quais entram depende do modo de operação.
Num teste de usabilidade com vídeo, por exemplo, entram Cronometrista e Crítico de UI; numa proto-persona sem dados reais, entram Hipóteses e Benchmarks.
Todas elas recebem o mesmo input: o output do Pré-Processador. Nenhuma delas lê o que as outras escreveram. Quem orquestra a camada (um Supervisor que coordena as skills sem ler o que cada uma escreveu) entrega o conjunto para o Modelador, na camada seguinte.
Esse isolamento é o que mais me custou aceitar no começo. Parecia desperdício. Hoje vejo como o oposto: é o que permite que a Camada 5 (Síntese) detecte convergência genuína entre análises independentes. Se três skills isoladas chegaram à mesma conclusão por caminhos diferentes, isso vale muito mais do que se elas tivessem se influenciado.
3.3 Toda afirmação precisa de fonte
Essa é a regra mais chata de implementar e a que mais protege contra alucinação. É um princípio básico de IA responsável (responsible AI). Cada item produzido por qualquer skill tem que carregar uma classificação:
Dado explícito: observado diretamente;
Inferido: conexão lógica não diretamente observada;
Dado secundário: pesquisa externa, relatório;
Benchmark: produto similar, caso publicado;
Hipótese do time: suposição da equipe sem dado externo;
Ausência: nenhum dado encontrado: não preencher.
Parece formal demais, não é? Mas quando o Pesquisador audita no fim, ele consegue separar com precisão o que tem lastro do que é inferência. E quando eu, como designer, vou apresentar a persona pro time, sei exatamente onde posso bater na mesa e onde preciso falar "isso aqui é hipótese, precisa validar".
Na imagem: Indicação do agente pesquisador sobre inferências feitas a partir das fontes consultadas, no contexto de uma pesquisa com proto-personas voltada à compra de apartamentos.
4. Os checkpoints: onde o sistema pode parar
Uma coisa que aprendi: confiar que a IA "vai entregar bem" é a forma mais cara de descobrir que ela não entregou. Por isso, a arquitetura tem dois checkpoints críticos no meio do caminho, pontos onde o ciclo trava se algum critério não for atendido.
Checkpoint 1: depois do Pré-Processador. Antes de disparar as análises paralelas, o sistema verifica: todas as pastas foram processadas? Cada item tem classificação de fonte? Cada item tem referência de origem (pasta, arquivo, trecho)? As transformações foram declaradas? Se for um modo com dados reais, há ausência de informação pessoal identificável?
Se algum desses pontos falha, o ciclo para. Não passa para a camada 2. Notifica o que faltou.
Checkpoint 2: depois do Modelador. Antes de ir pra simulação, verifica se a persona tem todas as seções obrigatórias, se cada característica tem sustentação classificada, se há padrão de decisão mapeado. Se for proto-persona, verifica se a linguagem é condicional, se a confiança está declarada como baixa, se está identificada como proto-persona no cabeçalho.
E no fim, depois da Síntese, vem a auditoria do Pesquisador que pode aprovar, aprovar com ressalvas ou reprovar. Reprovou? Volta para revisão.
Esses checkpoints fazem o ciclo demorar mais. Em compensação, eu chego no final com um artefato em que confio. E quando não confio, o próprio sistema me diz onde olhar.
5. Persona ou proto-persona: o caso de quando os dados não existem
Talvez a parte que mais reorganizou meu jeito de pensar foi separar persona de proto-persona como artefatos distintos, não como "a mesma coisa em estágios diferentes".
Persona sintética nasce quando há dados reais — entrevistas, analytics, vídeos. Confiança média a alta. Linguagem descritiva.
Proto-persona nasce quando não há — só hipóteses, dados secundários, benchmarks. Confiança baixa. Linguagem condicional obrigatória.
A diferença na prática:
Persona (com dados reais):
"O usuário pausou por 8 segundos antes de clicar";
“3 de 5 usuários abandonaram o fluxo neste ponto";
"Há uma pausa longa seguida de reformulação".
Proto-persona (sem dados reais):
"O público possivelmente enfrentaria dificuldade";
"Caso a hipótese se confirme, esse perfil provavelmente...";
"Dados secundários sugerem que...".
Na imagem: apresentação da proto-persona com a sinalização de conter respostas hipotéticas.
Parece detalhe linguístico, mas é um detalhe estrutural. Quando o Modelador escreve "o usuário sente X" sem dado real, ele transforma uma hipótese em afirmação. Quando ele escreve "o público possivelmente sentiria X", ele preserva a incerteza, e quem ler vai tomar decisão diferente.
E uma regra que custou aceitar mas faz sentido: proto-personas não evoluem para personas. Quando dados reais aparecem, você não "atualiza", mas recomeça do zero. Porque uma proto-persona é por natureza hipotética; misturar com dado real cria um híbrido em que ninguém consegue mais distinguir o que é evidência de o que era suposição!
6. O que muda no papel do designer (e o que não muda)
Voltando à pergunta que abriu o primeiro artigo: a IA vai substituir o designer de pesquisa? Continua sendo não. Mas a resposta ficou mais nuançada.
O que mudou com a arquitetura multiagente:
Eu paro menos pra "checar se a IA inventou alguma coisa". O sistema já segrega evidência de inferência por padrão. Consigo lidar com cenários em que não tenho dados reais, antes eu evitava personas nesses casos. Agora gero proto-personas conscientes da própria limitação. O artefato que entrego pro time vem com auditoria embutida. A confiança não é uma sensação minha, é um campo declarado.
O que não mudou:
Persona sintética continua sendo estrutura probabilística, não pessoa real. Simulação não substitui validação empírica. A ressalva continua obrigatória. A pesquisa de campo contínua é o que mantém os dados frescos. Sem ela, qualquer persona (sintética ou não) vira cápsula do tempo.
E talvez a mudança mais importante: a arquitetura me forçou a pensar antes de simular. Que tipo de teste eu quero rodar? Tenho dados reais? Que confiança o resultado precisa ter pra sustentar uma decisão? São perguntas que antes eu pulava direto pro prompt. Agora elas são o primeiro passo do ciclo.
Liderando com método
Se o primeiro artigo foi sobre descobrir que personas sintéticas funcionam, este foi sobre descobrir que funcionam melhor quando você impõe limites estruturais à IA, não quando dá liberdade pra ela.
A intuição é o oposto. A gente quer agentes "espertos", "criativos", "que conectam pontos". Na prática, é o isolamento, a classificação obrigatória de fontes e a auditoria que produzem um artefato confiável. A criatividade da IA generativa, sem governança de IA, é exatamente o que mina a confiança no resultado.
Por aqui na Taqtile, esse aprendizado virou plugin: uma arquitetura reaproveitável que qualquer designer do time consegue rodar em qualquer projeto — tecnologia aplicada na prática, com os mesmos filtros de evidência rodando por baixo.
A ideia não é prender o método em uma pessoa, queremos transformar o método em algo que o time pode construir juntos, bem como iterar juntos.
E você? Já tentou estruturar suas próprias personas sintéticas em camadas, ou ainda está na fase de "dois agentes espertos"?