Study Structure

Set Up Conditions

Chamber lines represent between-subjects conditions (e.g., treatment vs control). An experiment can have multiple chamber lines, and each participant is assigned to exactly one based on the experiment's assignment method.

Study Structure

Add Chambers & Segments

A chamber is a container where matched participants interact together. Each chamber holds one or more segments — the individual activities participants complete in sequence. Participants are matched once at chamber start and stay grouped across all segments within it.

Segment Types

Chamber Parameters

Study Structure

Embed Activities in Chat

The displayMode setting on a segment controls how it appears to participants:

• Standalone (default) — replaces the current view entirely.
• Embedded — renders as an overlay on top of a running chat segment. Chat continues beneath.

Non-chat segments placed after a chat segment in the timeline become embedded children of that chat. They activate while the parent chat is running, appearing as overlays that participants interact with without leaving the conversation.

Completion Behaviours

Study Structure

Configure Timing & Transitions

Timing Fields

Transition Modes

Additional fields: transition.countdown (ms before advance) and transition.allowEarlyAdvance (boolean, whether participants can skip ahead).

Study Structure

Add Surveys

Surveys can be placed at three levels in the experiment structure:

• Global pre/post — shown once at the start or end of a participant's session. Use for demographics, consent, or debrief.
• Chamber pre/post — shown before matching or after a chamber ends. Use for manipulation checks or mood measures.
• Segment survey — embedded in the chamber timeline as a segment of type survey. Use for in-context questionnaires.

Surveys use the Survey.js JSON format. You can design surveys visually in the Survey.js creator and paste the JSON into the experiment builder.

Participants & Roles

Add Human Participants

Define human participant slots in each chamber. Participants are real people interacting through the browser. Each slot specifies how the participant's identity is determined.

When participants join an active experiment, they enter a matching queue. The system groups them into chatrooms based on each chamber's slot requirements. See Property-Based Matching for advanced configuration.

Participants & Roles

Add an Agent

An agent is an automated participant whose behaviour is defined by its triggers. Triggers can produce responses in three ways:

• Scripted responses — fixed messages or random selection from an array. No API calls.
• LLM-driven responses — the llm-driven trigger type sends context to an LLM for a dynamic response.
• Mixed — combine both: keyword triggers with fixed replies plus an llm-driven fallback.

LLM Configuration

LLM agents respond with {content, rationale, actions}. content is the message (null = stay silent). rationale is logged for research. actions is mediator-only. See Simulation for trigger details.

Participants & Roles

Set Up a Mediator

The mediator role observes all messages and broadcasts information to the group. Mediators can control chat flow by disabling and enabling chat or prompting specific participants to respond.

Participants & Roles

Set Up a Processor

The processor role assists communicators privately during draft time. Processor feedback is only visible to the paired communicator — other participants do not see it.

Phase Definition

Simulation

How Triggers Work

A trigger is a condition-response pair that fires when something happens in the chatroom. Every trigger has three parts:

• Condition — what to watch for (a trigger type + value).
• Response or Action — what to do when matched (send a message or submit to a segment).
• Lifecycle controls — cooldown, maxTriggers, priority.

Trigger Definition Fields

Simulation

Trigger Types Reference

Simulation

Trigger Responses

When a trigger fires, it can send a message to the chatroom.

Response Fields

LLM-driven path: For llm-driven triggers, context is sent to the LLM which returns {content, rationale, actions}. content is the message (null = stay silent). rationale is logged only. actions is mediator-only (see Mediator Actions).

Simulation

Segment Actions

Beyond sending messages, triggers can submit to interactive segments via the segmentAction field. This enables bots to participate in votes, rankings, and other interactive activities.

Supported segment types: selection (including slider mode), ranking.

Data Modes

Referenced Strategies

Submission Metadata

Simulation

Mediator Actions

Mediator-role agents can issue actions that control the chat flow, returned in the actions array of their JSON response.

Example Action

{
  "action": "disable_chat",
  "target": "participant_name",
  "rationale": "reason (logged)",
  "release_conditions": {
    "type": "any",
    "conditions": [
      { "type": "timeout", "value": 30000 },
      { "type": "keyword_mentioned", "value": "ready" }
    ]
  },
  "on_release": {
    "notify": true,
    "message": "You can now type again."
  }
}

Simulation

Chaining & Lifecycle

Triggers can be linked together to create multi-step behaviour:

• chainTrigger — fires a follow-up trigger after the current one completes.
• chain-only — a trigger type that only fires when chained from another trigger.
• after-bot-message — fires when another bot sends a message (cross-bot coordination).
• event-monitor — monitors events and chains based on observations.

Lifecycle Controls

Conditional Logic

Participant Properties

