User Guide

Delstorm is a multi-agent experimentation platform. You design experiments where AI agents — each with their own persona, backed by an LLM of your choice — engage in structured discourse across configurable rounds.

Each round has a condition prompt that sets the social scenario: a debate topic, a collaborative task, a negotiation, a simulated classroom, or any situation you can describe. Agents respond based on their personas and the conversation history. You control the interaction pattern, number of turns, which agents participate, and how long responses should be.

Use cases include:

• Simulating academic debates grounded in real papers
• Modeling stakeholder negotiations with distinct interests
• Exploring how different ideological perspectives interact on a topic
• Testing how agent personas, temperature, or round structure affect discourse outcomes
• Running batch experiments to observe variance across identical setups
• Generating structured multi-perspective analysis of documents or topics

To run your first experiment, follow these steps:

1. 1.

   Create an account

   Click "Sign In" in the top right. If you don't have an account, click "Create one" to sign up with your email and password. You'll receive a confirmation email — click the link to activate your account, then sign in.

2. 2.

   Check your providers

   Go to Settings. You should see at least one provider already configured (e.g., "deepseek" or "claude"). If not, you'll need to add one — see Setting Up Providers below.

3. 3.

   Create an experiment

   Go to New Experiment. Give it a name, select your default provider (e.g., "deepseek"), enter the default model name (e.g., "deepseek-chat"), and add at least one agent and one round.

4. 4.

   Launch

   Click "Launch Experiment" and watch the agents respond in real-time. Results appear as they're generated.

Quick test: Try 2 agents, 1 round, "Short" response length. This will finish in under a minute and let you verify everything works before building a larger experiment.

Delstorm’s appearance control changes presentation only. It does not alter your account, permissions, experiments, assignments, or saved work.

• System follows your device’s current light or dark appearance and updates if the device setting changes.
• Light uses the warm paper interface.
• Dark uses the neutral charcoal interface.

When signed in, open the appearance menu in the top navigation or use the Appearance section in Settings. On the sign-in and create-account pages, use the compact appearance button in the top bar.

Your selection is stored only in this browser and remains after you sign out. It is not synchronized to your account or shared with other users.

A provider is an LLM backend that powers your agents. Providers are configured in Settings.

Shared vs. Personal Providers

Your administrator may have pre-configured shared providers (like Claude) that are available to all users automatically. These appear in your provider list without any setup. You can also add your own personal providers — these are visible only to you.

Provider Types

Per-Agent Provider Override

By default, all agents in an experiment use the experiment's default provider. However, you can override this on individual agents — for example, to have one agent powered by Claude and another by GPT-4. Set this in the "Provider Override" dropdown on each agent card.

The Experiment Builder is a three-pane workspace: your rounds (plus an "⚙ Experiment setup" entry) list in the left rail, your agents list in the right rail, and whichever item you pick opens as a full editor in the center. On smaller screens the rails hide, every section simply stacks down the page, and the "+ Add Agent" / "+ Add Round" buttons appear inline beneath their lists.

1. 1.

   ⚙ Experiment setup (the default view)

   Name your experiment, select the default provider (e.g., "deepseek"), and enter the default model ID (e.g., "deepseek-chat"). The model ID must match what the provider expects. This view also holds Document Context (optional): upload a document to extract themes and generate grounded agent personas — see Document-Grounded Personas.

2. 2.

   Agents (right rail)

   Define the participants. Click "+ Add Agent" at the bottom of the right rail; the new agent's editor opens in the center. Click any agent in the rail to edit it. See Agents & Personas.

3. 3.

   Rounds (left rail)

   Define the sequence of interactions. Click "+ Add Round" at the bottom of the left rail; reorder rounds with the ↑/↓ buttons on each rail entry. See Rounds, Conditions & Settings.

4. 4.

   Bottom bar: Launch / Save / Batch + drawers

   "Launch Experiment" runs it once. "Save Design" stores the config for reuse, updating the design you loaded rather than duplicating it; "Save as new" beside it always creates a separate copy. "Batch Run" runs it multiple times. Two panels slide in from the right: Designs (load a saved design, start from a built-in template, import/export/delete — templates that bundle documents are first imported into your saved designs so their documents land in your library) and Data extraction (see Data extraction; a green dot on the button means extraction is configured).

If Launch or Save flags a problem, the builder jumps to the item that needs fixing and highlights the field in red.

Agents are the participants in your experiment. Each agent is defined by these fields:

The Prompt Library is a built-in collection of course prompts you can reuse instead of retyping. It ships with the Classical Social Theory corpus — 91 prompts from SOCB42 and SOCB43 covering Smith, Marx, Wollstonecraft, Tocqueville, and Weber. It is instructor-only: students never see it.

Filter by theory, by assignment, or by prompt kind, and search across both titles and prompt text. There are four kinds:

