Customer Experience Simulation Is Agent-Driven User Research

The journey map looked clean because the simulated customer obeyed it.

The demo moved from discovery to onboarding to support exactly as the team expected. The account owner read the page in order. The billing question waited until the pricing step. The permissions problem waited until setup. Support stayed politely downstream.

Then the first real customer took a different path. They opened support before finishing setup. They got stuck between a pricing question and a permissions problem that the journey map had treated as separate moments. The demo had shown the intended flow. The customer exposed the actual system.

The concrete scenario in this post is narrow on purpose: a B2B account owner with incomplete admin permissions, a billing concern, a teammate who needs access, a docs path, and a support handoff. Customer experience simulation is useful there as rehearsal. It is not a replacement for research. It is not a shortcut around real customers. It is a way to make journey hypotheses executable before real customers pay the cost.

The mistake#

The mistake is treating synthetic users as if they are users.

That mistake is tempting because the outputs can look convincing. A model can produce plausible complaints, plausible objections, plausible quotes, and plausible persona-level reasoning. Plausible is not validated. Plausible is the beginning of the work.

NIQ's discussion of synthetic respondents names the core risk well: convincing answers are not the same thing as accurate answers, especially when a business decision depends on data integrity. IxDF makes a similar distinction in its discussion of AI-generated synthetic users and researched personas: a synthetic persona is not a substitute for actual user research.

The same rule applies to agent-driven CX simulation.

The simulation can suggest where a journey might break. It can reveal assumptions the team has encoded into the environment. It can stress a handoff before launch. It can generate telemetry questions. It cannot prove that real customers will behave that way.

The word "research" in this post means hypothesis generation, rehearsal, and instrumentation design. Validation still belongs to real signal.

The tradeoff#

The tradeoff is rehearsal speed versus evidence quality.

Agent runs are cheap. A team can try ten onboarding variants before recruiting anyone, vary the customer role, change the support path, and inspect the trace in minutes. That speed is valuable when the question is "what might break?"

The cost is that every run produces fluent language. Fluent language feels like evidence even when it is only a plausible behavior generated inside the team's own assumptions.

I would rather constrain the simulation hard and get fewer, auditable claims than let agents improvise rich customer stories. The simulation should be allowed to be boring. The research decision should stay expensive.

What agents add#

Traditional journey mapping is static. It names stages, emotions, touchpoints, pain points, and opportunities. That is useful, but it often hides interaction. Customers do not move through a service as a single path on a slide. They pause, retry, misread, ask another person, open another tab, call support, abandon, return, and bring prior memory back into the next step.

Agents make the journey executable.

The Stanford Generative Agents paper is useful here because it does not frame agents as one-shot respondents. It describes agents with memory, reflection, planning, and interaction inside a sandbox environment. The important idea for CX work is not that the agents are "human." The important idea is that the simulation can preserve state across steps and allow behavior to emerge from interaction with an environment.

That changes the shape of a product question.

Instead of asking:

What would a customer say about onboarding?

Ask:

What happens when an account owner with incomplete permissions tries to onboard, hits billing uncertainty, asks support for help, and returns two days later with partial memory of the setup flow?

The second question is a system question. It needs state, memory, roles, environment constraints, and instrumentation. That is where agents are useful.

What customer journeys require#

Customer journeys are not only digital paths. They are service systems.

The Springer paper on agent models of customer journeys on retail high streets is about physical retail, but the framing transfers: customer experience happens through touchpoints, service-scapes, motion, waiting, proximity, grouping, sociality, and interactions with the surrounding environment. Digital products have the same kind of structure, just with different surfaces.

A customer does not only "complete onboarding." They interact with:

• permissions,
• pricing,
• account setup,
• docs,
• support,
• teammates,
• internal approvals,
• prior expectations,
• a memory of the last failed attempt.

If the simulation ignores those service constraints, it becomes a chatbot roleplay. If it models them, it becomes a rehearsal space for the journey.

The scenario contract#

For the onboarding scenario, I would start with a small contract before running any agents:

scenario_id: b2b_onboarding_permissions_billing_support
decision_under_test: "Which onboarding handoff should we research first?"
agents:
  - role: account_owner
    goal: "Activate the workspace for a three-person team"
    constraints:
      - "Cannot grant admin permissions without IT approval"
      - "Needs cost confidence before inviting teammates"
    memory:
      - "Tried setup two days ago and abandoned at SSO"
