De uma esteira de dois agentes a uma arquitetura em seis camadas: o que foi preciso impor à IA para que a persona sintética virasse um artefato confiável.
Neste artigo, detalho como construí uma esteira de personas sintéticas com agentes de IA para testar protótipos. Situando o primeiro exercício, com dois agentes, vou detalhar a evolução para uma arquitetura em camadas, com as regras, os checkpoints e os limites que a tornam confiável.
O primeiro exercício contava com um Pesquisador que consumia transcrições de entrevistas, métricas e jornadas de negócio e gerava personas. Quando a informação não estava no material, ele reportava a lacuna. O outro agente era um UX Sênior que recebia essas personas e simulava entrevistas, em modo roleplay, crítica ou misto. Testei a esteira num protótipo de e-commerce B2B de bens de consumo, em que o usuário principal é o representante que atende outros negócios, com uma jornada de compra densa e cheia de cenários logísticos.
Funcionou. Ajudou a refinar o protótipo antes de ir para a validação com o time e para o teste com usuários reais, e me ensinou mais sobre o negócio do cliente, porque muitas dúvidas eu esclarecia perguntando à persona e confirmando depois com o time. Também deixou dois aprendizados que seguem válidos: a persona é um reflexo dos dados, uma cápsula do tempo que envelhece se o material envelhece; e a assertividade depende do prompt, porque pergunta solta gera resposta confusa, e pergunta condicionada a uma dor e a uma fonte gera resposta rica.
O exercício seguinte foi levar o método a outros cenários, numa estrutura multiagente, dividindo os objetivos do teste em mais de um agente. A evolução não foi adicionar 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.
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. A 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 numa frase só, e eu tinha que voltar aos dados para checar manualmente.
O primeiro exercício já tinha mostrado: 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 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?".
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 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 ao 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:
- Pré-Processador: estrutura os dados brutos.
- Skills analíticas: analisam em paralelo, orquestradas por um Supervisor.
- Modelador: consolida em persona.
- UX Sênior: simula a entrevista.
- Síntese: integra e avalia.
- Pesquisador: audita a rastreabilidade.
O Pesquisador mudou de função entre as duas versões. 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). 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 de forma observável), 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. Um Supervisor coordena as skills sem ler o que cada uma escreveu e entrega o conjunto ao 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 de 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. 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? 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 ao time, sei exatamente onde posso bater na mesa e onde preciso dizer "isso aqui é hipótese, precisa validar".
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 e notifica o que faltou.
Checkpoint 2, depois do Modelador. Antes de ir para a 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 ao 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: 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.
Na prática, a persona com dados reais diz "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". A proto-persona diz "o público possivelmente enfrentaria dificuldade", "caso a hipótese se confirme, esse perfil provavelmente...", "dados secundários sugerem que...".
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 escreve "o público possivelmente sentiria X", preserva a incerteza, e quem ler vai tomar uma 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", 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 do que era suposição.
6. As fronteiras da IA
A arquitetura reduz o risco de alucinação e deixa a confiança declarada, mas não muda o que a simulação é. Quatro limites que mapeei desde o primeiro exercício continuam definindo o papel da IA como ferramenta de refinamento, e não de substituição.
A dependência de dados. Uma persona sintética é tão profunda quanto os dados que a alimentam. No primeiro exercício, o usuário sintético insistia num problema da jornada que já estava resolvido, porque os testes com usuários reais eram anteriores à melhoria. A persona reflete o passado para tentar antecipar o futuro; por isso a reciclagem constante de dados reais importa.
O fator surpresa e emocional. A IA é boa em lógica e detecção de padrões, mas ainda falha em replicar a imprevisibilidade humana. Emoções complexas, como a hesitação ao ver um botão novo, a simulação não capturou. Como aponta o NN Group, o comportamento humano é complexo e depende do contexto, e os usuários sintéticos não captam essa complexidade.
Qualitativo, não quantitativo. A análise pende para o qualitativo. A IA é excelente para apontar por que um fluxo é confuso, mas a métrica de tempo de tarefa em ambiente sintético ainda não passa de uma sugestão. A simulação responde "o quê" e "por quê"; o "quanto" ainda pertence aos testes de usabilidade reais.
O risco da alucinação. Sem estrutura rigorosa, a IA divaga e preenche lacunas com suposições genéricas. As três regras e os checkpoints existem por causa disso, e mesmo com eles a ressalva continua obrigatória.
Reconhecer essas limitações não diminui o valor do método. Pelo contrário: dá ao designer a visão necessária para saber quando confiar na simulação, quando iterar o método e quando é hora de ir a campo ouvir o usuário real.
7. O que muda no papel do designer (e o que não muda)
A pergunta que abriu o primeiro exercício, a IA vai substituir o designer de pesquisa?, continua com a mesma resposta: não. Mas a resposta ficou mais nuançada.
O que mudou com a arquitetura multiagente. Eu paro menos para "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 ao 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 para sustentar uma decisão? São perguntas que antes eu pulava, direto para o prompt. Agora elas são o primeiro passo do ciclo.
Liderando com método
Se o primeiro exercício foi sobre descobrir que personas sintéticas funcionam, a evolução foi descobrir que funcionam melhor quando você impõe limites estruturais à IA, não quando dá liberdade a 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, é 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, com os mesmos filtros de evidência rodando por baixo. A ideia não é prender o método numa pessoa; queremos transformar o método em algo que o time constrói e itera junto.
Se quiser acompanhar como esse método evolui, assine a newsletter da Taqtile. É por onde contamos nossos últimos experimentos, cases e projetos.