• Agent — a persona, inserted into an agent's Persona field.
• Round — scene-setting instructions, inserted into a round's Condition Prompt.
• Moderator — end-of-round instructions, inserted into a round's Completion criteria.
• Transition — describes moving from one round to another based on what happened, inserted into a round's Transitions section as its Decision guidance.

In the Experiment Builder, open Prompt library in the right-hand agents rail. Pick a prompt, choose the agent or round to receive it, and click Insert. Insert appends to the chosen field rather than replacing it, so anything you have already written is kept.

Every round remains available as a target for a Moderator prompt. If the chosen round currently ends after its set turns, the action says Enable moderator ending + insert: it changes the existing Round ends control to When the moderator decides, reveals Completion criteria, and inserts there. Turns remains the hard cap, and you still choose the Moderator before launch. Nothing is changed until you click that explicit action.

In the assignment Studio the same library sits under Prompt library. While the design editor drawer is closed it stays in Copy mode, so you copy a prompt for reference. Open the design editor to edit an agent or round and the same library switches to Insert mode: it inserts into the drawer card you have focused and appends to that field, exactly as it does in the Builder. On a wide screen the library stays usable beside the open drawer; on a narrow screen it rides the drawer's own Prompt library tab. Closing the drawer returns it to copy mode. Transition prompts insert into the round's Transitions section in either mode: because guidance alone does not make a design branch, the insert also reveals that section and starts one empty condition row for you to fill in.

Some prompts are labelled Used by: Alpha, Beta, Gamma. That means one prompt is shared across several agents or rounds in the original course material. A visible source note preserves and explains a known issue in the source material before you reuse that record; it does not silently rewrite or remove the source prompt. The library is currently read-only — you cannot add or edit your own prompts in it yet.

If you built an assignment with the Assignment Builder GPT, you can bring its draft into Delstorm at Import assignment draft. Paste the AssignmentDraftV1 JSON the GPT produced, or upload it as a file.

The quickest way in is from the classroom itself: open a classroom you instruct, and under New assignment choose Import a draft from the Assignment Builder. Arriving that way carries the classroom with you, so you do not have to pick it again later.

Delstorm checks the draft on its own server against the exact schema the GPT was configured with, then shows you what it would create and anything blocking it. Nothing is created by that check. Saving stores the draft in your private intake inbox — it does not create an assignment.

The intake inbox (Saved drafts, also linked from each classroom) lists every draft you saved. Opening one re-checks it fresh and shows the full record: instructions, agents, rounds, what students will do, the builder's sources and assumptions, and any blockers. Submitting a revised draft with a higher revision number updates the same intake and keeps the older revisions as history; submitting the same draft again is recognized and stored only once. When a draft is not ready, Copy feedback for the builder gives you a structured note to paste back into the GPT.

When a draft is ready, choose one of your classrooms on the review page and create the assignment. It is always created unpublished. You land in Studio to review and edit it, and publishing stays a separate deliberate step — importing a draft never exposes anything to students. Each intake can create one assignment; deleting an intake never deletes an assignment already created from it.

Two things worth knowing. Delstorm re-checks the stored draft when you create the assignment, not only when you saved it, so nothing stored is trusted stale. And uploaded source files do not travel: the draft names the documents it used, but the DOCX, PDF, or notes themselves stay in ChatGPT. If a design points at a document you have not uploaded to your Delstorm Document Library, creation is blocked rather than quietly dropping it.

A draft the GPT marked as blocked or awaiting your decision can still be saved and reviewed, but offers no create button until you resolve it with the GPT and submit a new revision. A draft still being interpreted cannot be saved at all. The GPT cannot write into Delstorm by itself — this manual import is the supported path.

You can upload a document (PDF, TXT, or MD) to automatically extract themes, positions, and stakeholders, then generate agent personas grounded in the document's actual content.

Step-by-step:

1. 1.

   In the Experiment Builder, go to the "Document Context" section. Upload your file and select which provider to use for analysis (Claude is recommended for best extraction quality).

2. 2.

   Click "Analyze Document". The LLM reads the document and extracts: title, summary, key themes, distinct positions/stances, stakeholders, key arguments, and domain terminology. This takes 10-30 seconds.

3. 3.

   Review the extraction results. The themes, positions, and stakeholders should give you ideas for what agents to create.

4. 4.

   Add agents and give them relevant names and specialties (e.g., if the document is about left-right politics, create "Left_Coalition_Theorist" with specialty "Progressive policy coherence").

5. 5.

   On each agent card, click "Generate Persona from Document". The LLM creates a detailed persona for that specific agent, using the document's themes, arguments, data points, and terminology. The persona is tailored to the agent's name and specialty — not a generic summary.

6. 6.

   Review and edit the generated personas. The generation is a starting point — you can refine it, add specific instructions, or combine it with your own text.

The Document Library provides persistent storage for documents you want to reuse across experiments. Unlike the ephemeral document upload in the experiment builder (which is lost after analysis), library documents are permanently stored in your account.

