From a two-agent pipeline to a six-layer architecture: what had to be imposed on AI for the synthetic persona to become a reliable artifact.
In this article, I detail how I built a synthetic persona pipeline with AI agents to test prototypes. After setting out the first exercise, with two agents, I walk through the evolution to a layered architecture, with the rules, the checkpoints and the limits that make it trustworthy.
The first exercise had a Researcher that consumed interview transcripts, metrics and business journeys and generated personas. When the information was not in the material, it reported the gap. The other agent was a Senior UX that received those personas and simulated interviews, in roleplay, critique or mixed mode. I tested the pipeline on a prototype for a B2B consumer goods e-commerce, where the main user is the sales representative serving other businesses, with a dense purchase journey full of logistics scenarios.
It worked. It helped refine the prototype before going to team validation and testing with real users, and taught me more about the client's business, because many of my questions I cleared up by asking the persona and confirming with the team afterwards. It also left two learnings that still hold: the persona is a reflection of the data, a time capsule that ages as the material ages; and accuracy depends on the prompt, because a loose question produces a confused answer, and a question conditioned on a pain point and a source produces a rich one.
The next exercise was taking the method to other scenarios, in a multi-agent structure, splitting the test objectives across more than one agent. The evolution was not about adding agents. I had to rethink the entire architecture.
1. Why two agents started to fall short
The two-agent pipeline solved a specific problem: generate a persona from data and simulate a conversation with it. For a first experiment, that was enough.
The problem appeared when I tried to use the same method in different scenarios.
What if I had no interviews? Only team hypotheses, secondary data, a few loose benchmarks. The persona would "come out", but with the same visual confidence as a persona built on real data. Dangerous.
And when I wanted to test a concept not yet designed? The Senior UX agent kept simulating "screen interactions" because that is what it knew how to do. The response did not always make sense. And how could I tell if an answer came from the data or was inferred? I often could not. Sometimes the agent mixed both in a single sentence, and I had to manually go back to the data to check.
The first exercise had already shown it: without a rigorous structure, AI tends to fill gaps with generic assumptions. I saw AI fill a gap with an assumption as if it were evidence, more than once, and realized that more sophisticated prompts were not going to fix it.
What needed to change was not the prompt, but the architecture. If you have been there, you know the feeling: the question shifts from "how do I prompt better?" to "how do I organize the entire system?"
2. The turning point: thinking in layers, not agents
The first thing I had to internalize is that "multi-agent" does not mean "many agents talking to each other". Quite the opposite.
The initial instinct is to have agents help each other: the UI Critic reviews what the Empathy agent wrote, the Modeler talks to everyone, and so on. It feels collaborative. In practice, it contaminates everything.
When two AI agents can read each other's output, one's inferences become "facts" for the other. The pattern is always the same: the first one ventures a hypothesis ("the user seems anxious"); the second reads it and treats it as an observation ("the user is anxious"); the third proposes actions based on anxiety. By the end of the cycle, the hallucination is woven into the persona as if it were evidence.
The solution was to invert the logic. Instead of agents that communicate, layers that isolate. Each layer has a unique role, receives input from a specific layer, and no one feeds back into anyone else. The flow is unidirectional.
The result was a six-layer architecture:
- Pre-Processor: structures raw data.
- Analytical skills: analyze in parallel, orchestrated by a Supervisor.
- Modeler: consolidates into a persona.
- Senior UX: simulates the interview.
- Synthesis: integrates and evaluates.
- Researcher: audits traceability.
The Researcher changed roles between the two versions. Before, it created personas; now it audits what was created. That was one of the best decisions in the project: separating who builds from who checks.
3. The three rules that sustain the architecture
Having six layers means nothing on its own. What makes the whole thing work are the three rules that govern the flow between them.
3.1 Only one layer touches raw data
The Pre-Processor is the only agent with direct access to the input folders (interviews, analytics, videos, screens, hypotheses). All subsequent layers operate exclusively on its structured output.
Why does this matter? Because raw data is too open to interpretation. When multiple agents read the original transcript, each one reads the same sentence differently. When only one agent reads and structures it, everyone else starts from the same base, and any divergence downstream becomes a signal of something real, not a difference in reading.
3.2 Analytical layer skills do not read each other
Layer 2 has several skills running in parallel: Timekeeper (measures time and friction), Empathy (maps observably expressed emotions), Quantitative (analytics), UI Critic, Hypotheses, Benchmarks, and so on. Which ones are active depends on the operating mode. In a usability test with video, for example, Timekeeper and UI Critic are active; in a proto-persona without real data, Hypotheses and Benchmarks come in.
All of them receive the same input: the Pre-Processor's output. None of them reads what the others wrote. A Supervisor coordinates the skills without reading each one's output and delivers the full set to the Modeler in the next layer.
This isolation was the hardest thing for me to accept at first. It felt wasteful. Now I see it as the opposite: it is what allows the Synthesis layer to detect genuine convergence between independent analyses. If three isolated skills reached the same conclusion by different paths, that is worth far more than if they had influenced each other.
3.3 Every claim needs a source
This is the most annoying rule to implement and the one that most protects against hallucination. It is a basic principle of responsible AI. Every item produced by any skill must carry a classification:
- Explicit data: directly observed.
- Inferred: logical connection not directly observed.
- Secondary data: external research, report.
- Benchmark: similar product, published case.
- Team hypothesis: team assumption with no external data.
- Absence: no data found; do not fill in.
It sounds overly formal, right? But when the Researcher audits at the end, it can precisely separate what is grounded in evidence from what is inference. And when I, as a designer, present the persona to the team, I know exactly where I can make a confident claim and where I need to say "this is a hypothesis, it needs validation".
4. Checkpoints: where the system can stop
One thing I learned: trusting that AI will "deliver well" is the most expensive way to discover that it did not. That is why the architecture has two critical checkpoints mid-cycle, points where the cycle stalls if any criterion is not met.
Checkpoint 1, after the Pre-Processor. Before triggering the parallel analyses, the system checks: were all folders processed? Does each item have a source classification? Does each item have an origin reference (folder, file, excerpt)? Were transformations declared? If running in a real-data mode, is there an absence of personally identifiable information? If any of these fails, the cycle stops, does not advance to layer 2 and flags what is missing.
Checkpoint 2, after the Modeler. Before moving to simulation, it checks whether the persona has all required sections, whether each characteristic has classified support, whether a decision pattern is mapped. If it is a proto-persona, it checks whether the language is conditional, whether confidence is declared as low, whether it is identified as a proto-persona in the header.
At the end, after Synthesis, comes the Researcher's audit, which can approve, approve with reservations or reject. Rejected? It goes back for revision.
These checkpoints make the cycle take longer. In return, I arrive at the end with an artifact I can trust. And when I cannot, the system itself tells me where to look.
5. Persona or proto-persona: when the data does not exist
Perhaps the part that most reorganized my thinking was separating persona from proto-persona as distinct artifacts, not as "the same thing at different stages".
A synthetic persona is born when there is real data: interviews, analytics, videos. Medium to high confidence. Descriptive language. A proto-persona is born when there is not: only hypotheses, secondary data, benchmarks. Low confidence. Conditional language required.
In practice, the persona with real data says "the user paused for 8 seconds before clicking", "3 out of 5 users abandoned the flow at this point", "there is a long pause followed by reformulation". The proto-persona says "the audience would possibly face difficulty", "if the hypothesis holds, this profile would likely...", "secondary data suggests that...".
It seems like a linguistic detail, but it is a structural detail. When the Modeler writes "the user feels X" without real data, it turns a hypothesis into a statement. When it writes "the audience would possibly feel X", it preserves the uncertainty, and whoever reads it will make a different decision.
And one rule that was hard to accept but makes sense: proto-personas do not evolve into personas. When real data arrives, you do not "update"; you start from scratch. Because a proto-persona is by nature hypothetical; mixing it with real data creates a hybrid where no one can distinguish what was evidence from what was assumption.
6. The boundaries of AI
The architecture reduces the risk of hallucination and makes confidence a declared field, but it does not change what a simulation is. Four limits I mapped since the first exercise still define AI's role as a refinement tool, not a replacement.
Data dependency. A synthetic persona is only as deep as the data that feeds it. In the first exercise, the synthetic user kept focusing on a problem in the journey that had already been resolved, because the real-user tests had been conducted before that improvement. The persona reflects the past to try to anticipate the future; that is why constant refreshing of real data matters.
The surprise and emotional factor. AI's strength is in logic and pattern detection, but it still falls short in replicating human unpredictability. Complex emotions, such as the hesitation felt when seeing a new button, are things the simulation could not capture. As the NN Group notes, human behavior is complex and context-dependent, and synthetic users cannot capture that complexity.
Qualitative, not quantitative. The analysis leans toward the qualitative. AI excels at explaining why a flow is confusing, but measuring task time in a synthetic environment is still no more than a suggestion. The simulation answers the "what" and the "why"; the "how much" still belongs to real usability testing.
The risk of hallucination. Without a rigorous structure, AI drifts and fills gaps with generic assumptions. The three rules and the checkpoints exist because of this, and even with them the caveat remains mandatory.
Recognizing these limitations does not diminish the value of the method. On the contrary: it gives the designer the clarity needed to know when to trust the simulation, when to iterate the method and when it is time to go to the field and listen to the real user.
7. What changes in the designer's role (and what does not)
The question that opened the first exercise, will AI replace the research designer?, still has the same answer: no. But the answer has become more nuanced.
What changed with the multi-agent architecture. I spend less time "checking if AI made something up". The system segregates evidence from inference by default. I can handle scenarios where I have no real data; I used to avoid personas in those cases, and now I generate proto-personas that are conscious of their own limitations. The artifact I deliver to the team comes with built-in auditing. Confidence is not a feeling of mine; it is a declared field.
What did not change. A synthetic persona is still a probabilistic structure, not a real person. Simulation does not replace empirical validation. The caveat remains mandatory. Continuous field research is what keeps data fresh; without it, any persona, synthetic or not, becomes a time capsule.
And perhaps the most important change: the architecture forced me to think before simulating. What kind of test do I want to run? Do I have real data? What confidence level does the result need to have to support a decision? These are questions I used to skip, straight to the prompt. Now they are the first step in the cycle.
Leading with method
If the first exercise was about discovering that synthetic personas work, the evolution was discovering that they work better when you impose structural limits on AI, not when you give it freedom.
The intuition is the opposite. We want agents that are "smart", "creative", "connecting dots". In practice, it is the isolation, the mandatory source classification and the auditing that produce a trustworthy artifact. The creativity of generative AI, without governance, is exactly what undermines confidence in the result.
Here at Taqtile, that learning became a plugin: a reusable architecture that any designer on the team can run on any project, with the same evidence filters running underneath. The idea is not to lock the method inside one person; we want to turn the method into something the team builds and iterates on together.
If you want to follow how this method evolves, subscribe to the Taqtile newsletter. It is where we share our latest experiments, cases and projects.