Properties are key-value pairs that accumulate on participants throughout their session, used for matching, chamber visibility, and dynamic assignment.

Condition Operators

Conditional Logic

Route by Survey Response

Two mechanisms let you route participants based on survey answers:

Conditional Logic

Show/Hide Chambers

Each chamber can define visibilityConditions — an array of property conditions that must ALL be satisfied (AND logic) for the chamber to appear in a participant's run plan.

Visibility Condition Fields

Conditional Logic

Property-Based Matching

Chamber slots can define requiredProperties. The matching algorithm uses most-constrained-first ordering: slots with the fewest eligible candidates are filled first, with FIFO within tiers.

Required Property Fields

Running & Monitoring

Launch Your Experiment

When your experiment design is ready, change its status from draft to active in the Experiment Builder. This enables participant access and starts the matching system for your experiment.

Data Collection Mode

Choose between two data collection modes when activating:

Sharing the Participant URL

Share the participant URL with your participants: /experiment/[experimentId]. When the first participant joins, they progress through: session initialization, identity setup, global pre-survey, chamber line assignment, and into the matching queue.

External Platform Integration

When recruiting from external platforms (e.g., Prolific, MTurk), append participant IDs via query parameters. The parameter name is configurable via participantIdParam (defaults to pid). For example: /experiment/[experimentId]?pid=PROLIFIC_PID

Content Filtering

For experiments using LLM agents, content filters are available in experiment settings. These include profanity filtering, PII detection, and harmful content filters to help maintain safe interactions.

Running & Monitoring

Monitor Live Sessions

The Experimenter Dashboard provides real-time visibility into your running experiment. Access it from /dashboard/experiment/[experimentId].

Dashboard Features

The dashboard displays active sessions with real-time participant status, chatroom activity, and connection information. You can see which participants are in which chambers, their current segment, and how long they have been active.

Matching Queue

View who is waiting in the matching queue, how long they have been waiting, and which experiment they belong to. This helps you identify bottlenecks when participants are waiting too long for a match.

Alerts

The dashboard surfaces alerts for situations that may need attention: disconnected participants, long wait times in the matching queue, participant drop-outs, and idle sessions where no activity has occurred for an extended period.

Running & Monitoring

Manage Participants

From the dashboard you can take action on individual participant sessions.

Session Actions

Pause a session to temporarily suspend a participant's progress. Resume a paused session to let them continue. End a session to terminate a participant's run early. These actions are available per participant from the dashboard session list.

Participant Status

View each participant's current phase (e.g., identity setup, pre-survey, chamber execution), their chamber progress within the run plan, and their connection status (online, offline, or disconnected).

Chatroom Inspection

Inspect any active chatroom to view its contents: the live chat history, participant list, and current segment. This is useful for verifying agent behaviour and monitoring the quality of interactions during a live session.

Running & Monitoring

Export Data

Export your experiment data for analysis from the dashboard.

Formats

Data can be exported in JSON or CSV format.

Data Types

Completion Redirect

Configure a completionRedirectUrl in global settings to redirect participants to an external URL when they finish. The configurable participantIdParam is appended to the redirect URL so external platforms can match completions back to their records.

Examples

Two-Person Text Chat

The simplest experiment — two humans chatting in real time.

Examples

Human-AI Collaboration

One human paired with an LLM-driven agent for a conversational study.

Examples

Multi-Condition Study

A between-subjects design with 3 conditions: control, treatment-A, and treatment-B.

Examples

Mediated Group Discussion

Four humans with an AI mediator managing the conversation flow.

Reference

Experiment

Top-level container for a complete research study. Holds global settings, surveys, chamber line definitions, and bot templates. Each experiment has an owner and optional collaborators.

Reference

Chamber Line

A condition track comprising an ordered sequence of chambers. Participants are assigned to one chamber line based on the experiment's assignment method.

Reference

Chamber

A container for one or more sequential segments that matched participants progress through together. At runtime, becomes a chatroom. See Add Chambers & Segments.

Reference

Segment

A single activity within a chamber timeline. See Add Chambers & Segments and Embed Activities.

Reference

Participant

An entity in a chamber. See Add Human Participants and Add an Agent.

Reference

Roles

Functional capabilities assigned to any participant. See Mediator and Processor for role-specific configuration.

Reference

Triggers

Condition-response rules for agent automation. See How Triggers Work, Trigger Types, Segment Actions, and Mediator Actions.

Reference

Run / Session

A single participant's end-to-end journey through an experiment. See Launch Your Experiment.

Reference

Chatroom

Runtime instantiation of a chamber, created when participants are matched. See Monitor Live Sessions.

Reference

Matching

The runtime process that groups participants into chatrooms. Runs every 5 seconds. See Property-Based Matching.