Uploading Documents

Go to Library and upload a PDF, TXT, or MD file. The document is automatically analyzed by the LLM — themes, positions, stakeholders, and key arguments are extracted and stored alongside the full text. Supported files up to 10MB.

Using Documents in Experiments

Library documents can be attached at two levels:

Document Depth

For both round-level and agent-level documents, the "Document Depth" setting controls how much of the document is injected into the prompt:

Example: Section-by-Section Analysis

Upload an academic paper to your library, then design rounds that walk through it:

Each round's condition prompt guides the excerpt extraction, so agents see the parts of the paper most relevant to that round's focus.

Each round represents a phase of the experiment. Rounds are independent by default — you create continuity through how you write your condition prompts.

The Condition Prompt

This is the most important part of a round. It sets the social scenario that all participating agents operate within. Think of it as setting the stage for a scene.

Round Settings

On the round card these controls are grouped into three sections: Turn-Taking (speaking order, first speaker, turns, moderator, when the round ends), Memory & Context (context depth, context window, overflow, private self-reflections), and Output & Participants (response length, participating agents, reference document and depth) — so it's clear at a glance which settings shape how the group takes turns versus what each agent remembers. Each section starts collapsed — click a section heading to expand it (and again to hide it) — so you can focus on one group at a time and see at a glance that the settings are organised into expandable groups.

Each round uses one of five interaction patterns that define how agents communicate:

Tip: You can use different patterns across rounds in the same experiment. Start with Blind Parallel (to capture uninfluenced positions), then Free Discussion (to let agents interact), then Debate (to force a conclusion).

On a Free Discussion (or Custom) round, the "Speaking order" control on the round card decides who speaks next. The other patterns — Debate, Chain, Blind Parallel — have their own built-in orders and ignore this control, so it only appears for Free Discussion and Custom.

Turns become a per-speaker budget

For every order except Round-robin — so including Sequential — the "Turns per round" field relabels to "Turns per speaker". The number is now a per-agent budget, and the round's hard cap is that number times the number of participants. Because the moderator or the hand-off can re-call or skip an agent, a speaker may take several turns while another takes none — the cap is the ceiling, not a promise that everyone speaks the same amount. The round still ends early if its moderator decides it's complete.

Each utterance streams into its own bubble in the live and completed views, so a re-called speaker reads as a fresh turn rather than appended text.

A moderator is a dedicated agent that guides a round without taking part in the debate. It frames the scene, comments between turns, and wraps the round up — like a panel chair or a narrator.

Assigning one

On the round card, use the "Moderator (optional)" dropdown. It lists every agent you've defined and reads — none — until you pick one, so add your agents first. The same agent can moderate one round and participate normally in another.

What the moderator does