environment:
  available_actions:
    - read_pricing_page
    - read_setup_docs
    - invite_teammate
    - request_admin_help
    - open_support_chat
    - abandon_setup
  unavailable_actions:
    - bypass_permissions
    - see_internal_support_notes
validation_claims:
  - claim: "Permissions block activation"
    required_signal: "Admin logs, setup funnel drop-off, or moderated study"
  - claim: "Pricing uncertainty delays invites"
    required_signal: "Sales notes, pricing-page analytics, or interview evidence"
stop_condition: "Agent activates, abandons, or reaches unsupported state"

The contract does two jobs. It tells the simulation what world it is allowed to inhabit, and it tells the team which claims are eligible for validation. If the run produces a story outside that contract, the story may be interesting, but it is not evidence for the decision.

The simulation loop#

The loop I would use is small on purpose:

The decision can be many things:

• change the journey,
• instrument a missing step,
• run a usability study,
• rewrite a support handoff,
• narrow the launch audience,
• reject the simulation result as unvalidated noise.

The last option is important. A simulation that produces a plausible story but no testable decision is entertainment. It may be useful creative work. It is not research.

The evidence table#

Here is the acceptance table I would use before trusting a simulation result:

The table keeps the simulation honest. Every synthetic claim needs a real-world validation path. If no validation path exists, the claim should not drive a product decision yet.

What to instrument#

The simulation should emit traces like a product system, not just transcripts like a chat demo.

I would capture:

scenario_id
agent_id
agent_role
agent_goal
journey_step
available_actions
selected_action
blocking_constraint
retrieved_memory
supporting_evidence
confidence
timestamp

The fields are boring because the point is auditability. If an agent abandons onboarding, I want to know which role it was playing, what it believed, which action it selected, what constraint blocked it, and what memory it brought forward.

Without that trace, the team will be tempted to read the agent's final complaint as evidence. The trace is what turns a synthetic complaint into a research question.

Failure modes#

Stanford HAI's 2025 brief on simulating human behavior with AI agents is optimistic about simulation as a research tool, but it also names risks around over-reliance, privacy, and reputation. Those risks show up quickly in product work.

Convincing but inaccurate behavior#

The agent says something a real customer might say. The team recognizes the complaint. Everyone nods. The simulation feels validated because the output is familiar.

That is not validation. It is recognition.

The fix is to tie every important behavior to a validation signal before it enters the roadmap.

Over-reliance#

Simulation is cheaper than research, so the team runs more simulations and fewer studies. The practice starts as rehearsal and becomes replacement.

The fix is policy: simulations generate hypotheses. Real customers validate or reject them.

Privacy leakage#

If real customer transcripts, support tickets, or sales notes shape agents, the simulation inherits privacy obligations. Synthetic outputs can still reveal sensitive patterns if the input data was not handled correctly.

The fix is data minimization, consent discipline, redaction, and clear separation between illustrative examples and customer-derived evidence.

Persona drift#

The agent starts as "billing admin at a mid-market company" and becomes whatever the prompt rewards. After enough prompt edits, the persona reflects the team's anxieties more than the customer's reality.

The fix is a persona contract: role, goal, constraints, memories, allowed tools, and known unknowns. Change it deliberately. Version it.

Environment fantasy#

The simulation gives agents perfect access to docs, clean navigation, or a support path that the product does not actually expose. The result looks like a better customer experience because the simulated service is better than the real service.

The fix is to model the environment as it exists, not as the team wishes it worked.

Where validation enters#

Simulation validation is its own discipline. R. G. Sargent's paper on verification and validation of simulation models is a useful anchor because it separates questions about whether the model was built correctly from whether the model is valid for its intended use.

A technically correct simulation can still be invalid for the decision. The agents may follow the rules. The scenario may run. The traces may look coherent. But if the environment omits the real approval path, the simulation is not valid for an enterprise onboarding decision.

I would use three gates:

Only the third gate should change the roadmap by itself. The first two decide what to investigate.

What to do differently#

Do not ask agents to be customers.

Ask them to make your journey assumptions executable.

Give them roles, memory, constraints, and a service environment. Run scenarios. Capture traces. Convert surprising behavior into research questions. Validate against product data, support signal, sales notes, and real user research.

The value of customer experience simulation is not that it predicts customers perfectly. It does not. The value is that it lets the team rehearse a service system before the system touches people, and it makes the next real test more precise.

Use simulation to decide what to test with real users, not to avoid testing with real users.