Simulation Personality Library & Suites

Overview

The Simulations page covers the core personality/scenario/simulation/run/review workflow, including how to define a one-off personality inline. This page covers the layer built on top of that: turning personalities into a reusable library, and grouping multiple simulations into a suite for batch regression testing.

A personality is a full assistant configuration — model, voice, and system-prompt-driven behavior — that defines how the AI tester behaves during a simulation. Rather than being redefined inline every time, a personality can be created once as an independent, reusable resource and then referenced by ID across many different simulations.

Create a personality and save its returned ID for reuse:

curl -X POST "https://api.sulus.ai/eval/simulation/personality" \
  -H "Authorization: Bearer $SULUS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Impatient Customer",
    "assistant": {
      "model": {
        "provider": "openai",
        "model": "gpt-4o",
        "messages": [
          {
            "role": "system",
            "content": "You are an impatient customer who wants quick answers and may interrupt if responses are too long."
          }
        ]
      },
      "voice": {
        "provider": "cartesia",
        "voiceId": "sonic-english"
      }
    }
  }'

The response includes the personality's id — keep it, since this is what you'll reference from any simulation that should use this tester behavior.

When creating a simulation, pass the saved personality's ID as personalityId instead of defining the personality inline:

curl -X POST "https://api.sulus.ai/eval/simulation" \
  -H "Authorization: Bearer $SULUS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Impatient Customer - Book Appointment",
    "personalityId": "<personality-id>",
    "scenarioId": "<scenario-id>"
  }'

Because the personality is a standalone resource, the same one can be paired with as many different scenarios as you need, without redefining the tester's behavior each time.

A recommended starting set of personality archetypes to build your library around:

A suite groups multiple simulations into a single batch that runs together, so every personality/scenario pairing you've built can be executed as one regression pass:

curl -X POST "https://api.sulus.ai/eval/simulation/suite" \
  -H "Authorization: Bearer $SULUS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Appointment Booking Regression Suite",
    "simulationIds": [
      "<simulation-id-1>",
      "<simulation-id-2>",
      "<simulation-id-3>"
    ]
  }'

A useful organizational pattern is to keep suites scoped by workflow — for example, separate suites for "Booking Tests," "Cancellation Tests," and "Rescheduling Tests" — and run the relevant suite whenever that part of your assistant's configuration changes.

For the core simulation mechanics — the personality/scenario/simulation/run/review workflow and evaluation comparators — see the Simulations page. This page is specifically the reusable-library and suite-batching layer built on top of that workflow.