• It doesn't participate. The moderator is removed from the round's participant list, so it never argues a position or takes a turn.
• It speaks to guide the round: an opening message and a closing message always, plus comments between turns on some speaking orders, and, when it drives the speaking order itself, a short message before each turn naming who speaks next and why.
• It sees everything. The moderator reads the full, untruncated round so far (it ignores the round's Context Depth setting).
• Its comments steer the room. Moderator messages are passed to the participants on their next turn under a "Moderator guidance" heading — so a nudge or a question shapes what comes next.
• Blind Parallel is the exception. In a Blind Parallel round agents see only the condition prompt, so moderator guidance doesn't reach them (the moderator still speaks and its messages are still recorded).

Moderator messages render as their own 🎙 moderator bubbles in the live and completed views, and they're included in the exported transcript.

The default narration, and the end-of-round summary

Assigning a moderator to a round assigns a fixed script, not a personality that may or may not speak. Every moderated round gets an opening message that sets the scene and poses the central question, and a closing message that synthesizes the discussion and concludes. In between, the moderator may interject, depending on the round's speaking order: some orders give it a short comment between turns, and when the moderator drives the speaking order itself it speaks before each turn to name who goes next and why. Other orders produce no between-turn narration at all. The close always happens, and it is an extra utterance: it does not count as one of the round's turns, so the closing synthesis is never paid for out of the participants' turn budget.

That closing synthesis is the platform's instruction to the moderator, not something the agent decided to do, so the end-of-round summary many designs show is expected behaviour rather than drift. When the round's ending is set to "When the moderator decides" and you have written completion criteria, the close is also told to say what it observed that satisfied those completion criteria, or which criteria were still unmet if the round hit its turn cap instead. The criteria box is optional: leave it empty and the close is a plain synthesis with no met-or-unmet verdict. If the round branches, the transition announcement ("Moving to ...") is recorded as one more moderator message after the close, so the reason the run took that path sits in the transcript beside the summary.

This is not configurable today: there is no setting that turns the closing summary off or rewrites it. If you want a round with no narration and no summary, do not assign a moderator to that round; the round then runs on its turn count with participant turns only. To shape the summary rather than remove it, write the moderator's persona to say how it should close.

Every round card has a "Round ends" control that decides when the round stops. There are two options.

Turns is always the cap

Even with "When the moderator decides", the turn count you set stays the hard cap — the round can end early on the moderator's call, but never runs longer than the set turns. So set Turns to the most you'd ever want, and let the moderator stop sooner.

Completion criteria are private while the round runs

The completion criteria are moderator-private during the round: the behind-the-scenes end-check is the only place they appear while agents are still speaking, so you can describe the outcome you're waiting for — even in the theory's own terms — without steering the discussion. The end-check itself is a separate, quiet call that never appears in the transcript. When the round closes, and only if you filled in the completion criteria, the moderator's closing message announces what it detected: which criteria it observed being met, or, if the turn cap ended the round first, which were still unmet. By then every participant turn is already spoken (and private self-reflections never see moderator messages), so the announcement explains the ending without influencing it. The box is optional: leave it empty and the round still ends on the moderator's own judgement, but the close is a plain synthesis with no met-or-unmet verdict.

Tick "Private self-reflections" on a round card and, after the round's turns finish, each participating agent writes a short private note on what just happened — from its own point of view.

What "private" means

• A reflection never enters the conversation — it isn't part of any response or turn, and no other agent can read it.
• An agent's own earlier reflections are fed back into that same agent's prompts in later rounds.

So a private inner state can build up across a simulation while the outward conversation runs separately. That's the point for any theory where what an agent feels should diverge from what it says — resentment or alienation accumulating, private doubts, an inner self at odds with a public role.

In the live, completed, and submission views, a round's reflections start collapsed at the end of the round behind a 💭 N private reflections toggle — click it to read them as dashed 💭 bubbles (see Navigating a Transcript). They're included in the exported transcript, so you can analyse them afterwards. Reflections always see the full round, regardless of the round's Context Depth setting.

Click "Launch Experiment" to start. You'll be taken to the live view.

The live view shows:

• A progress indicator while the experiment is running
• Live streaming of each agent's response as tokens are generated (you see the text appearing in real-time)
• Color-coded agent names for easy identification
• Round-by-round results with full markdown rendering (headers, bold, lists, etc.)
• Agent cards in a right-hand rail beside the transcript, so who's who stays in view while you read
• An action bar along the bottom with "Export JSON", "Data CSV", and "Evaluate"

Duration estimates:

Completed transcripts — the live results view, the guided workspace’s Analyze step, and the submission review page — share the same reading aids, so long runs don’t mean endless scrolling.

The Contents sidebar

• A docked Contents sidebar lists every round with its messages. Click a round heading to jump to that round; click an agent’s name to jump straight to that message — it briefly pulses so you can spot it.
• Analysis questions appear in the list at their place in the transcript, with a state icon: ✓ answered, ▸ current, ❓ open. Clicking one jumps to its ❓ marker in the transcript — the answers themselves live in the questions panel beside it.
• As you scroll, the sidebar highlights the message you’re reading.
• In a gated assignment, sections past your current question show as gray 🔒 locked rows — you can see the shape of what’s coming, but the content (and the question text) unlocks only as you answer.
• On narrow screens the sidebar tucks away behind a floating ☰ button.

Folding

• Rounds are collapsible — click a round’s divider to fold it away; click again to reopen. Rounds start open.
• Private reflections start collapsed at the end of each round behind a 💭 N private reflections toggle — click it to read them.

Message details (ⓘ)

Every message has a small ⓘ button next to the agent’s name. Click it for that message’s context: the agent’s persona, specialty, and model; the round, turn, and condition prompt; and — for newer runs — the time the message was generated. Press Escape or click anywhere else to close it.

Batch running lets you execute the same experiment design multiple times to observe how agent behavior varies across identical setups.

How to use:

1. Build your experiment as usual in the experiment builder.
2. Instead of "Launch Experiment", click the purple "Batch Run" button.
3. Enter the number of runs (1-20).
4. A batch progress page shows completion status for each run.
5. Click into individual runs to see their full results.

Each run uses the exact same configuration — same agents, personas, rounds, and conditions — but produces different responses due to LLM sampling variability. Runs execute sequentially (not in parallel) to avoid API rate limits.

Tip: Use "Short" response length for batch runs to save time and API costs. Run 3-5 short batch runs to identify interesting patterns, then do a single thorough run to explore them in depth.

Designs let you save and reuse experiment configurations:

• Save Design: Click the green "Save Design" button in the experiment builder's bottom bar. Your agents (including personas), rounds, and all settings are saved to your account. If you loaded a saved design first, this updates that design in place (one design, not a second copy under the same name) and the confirmation reads "Design updated".
• Save as new: Beside Save Design. This always creates a separate design, so it is how you branch a variant off a design you loaded while keeping the original untouched. The builder then follows the new copy, so the next Save Design updates the variant. A builder with nothing loaded creates a new design either way: a fresh page, and a built-in template with no documents (nothing is stored until you save it). A template that bundles documents is imported into your designs first, so the builder is then holding that imported design and Save Design updates it. Restoring unsaved work from a previous session keeps whichever design you were editing, so Save Design updates that one, but only once Delstorm has confirmed that design is still in your list. If you deleted it in the meantime, or if that check cannot run (your saved designs failed to load just then), the restored work comes back unattached and saving creates a fresh design instead. Either way the work itself is never lost. Saving into a design that no longer exists is refused with a message rather than reported as a success, so use "Save as new" to keep the work.
• Load Design: Open the Designs drawer from the builder's bottom bar, select a saved design from the dropdown and click "Load". All fields are populated with the saved values, and a note in the drawer reminds you that Save Design will now update this design. Every dropdown that lists your designs (here, the Studio's attached design, and a classroom's attach and share pickers) labels each one with its name and the date you last saved it, most recently saved first.
• Delete Design: In the same Designs drawer, select a design from the dropdown and click "Delete" to remove it.

Sharing designs with other users

You can share an entire experiment setup — agents, rounds, and the documents they reference — with another Delstorm user (or with yourself on a different account) via JSON export/import:

• Export: In the Designs drawer, select a saved design and click "Export". A <name>.delstorm.json file is downloaded. By default, every referenced document (from rounds and from agent-level personal documents) is bundled inside the file so nothing is lost on the other end.
• Import: In the Designs drawer, click "Import" and choose a .delstorm.json file. The design is added to your list (suffixed with "(imported)") and auto-loaded into the builder. Any bundled documents that don't already exist in your library are added to it.

Note: export files can be large if the design references big documents. There's a 25 MB cap on import uploads.

Click "Export JSON" on any completed experiment to download the full results. The JSON file includes:

• Experiment metadata (name, duration, session ID)
• Agent specifications (names, personas, temperatures, providers)
• All rounds with condition prompts, interaction patterns, and full agent responses
• Turn-by-turn data for multi-turn rounds
• Timing data per round

The exported JSON can be used for further analysis in Python, R, or any data processing tool.

The Evaluate page lets you analyze completed experiments by defining structured evaluation fields and running a hybrid parser + LLM extraction system.

When to Use Evaluation

Evaluation is post-hoc and on-demand — you run it after an experiment completes, not as part of the experiment design. This means you can evaluate the same experiment multiple ways, or decide what to measure after seeing the results.

Access the evaluate page from:

• The "Evaluate" link in the navigation bar
• The "Evaluate" button on any completed experiment's results page
• The "Evaluate All Runs" button on a completed batch page

How It Works

The evaluation system is hybrid — it combines two approaches:

The parser runs first. The LLM runs second, informed by what the parser found. Results are merged with confidence tracking so you know whether each value came from the parser (deterministic), the LLM (inferred), or both (confirmed).

Field Types

Source Filtering

Each field can optionally specify a source round and/or source agent. When set, the parser and LLM only look at that portion of the transcript. This is useful when you have a dedicated evaluation round — you want scores from the evaluator agent's output, not from the full debate.

Evaluation Templates

Save your field definitions as reusable templates. If you always evaluate political debates with the same criteria (Consensus Score, Winner, Key Arguments), save those fields as a template and load it for each new evaluation. Templates are saved to your account.

Batch Comparison

When evaluating multiple experiments (from a batch run), results display as a comparison table — fields as rows, experiments as columns. Numeric fields show an average across runs. This is the core tool for measuring variance: "Did the agents reach consensus more often in runs with lower temperature?"

Example Workflow: Evaluator Agent

A powerful pattern is to include a dedicated evaluator agent in your experiment:

1. Create an agent named "Evaluator" with a persona like "You are an impartial judge who evaluates the quality of discourse."
2. Add a final round with only the Evaluator participating, with a condition like: "Score the preceding discussion on: consensus (1-10), argument quality (1-10), and name the strongest contributor."
3. After the experiment, go to Evaluate and define fields: "Consensus (number, 1-10, source agent: Evaluator)", "Argument Quality (number, 1-10, source agent: Evaluator)", "Strongest Contributor (choice, source agent: Evaluator)".
4. The parser will extract the scores directly from the evaluator's structured output.

Confidence Badges

The Evaluation page is something you run by hand after an experiment. Data extraction is the same idea built into the design, so the metrics you care about are pulled out of every run automatically.

Setting it up

In the experiment builder, open the "Data extraction" drawer from the bottom bar (a green dot on the button means extraction is already configured). Then:

1. Click "+ Add field" for each thing you want to measure. A field has a Name, a Type (Number, Text, Scale, Boolean, or Choice), and a Description of what to extract. A Choice field also takes its allowed values, one per line.
2. Optionally add "Extraction instructions" to guide the evaluator.
3. Tick "Auto-extract after each run".

Now, whenever a run (or each run in a batch) finishes, the hybrid evaluator scores those fields and stores the result on the experiment — in the same place the Evaluate page reads from, so the Evaluate view shows it with no extra step. If extraction ever fails it's logged but never fails the run; your experiment still completes normally.

Exporting to CSV

Once an experiment has extracted data, you can download it as a spreadsheet from the experiment's data endpoint. There's no download button yet — open the URL directly in your browser:

The CSV opens cleanly in Excel, Google Sheets, Python, or R for further analysis.

Delstorm includes a built-in AI assistant. Look for Pal, the small assistant character, in the bottom-right corner of most pages; in the Assignment Studio he sits in the bottom-left corner instead, so he stays clear of the design editor drawer. You need to be signed in to use it. The panel header has a context selector that always offers Platform help, plus one entry for each of your classrooms whose instructor turned on a Course TA. Each context keeps its own conversation (saved in your browser for 7 days; the trash icon clears only the active context's chat).

Whichever context is selected, the assistant still sees the page you are on, and on the experiment builder page it can see your work in progress — a "Design shared with assistant" chip appears when your current design is attached, so its answers can target what you are actually building. Every context answers only from its curated knowledge base and will say so plainly when the material doesn't cover something.

Classrooms connect instructors and students for coursework: instructors post assignments built on experiment designs, students run them and submit their results, and anyone in the class can share designs. The Classrooms page lists every classroom you teach or have joined.

There are two roles. Instructors create classrooms, post assignments, and grade submissions — instructor accounts are granted by the platform administrator (an email allowlist), so contact the admin if you need one. Everyone else is a student.

Joining a classroom

Your instructor gives you a join code. On the Classrooms page, enter it in the "Join code" box and click Join. The classroom appears in your list; open it to find three tabs: Assignments, Shared Designs, and Members. You can leave a classroom from the Members tab.

Working on an assignment

1. 1.

   Open the assignment from the classroom's Assignments tab. It shows the instructions, due date, and any resource links.

2. 2.

   Click "Start assignment". The attached design template — agents, rounds, and any referenced documents — is imported into your own saved designs, ready to load in the experiment builder. Clicking it again does not make a second copy: you are handed the copy you already have, edits and all, and renaming it makes no difference (Delstorm records which assignment the copy came from). To start over from the instructor's version, delete your copy first.

3. 3.

   Run the experiment as usual, adjusting the design first if the instructions ask you to.

4. 4.

   Back on the assignment page, pick the completed experiment, optionally add notes for your instructor, and click "Submit".

For instructors

Sharing designs

Anyone in the classroom can share a saved design from the Shared Designs tab — pick one of your designs and click "Share with classroom". The share is a snapshot bundled with the design's documents, so later edits to the original don't affect it; share again to distribute an updated version. Classmates click "Copy to my designs" to import it — bundled documents land in their library (deduplicated against what's already there), and provider references they don't have configured are cleared, just like a design import.

On a multi-run submission, select a variant in the run tabs. The Variant changes card reconstructs the student’s editable-field changes from the inputs saved with that submission. It is a read-only review aid and does not change the submission, its grade, or any experiment.

The card opens in Stacked layout. Choose Side by side to compare the reference run and selected variant in adjacent columns, with the Changed, Added, or Unchanged marker between them. The layout choice changes presentation only. It does not edit the stored inputs, and complete text wraps instead of being truncated on narrow screens.

A step later in a chain can show two clearly labeled blocks. Changes from <source run> shows what changed from the run that supplied this variant’s starting values. Changes from Baseline shows the cumulative change from the first run. When the source is Baseline, the two references collapse into one Baseline block.

If a locked or empty run sits immediately before the variant, the source label reaches back to the nearest earlier run with saved inputs. This keeps the label aligned with the values the student actually inherited.

In the Stacked layout, prompt and other text fields put the complete source and current values inside an expandable disclosure, while typed settings such as choices, numbers, toggles, first speaker, and moderator read inline as old value to new value. In Side by side, every field type appears as source value, status, and current value in adjacent columns, with complete text wrapping instead of truncating. Every row says Changed, Added, or Unchanged; color is only a secondary cue. A no-op variant says that there are no changes from its reference instead of leaving a blank panel.

Some assignments open in a workspace instead of the full builder, a focused, three-step page that walks you from setup to submission. You'll see an "Open workspace" button on the assignment when your instructor has set one up; assignments without one use the regular builder. Some workspaces are open: the instructor left no editable slots, so Set up has nothing to fill in. You review the locked design, run it, and everything else (marking moments, answering questions, submitting) works the same.

The three steps

Running variants (multi-run assignments)

If your instructor built a guide into the assignment, a "📖 Guide" button appears on every step of the workspace (and on the assignment page itself). Click it to slide open a drawer on the right with the instructor's step-by-step guidance, grouped under General, Set up, Run, and Analyze & submit. Every section stays visible on every step: whichever sections match the step you are on open automatically, and the rest are collapsed but one click away, so you can peek ahead or look behind whenever you want. That is on purpose, not a leak; the guide is reference material for the whole assignment, not a script that hides what comes next. Move to another step with the drawer open and it repaints for that step. Close it with Escape, the ✕, or by clicking outside. Guide edits show up immediately, so if your instructor updates it mid-assignment you'll see the latest version next time you open it.

When an assignment has a design attached (see Classrooms), you can turn it into a workspace: students run the design and answer questions in the focused three-step page. Runs, analysis questions, and the required-notes minimum are available whether or not you make any field editable; they reach students as soon as a design is attached. Making design fields editable (the Student agency section's "Editable design fields" panel) is a separate, optional choice that adds student-filled slots to Set up.

Setting it up

Save the assignment and students will see "Open workspace". You get a "Preview workspace" button on the assignment page once the assignment has a workspace (guided or open); it opens exactly what they get. A banner marks it as instructor preview: you can test-run it with your own provider to check the assignment works, but nothing you enter is saved and you can't submit.

The "Editable design fields" panel in Student agency is not limited to prompts. You can mark almost any interaction setting editable, so a guided assignment can teach mechanics (for example, "now choose Free Discussion and set three turns") instead of only prompt writing. Each field you tick becomes a typed widget for the student that accepts only valid values, so a student choice can never break the run.

The groups you can open

Agent-ref fields. First speaker and moderator are agent-ref fields: the student chooses one of the design's own agents, or none (both are optional). A chosen agent must be one of the design's agents, and a chosen moderator cannot also be one of the round's debating agents. Because a moderator is now student-selectable, a moderator-dependent choice (ending the round on the moderator, or letting the moderator pick speakers) is satisfied once the student assigns one.

What the widget accepts. A dropdown offers only the values the runner accepts, a number field enforces its range, an agent picker offers only the design's agents (or none), and a checkbox is a plain yes or no. "Minimum characters" and a placeholder are text-only options: they apply to the prompt fields and are rejected on a number, dropdown, agent picker, or checkbox field, which have no character minimum.

A guardrail on how much to open. Once four or more fields are editable, the Studio's readiness review adds an advisory note: broad editing can reduce comparability across students. It is a note, not a limit, and it never blocks publishing. If you would rather hand students the full Experiment Builder, that is a different assignment shape, not a variation on this one: attach a design and leave the assignment with no workspace content at all (no editable fields, no runs, no questions, no required-notes minimum). Students then click "Start assignment", the design imports into their own saved designs, and they build and run it in the Builder. Analysis questions are a workspace feature and do not follow them there, so an assignment on that path has no questions to answer; students submit a completed experiment instead.

What stays locked. Provider and model routing, and the structural collections (team assignments, agent order, participating agents), are not editable fields; they run as you set them in the design. To hand students full control, attach a design with no workspace content and they open it in the Experiment Builder (see Authoring in the Assignment Studio).

When an assignment has a design attached, you edit that design right in the Studio's Simulation design section, with no Builder round-trip and no re-upload. Every agent and every round shows as a clickable line. Click one to open the design editor, a drawer that slides in from the right focused on that card. There are also "Add agent" and "Add round" buttons, and a header "Design editor" button that opens the drawer on the card you last worked on.

The drawer holds the same agent and round cards as the Experiment Builder, so every setting is editable there, plus a small header block for the design name, default provider, and default model. It is non-modal: the page stays usable behind it, the main content reflows to its left on a wide screen, and it goes full width on a narrow one. Closing the drawer with edits you have not applied asks you to confirm before discarding them.

One place saves

Divergence and re-attaching

Because studio edits touch only the snapshot, the design section labels the difference. After you save studio edits it reads "Edited in Studio, diverged from <source design name>", or "Edited in Studio (source design deleted)" when the original is gone. Re-attaching a design from the "Attach design" select replaces the studio edits and clears the label. While a re-attach is chosen but not yet saved, the design editor is locked until you Save assignment, so the design about to be replaced cannot be reopened over the new choice.

Saving a copy to your Designs

After a successful Save assignment, a "Save a copy to my Designs" button appears. It writes the edited design into your own Designs, named with a " (Assignment Studio Build)" suffix. There is exactly one copy per assignment: the first save mints it, and later copy saves update that same design in place rather than minting a second one. The copy identity survives re-attaching a different design. Saving a copy re-syncs the assignment's source to that copy, and the diverged label clears once the snapshot matches the copy.

The student path diagram

Preview & publish carries a read-only "Student path" diagram, and a "View student path" link in Simulation design jumps to it. It is a derived projection of the current design, guided scaffold, declared runs, and analysis questions: it owns no editable state and never writes back, so it always reflects what you have staged. It shows, in order: before-the-run (setup) questions, then run lanes that each walk Set up then Run then Analyze (one lane for a normal assignment, or one lane per declared run), with each round's interaction pattern, moderator, and speaker-order badges. Questions anchored after a round or after a specific message appear at that spot, with message numbers shown starting at 1. A multi-run assignment rejoins at a Compare stage, then Submit. Whether students unlock the transcript step by step (gated) or see it all at once (open reveal) is shown, and a plain linear text list of the same path always ships beside the diagram for screen readers. In an incomplete design the diagram draws only the parts it knows and marks the broken step, never inventing placeholder rounds or agents.

Letting students see the path

A checkbox in Preview & publish, "Students can open the Assignment Studio for this assignment", controls the student-facing view. It is off by default, so students see no such button and reach nothing; instructors always keep full studio access. Turn it on and a student who opens the assignment studio gets only this read-only path view, never the authoring drawer, the prompt library, any write control, or the raw design. It is a separate student page, not the instructor Studio with parts hidden.

The Tutorials page — one of the three student front doors — holds short, self-paced lessons that teach the platform one step at a time. They're the gentlest place to start before diving into the full builder.

How they work

• Deterministic, not an AI chat. A lesson mixes short things to read with "type the answer" checks. A wrong answer just shows a hint and lets you try again — no model is involved, so it's instant and consistent.
• Sequential unlock. Finish one lesson to open the next (Mimo/Duolingo-style). Your progress is saved to your account when you're signed in (so it follows you across devices) and in this browser otherwise.
• Self-paced and separate from grading. Tutorials aren't a classroom assignment — re-enter any lesson any time.

The four modules

Ordered from the basics up: Build (create an agent, write its prompt, add a round, edit round features, and advanced round controls), Run (run a one-round experiment), Analyze (export, annotate, and analyze the transcript), and Submit (turn in an assignment). All lessons are live across the four modules.

By default an experiment runs your rounds top to bottom, once each. Transitions let a round decide what happens next based on what actually happened in it, so one design can take different paths on different runs.

Setting up conditions

Every round card in the Experiment Builder has a Transitions section. Under Conditional transitions, add one condition per possible destination: pick the target round by name, and write a When text describing the circumstances that should send the experiment there ("the Trajectory Score is 3 or above"). Rounds are referenced by their Round name, so a branching design needs its target rounds named. Renaming a round updates every condition that points at it; deleting one asks first and clears the conditions that pointed at it.

Once a round has at least one condition, choose a transition moderator: the agent that reads the round and decides. It can be the round's own moderator, an agent that participates in other rounds, or a dedicated judge; its only extra duty is the decision, and it does not join the round's turn-taking. Decision guidance is optional overall instruction for that judgement ("the outcome depends on practices, not on who wins").

The condition texts and the decision guidance are never shown to the agents taking part. The judge's public announcement is, so it may paraphrase the reason it chose.

After this round

After this round sets what happens when no condition is met, and what happens on a round with no conditions at all. Continue to the next round is the default (and off the last round, the experiment simply ends). End the experiment stops the run there, which is what a branch tail usually wants: without it, the round after "The Iron Cage" in your list would run even though the experiment took the other path. Jump to a round goes somewhere specific every time.

Loops and the round ceiling

A condition may point backward, or at its own round, so a design can cycle. To keep an unattended run finite, every branching run has a ceiling on the total number of rounds it will execute. Max rounds executed in Experiment Info sets it; leave it blank for the automatic ceiling (three times the number of rounds you authored). The platform caps it at 150 whatever you enter. When a run stops because it hit the ceiling, the transcript says so: "Run ended at its round ceiling."

If a round cannot be reached from the first round by any path, the Studio's readiness review flags it as an advisory. It does not block saving or publishing: an unreachable round may be work in progress.

What students see

In an assignment, Show branch conditions to students controls whether the assignment path view spells out the When texts and the decision guidance. It is on by default, because handing students the conditions is usually part of the exercise. Turned off, students still see which rounds a round can lead to, labelled "decided during the run", and the condition texts never reach their browser at all.

Reading a branched transcript

Rounds appear in the order they ran, numbered 1, 2, 3 by execution. When the executed order differs from the order you authored, the heading also names the authored position, for example "Round 3: The Bust (design round 2)", and a round that ran more than once is labelled ", second pass (design round 2)". The judge's decision appears between rounds as its own note. Rounds that were not taken are simply absent.

Anchored analysis questions are authored against a design round, so a question attaches to the first time that round actually ran. If the round never ran, the question still appears, at the end of the transcript, marked "This question was set for a round that did not run in this experiment." A gated assignment treats such a question as passed rather than locking the rest of the transcript behind a round that cannot exist.

Extracted data works the same way: a field sourced from a design round reads every execution of that round, and a field pointing at a round that never ran comes back empty with the not_executed confidence badge. Instructors reviewing a submission can open Routing assessment beside the announcement to read the judge's full private reasoning; students never receive it. On your own personal runs, Show routing assessments on the results page fetches the same thing for you.