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. If this address is new, you'll receive a confirmation email: click the link to activate your account, then sign in. If you already have an account, no email is sent, so sign in instead (and use "Forgot password?" on the sign-in page if you need a new password).

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.

Forgot your password? Use the "Forgot password?" link on the sign-in page: enter your account email and open the link in the message that arrives. It takes you to a page where you confirm your account email and set a new password, and you land back on Home already signed in. Links expire after a short while and each works once; if yours has expired, the page says so and offers to send a fresh one. For privacy, the request page shows the same confirmation whether or not an account exists for the address you typed, so if no email arrives, check your spam folder and double-check the address. This is also how you change your password: there is no separate password field in Settings.

Quick test: Try 2 agents, 1 round, "Short" response length. That is a small, fast test, so it lets you verify everything works before building a larger experiment.

Home is where signing in lands you: a greeting, a focus card of the work to continue, your classrooms, and then your lists.

• The focus card offers the design you saved most recently, with an Open in builder button. Before you have saved any design it offers your most recent run instead. Students always see the run card, since their starting point is Classrooms rather than the builder.
• Your designs is a grid of your saved designs, most recently saved first, each showing when you last saved it and an Open in builder link that loads it into the Experiment Builder ready to edit and run. It shows the first 12 with a "Show all N designs" button underneath for the rest.
• Recent Experiments lists your runs, newest first, each card carrying the run's name, its state, and the date it was launched. It shows the first 12 and puts a "Show all N runs" button underneath for the rest, so a long history doesn't bury everything below it.
• Recent Batches lists batch runs and how many of their runs have finished.

Finding an older run

The search box above Recent Experiments filters the list as you type, matching a run's name, its state (completed, running, error), or its date. Dates match either way you type them: as the card prints it (Mar 7) or as a plain calendar date (2019-03-07). Search reads every run you have, not only the 12 on screen, so an old run turns up without expanding the list first. If nothing matches, the list tells you so; clear the box to go back to the normal view.

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:

How strongly the persona is held

Agents hold their persona on their own. You do not need to repeat "stay in character" or restate persona-specific instructions inside the round's condition prompt to be heard: every agent turn is told to answer in its persona's own voice, and is reminded of that persona again right before it speaks. Write the condition prompt for the situation and let each agent's Persona field carry who they are.

The moderator is deliberately different. It narrates and synthesizes about the participants rather than speaking as one of them, so it keeps a neutral voice. The same is true of the behind-the-scenes calls that decide whether a round is finished and which round runs next.

If you are running a research sequence, note that this behaviour changed on 9 August 2026. Transcripts produced before that date and transcripts produced after it are not directly comparable: the same design will hold its personas more strongly now. Re-run your baseline if a comparison has to hold across that date.

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 shipped corpora themselves stay read-only: you cannot add to or edit the course prompts. You can, however, save your own agents alongside them. See Agent library.

Use the Source filter to separate the two. It lists My agent library first, then each course corpus. The count line below the filters reads "12 of 94 prompts and saved agents" once you have saved anything, so the second number always means everything this browser can reach.

Your agent library saves a whole agent so you can use it again in another design. It is instructor-only, and it is private to your account: nothing you save is shared with students or with other instructors. Sharing a library, to a classroom or to a colleague, is not part of this version.

Saving. In the Experiment Builder, each agent card has a Save to my library button in its header row. The saved entry keeps everything on that card: the name and ID, specialty, persona, agent type, model, provider, temperature, memory window and overflow, and any attached document reference. Saving never interrupts what you are building. It changes nothing on the card, and if it fails you get a notice you can dismiss and carry on.

Names. An entry is named after the agent's ID by default. If you already have an entry with that name, Delstorm asks whether to replace the saved one or give this one a different name. It never overwrites silently, and the comparison ignores capitalisation and surrounding spaces, so "The Preacher" and "the preacher" count as the same name.

Browsing and inserting. Saved agents appear in the same Prompt Library browser as the course corpora, under the source My agent library. Inserting one adds a new agent card to your design with every field filled in, rather than pasting text into a card you already have. In the assignment Studio, saved agents are visible and you can copy their persona text, but the whole-card insert lives in the Builder, which is where agents are authored.

Routing is re-checked when you insert. If the saved provider is not set up in your account, Delstorm clears the provider and the model together, tells you which provider was dropped, and the new card uses your session's default provider and model. It never does that silently. A saved document reference that is no longer in your document library is dropped the same visible way. Model names are free text everywhere in Delstorm, so a model that carries over is exactly as checked as one you type in yourself.

Size limits: a name is up to 100 characters, and a whole saved agent has to fit in 64 KB, which is roughly thirty times the longest persona in the shipped course material. If either is exceeded the save is refused and says so; nothing is silently shortened.

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.

The assignment assistant builds an assignment with you by conversation, at Build an assignment with the assistant. The way in is from a classroom you instruct: under New assignment, choose Build an assignment with the assistant, which carries that classroom along for you. It is a tool for instructors. Students do not use it and cannot open it.

Describe the assignment you want in your own words and add your course material: a PDF or a text file, and slides work best exported to PDF. The assistant reads what you upload, asks what it still needs, and drafts the assignment with you. Ordinary questions get short answers; when the plan looks right, ask it for the draft.

From there the draft rides exactly the same path as an imported one. Check this draft validates it on the Delstorm server, the same check the import page runs, and shows you what it would create along with anything blocking it. Nothing is created by that check. Save to my drafts inbox stores it in your private intake inbox, the very same inbox manual imports land in. You create the assignment later from the review page, and it always arrives unpublished.

What it does not do. The assistant creates new assignment drafts only: it does not edit assignments that already exist, and it cannot publish anything or create the assignment for you. If the reply gets cut off before the draft finishes, it says so and offers nothing to save, rather than handing you an older draft that looks current.

Two names, two different things. This assistant lives inside Delstorm. The Assignment Builder GPT is a separate tool that runs in ChatGPT, and its drafts come over by hand on the import page. They both end at the same inbox, so use whichever suits you.

Your conversation stays in your own browser so you can come back to it, and it is cleared when you sign out. Uploaded material is read for the conversation and is not added to your Document Library; if a design needs a document at run time, upload it there as usual.

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:

Going back to the builder

The same action bar carries the way back to the design the run came from:

• "Edit design & re-run" appears when the run was launched from a saved design. It opens the Experiment Builder with that design loaded, so you can adjust a persona, a condition prompt, or a round setting and launch again. Save Design updates that design in place; use "Save as new" to keep the original and file the edited version separately.
• "Back to builder" appears when the run came from a design you never saved.

A launch never discards your work. The builder keeps a local draft of whatever you are building, and launching saves that draft instead of clearing it, either way:

• An unsaved build is offered back with a Restore banner the next time you open the plain builder.
• While the Restore banner is showing, everything that acts on the design waits: saving, launching, batch running, and deleting a design. Each one would decide for you which copy to keep, so Delstorm asks you to Restore or Dismiss it first and then does what you asked.
• A saved design is protected the same way, because launching runs what is on screen rather than what the design row holds: edit a persona and launch without saving, and the run used your edit while the saved design still has the old one. Coming back through "Edit design & re-run" loads the saved design and then offers those edits back with the same banner, so you can take them or dismiss them. Launch without changing anything and there is nothing to offer, so no banner appears.

Launching produces a new run every time, so re-running never overwrites the transcript you were just reading. Both runs stay in your experiment history. Runs launched before this link existed show "Back to builder", because they recorded no design.

A run that failed keeps the way back and nothing else: there is no transcript to export, chart, or evaluate, so those buttons are not offered on it.

Workspace assignment runs work differently on purpose: a run launched from a workspace assignment carries no builder link of either kind. That loop goes back to the assignment workspace, where the run was launched and where the next step of the assignment lives. Runs from a freeform build or a classroom's builder space keep both controls, leading back to the builder that launched them (the assignment's own, or the classroom's), never the generic personal builder.

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.

Citing a message

Every message carries a short citation reference beside the speaker’s name, in a plain monospace chip. It names exactly one message, so you can point at it in an answer instead of describing it (“the bit where Elena pushes back”).

An agent’s turn reads R2.T3.Elena:

• R2 is the round, counted in the order the rounds actually ran. If a round repeats (a design can loop back), each pass gets its own number, so a reference is never ambiguous.
• T3 is the turn within that round, counted from 1.
• Elena is the agent, written exactly as the agent is named in the design.

Two other kinds of message use the same shape:

• A moderator message reads R2.M.open, where the last part is the moment it spoke: open, turn_2, close, transition, or a speaker pick.
• A private reflection reads R2.X.Elena.

Click the chip to copy the reference, then paste it where pasting is allowed, such as the note's quote field. The full reference is always shown, never shortened, so where an answer box requires typing you read it off the screen and type it in; it is only a few characters.

References appear while the run is streaming as well as on the finished transcript. An agent turn, a moderator message, and a private reflection each carry the same reference in both, so one you copy mid-run still points at the right message afterwards. There is one exception: the moderator’s speaker-pick narration shows its reference only once the run has finished, because a pick is not always kept in the record. A reference is tied to one experiment record: the same design run again produces a new record, and R2.T3.Elena in that run means that run’s message, so say which run you mean when you compare two.

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, download it as a spreadsheet: on the finished experiment's page, click "Data CSV" in the action bar along the bottom, beside Export JSON. The same file is served from the experiment's data endpoint, which is also how a batch exports (the batch page has no button yet) and how you choose columns:

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.

Some classrooms set join requirements. A classroom can restrict joining to certain email domains (for example, only university addresses). If your account's email doesn't match, the join is refused with a message naming the accepted domains, and you'll need an account at one of them. A classroom can also ask for your official name as it appears in your school's course system: the join box reveals first and last name fields, and the name you enter shows on your instructor's roster and grade export so they can match your work to the course roster. If your classroom starts asking for names after you joined, a card on the classroom page asks for yours on your next visit. Neither requirement ever locks out someone already in the classroom.

Working on an assignment

These four steps are for an assignment that opens in the builder. If your instructor built a workspace for it, the assignment page shows "Open workspace" instead, with "Start in builder" beside it if you also want the design in your own builder to explore. On that kind of assignment you work through the workspace's own steps and submit there, so step 2's button and step 4's picker are not what you will see.

"Start in builder" copies the design, and only the design. You get the baseline agents, rounds, and any referenced documents in your own saved designs. The declared runs, the fields your instructor left editable, the analysis questions, the required transcript notes, and the instructor's guide are all part of the workspace, not part of the design, so none of them come with the copy. It is there to take the design apart and experiment with it. The attempt your instructor marks still happens in the workspace, and you still submit there.

1. 1.

   Open the assignment from the classroom's Assignments tab. It shows the instructions, due date, and any resource links. A due date never blocks a submission: you can still submit after it passes, and Delstorm accepts the work exactly as it would before, and your instructor simply sees it marked as late.

   Whether you see your own late status is up to your instructor, and it is off unless they turn it on. When it is on, a Late marker sits beside your submission on the assignment page and on your submission page, and the workspace header shows a Past due note once the due date has passed. It is a marker, never a block: the workspace still lets you submit, and the work is accepted the same way.

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. What is imported is the design template on its own: anything the instructor set up as workspace content (declared runs, editable slots, analysis questions, required notes, the guide) stays on the assignment and does not travel into your saved design.

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". A workspace assignment has no completed-experiment picker on this page: you submit inside the workspace, and a run you launched from the builder is not accepted there.

Practice runs

The experiment builder is yours to use whenever you like. Build a design of your own, run it as often as you want, change it and run it again: nothing there is submitted to anyone, so that is the place to practice. When an assignment opens in the builder (step 2 above), the copy imported into your saved designs runs there too, so you can run it, read the transcript, adjust it, and run it again before you submit anything.

An assignment that opens in a guided workspace works differently: the runs you launch there are your real attempt. You can still go back to Step 1, adjust whatever the assignment leaves editable, and launch again as often as you need before you submit. Each launch runs a new experiment, and your earlier attempts stay on record. There is no separate practice mode inside the workspace, and your instructor sees your work when you submit it.

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.

Every classroom has its own experiment builder space: the "Experiment builder" button on the classroom page opens the full builder for any member, any time. Runs launched there are funded by the classroom (the classroom allowance is spent first; your own starter tokens absorb any overflow), so it is the place to explore freely on course resources. Exploration runs belong to no assignment and cannot be handed in, and a completed run's page links you back to the classroom builder, so re-running keeps the same funding.

Freeform builds (for students)

A freeform build is the assignment shape that hands you the full experiment builder instead of a fixed workspace. The assignment page's "Open experiment builder" button opens the assignment's own builder: design and run any experiment you like there, funded by the classroom. Only runs launched from this assignment's builder count toward the assignment; runs made in your personal builder or in the classroom's exploration builder can never be handed in, so always start from the assignment page. If your instructor attached a design it is an optional starter, not a lock: it appears in your saved designs the first time you open the builder, yours to edit or ignore. If the assignment has a 📖 Guide, it comes into the builder with you: a Guide button sits in the banner at the top beside "Review & submit" and another in the bottom action bar beside Designs and Data extraction, and both open the same drawer you saw on the assignment page (Expand and Dock both work there: docking narrows the builder's two side rails a little to preserve a usable editor width and makes room for the guide down the right-hand side, so nothing is covered, and the builder remembers a docked guide for that assignment until you close it with the ✕).

Handing in: back on the assignment page, your completed runs appear once at least one finishes, and the analysis questions unlock at the same moment. Pick which completed runs to hand in (the assignment says how many it requires; you may always hand in more, up to six), give each one a name your instructor will see, answer the questions (word minimums, maximums, and per-question paste rules apply as usual), add optional notes, and submit. Submitting freezes your chosen runs and answers together, and resubmitting replaces the whole previous submission.

Attached files. When your instructor has allowed it, the submission card also carries an "Attached files" block, there from your first visit so you can attach design notes before any run completes: choose a file and click Upload. Up to 10 files, 10 MB each and 50 MB in total; images (png, jpg, gif, webp), PDFs, text and markdown, CSV, JSON, and Jupyter notebooks. Each file has a "hand in" checkbox: the ticked files go in with your runs when you submit. A file that has been handed in shows a chip and cannot be removed until a resubmit that leaves it unticked releases it back to your list, where Remove works again; nothing is deleted by a resubmit. Your own submission page shows the attached files exactly as your instructor sees them.

Freeform builds (for instructors)

Turn the shape on in the Assignment Studio's Student agency section with "Students get the full experiment builder"; beside the guided and open workspace shapes it is the third way an assignment can meet students. "Required variants" (1 to 6, default 1) sets how many completed runs each student must hand in. Questions on this shape come in three stages: a before-the-run question is answered at the first launch that asks it and gates that launch (one added later is asked at the student's next launch), design questions (below) are answered beside the elements of the student's own design, and everything else is answered at hand-in. Word limits, paste rules and attached-note minimums work unchanged (students take their notes on each run's own page and attach them at hand-in; the round evaluation can ask for attached notes too), while run-scoped questions and transcript anchors do not apply, and the Studio offers a one-click conversion when an existing question set needs adjusting for the shape. Editable design fields, declared runs, and required transcript notes do not apply either; attach a design and it becomes an optional starter students import, not a lock. You and your co-instructors can open the assignment builder yourselves, before publishing included, and test-run without being metered, though a preview run can never be handed in. On the submission review page the handed-in runs read as tabs under the names the student gave them, with the answers under their own heading; per-question marks and grade draft and release work exactly as on other shapes.

Design questions

For students. A freeform build may ask design questions: questions about the elements of your own design, asked once per element. "Each agent" and "Each round" questions appear once per agent or round you build; the other kinds appear only when you change that setting from its default (memory window, context window, response length, interaction pattern, moderator, or turns). In the assignment's builder each question has an answer box beside its element, and the Design questions panel lists everything asked of your current design. Answers typed there are recorded with the run when you launch and shown at hand-in as what you wrote at launch; the hand-in answer is yours to finish or revise, and it is the one that is graded. Every launched run carries the design questions exactly as they stood when it launched, so an instructor's later edit applies only to later runs. A before-the-run question is answered at the first launch that asks it (your first launch, or your next launch if your instructor added it later), gates that launch, and is then recorded for the assignment; a round evaluation question, when the assignment asks one, is answered at hand-in for each round of the latest run among those you hand in. Each run allows at most 20 question instances with 600 minimum words between them, and at most 20 round evaluations with their own 600 minimum words; a run that would exceed either is refused at launch with the count. A run launched from an assignment's builder is bound to that assignment and cannot be deleted while the assignment exists; it stays in your list as evidence, so start a fresh run rather than trying to remove one.

For instructors. Add design questions under the freeform build's settings in Student agency: pick the trigger, write the question (1,000 bytes, with a live counter and markdown preview), set word bounds (0 to 500) and the paste rule, and tick "Ask an evaluation question for each round" for a per-round evaluation. Before-the-run questions keep their stage on this shape and gate the first launch that asks them; one added after a student's launch is asked at their next launch or answered at hand-in. On the review page every generated answer shows its context (run, element, and the setting's value against the default), the as-written-at-launch text when there is one, and the usual per-question marks. A freeform build is one-way once it has been live: the moment a freeform assignment is saved published, its shape can no longer change back to a workspace (unpublishing does not undo that), because students may have started runs against it, and an assignment that already has submissions cannot become a freeform build. Use Copy assignment for a new shape or a fresh freeform version; a copy starts unlocked and unpublished.

Attached files (instructors). Tick "Students may attach design notes at hand-in" under the freeform build's settings in Student agency to let students attach files (off by default, so existing assignments are unchanged). On the submission review page an "Attached files" card sits above the answers with each file's name, type, size, when it was uploaded and when it was handed in; images show inline and every file has a Download link. Files are stored exactly as uploaded, kept with the submission, and removed with the submission, the assignment, or the classroom; they never expire on their own. Turning the checkbox off later refuses new uploads while files already handed in stay with their submission.

When a run uses one of the platform's shared AI providers, the text it generates costs real money, so student usage is measured in tokens (about four characters of generated text each). Runs against a provider you configured yourself in Settings (your own API key, your own spend) never touch your token balance, and instructor accounts are not metered at all.

For students

Every student account starts with 25,000 tokens of its own, enough to genuinely try the experiment builder. Classroom work runs on tokens your instructor grants: a per-student allowance for the classroom, plus top-ups whenever you need more. Classroom tokens stay in their classroom; your own starter tokens work anywhere. You can see what you have left on Home, under the run button in an assignment workspace, and on the classroom page's Members tab.

When your balance is empty, new launches are blocked; a run that has already started always finishes, even if it takes you a little below zero. The message points you back here: ask your instructor for more, or press "Request more tokens" on the classroom page, which flags you on your instructor's roster so they can top you up. Only one of your metered runs can be in flight at a time, and a batch stops starting new runs when the balance runs out (finished runs are kept, the rest are marked skipped with the reason).

For instructors

The Tokens card on your classroom's Members tab is the whole control surface. Set a per-student allowance and every current member is topped up to it; a student who joins later gets it on joining, and raising the allowance grants everyone the difference. Lowering it never takes tokens back, and nothing ever resets: top-ups are additive, for the whole class or for one student at a time, and a targeted top-up never touches classmates. The spend view shows each student's granted, used, and remaining tokens, with the used figure split honestly between what classroom tokens covered and what the student's own starter tokens absorbed, plus a "Requested more" badge when a student has asked; topping them up clears it. Your own runs, previews, and the classroom TA's replies are not metered, and co-instructors are exempt like you.

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, each row carrying its own Changed, Added, or Unchanged marker. 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 a row that names the field and its status on its own line, with the reference and current values in adjacent columns beneath it and 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.

Each Changes from block folds, and in Side by side each row folds too. Everything starts open; closing a fold parks it while you read the next one, and a closed row still shows its field name and status. Stacked one-line settings do not fold, since there is nothing under them to hide.

Within a changed text field, the words that differ are highlighted in both panes: removed words tinted in the reference value, added words in the current one, so a one-word prompt edit is visible at a glance inside a long prompt. The full text of both values still reads exactly as stored. On a very long or very heavily rewritten value the highlighting steps aside and the two panes render plain, complete as always.

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 floats at the top right of the workspace and of the assignment page, following the page as you scroll. 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, and numbered 1, 2, 3… straight through the groups so you and your instructor can name the same section. Every section stays visible on every step: whichever sections match the step you are on open automatically, the first General section (the overview) opens with them every time when the guide has one, 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.

Two ways to keep the guide where you want it. Expand in the drawer's header widens it, for a long section you would rather not read in a narrow column. Dock, in the workspace and in a freeform build's Experiment Builder, parks the guide beside your work instead of over it: the page makes room down the right-hand side, nothing is covered, and you can keep typing with the guide open. A docked guide ignores Escape and clicks outside on purpose, since neither of those is you asking to put it away; its ✕ closes it. The workspace and the builder each remember a docked guide for that assignment separately, and each opens it docked again the next time you come back, until you close it there with the ✕. Dock is offered on a wide screen only, and narrowing the window turns a docked guide back into the ordinary drawer over the page (or, while a panel is open above it, such as the builder's Designs or Data extraction drawer or the workspace's notepad, or while a walkthrough is running, closes it and keeps your choice for the next wide visit).

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.

How much to hand over is a dial, not a switch. The same panel covers the whole range, one assignment at a time. Locked is the default: nothing is ticked, the design runs exactly as you authored it, and students answer your questions. Selectively editable is the middle: tick the specific fields the assignment is about, and the rest stays locked and visible. Fully exposed is the far end: tick everything the panel offers, and students set up the whole design themselves inside your assignment. There is no separate mode to turn on for the last one; it is what the middle becomes when you tick every box. Students never choose their own editable set, on any setting of the dial.

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", a placeholder, and "Allow pasting" 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 and no paste rule.

Expected answer (optional). Every typed field you make editable gets an "Expected answer" control beside its label, except participating-agents and transitions fields, which have no single right answer to check against and say so where the control would be: the value you would have chosen. It is read only by "Check my work", which compares the student's choice to yours and answers with a pass or a fix chip. It is advisory only and does not block launching or submitting, and the feedback never shown to students as the answer: a student who misses it sees your field hint if you wrote one, otherwise a neutral nudge back to the guide. Leave it on "No expected answer" and the field is simply not checked. Text fields have no expected answer (there is no single right wording); they keep the on-topic check they always had.

Hint (optional). Every typed field you make editable also takes a markdown hint, exactly like a text field: it renders under the widget's label in the workspace wherever the field is editable, and it is the feedback a student sees on a missed expected answer. Write it as the guidance you would give in person ("debate fits a two-sided question"), not as the answer. On a multi-run assignment the base hint carries to every run unless you customize that run's hint: each run row in Runs & variants has a "Customize hints for this run" panel, off until you use it, whose editors follow the base hint until you edit one. Typed fields sit in that panel beside the text fields, so a dropdown, a number field, or a checkbox can carry its own wording on a single run, and a field whose base hint you left empty can still be given one there. A locked run hides every hint from students either way. Authoring in the Assignment Studio states the whole rule.

How students answer. Two independent checkboxes in Student agency set what you demand of the choosing itself, and both are off by default. "Students must actively choose each editable setting" opens every editable typed widget on "Choose..." rather than the design's value, so a student cannot run by leaving your defaults untouched; choosing the same value the design had still counts. "Students must justify kept preset values" adds a "Why this choice?" box under each editable setting, required only when the submitted value equals the design's, optional when the student changed it. Justifications are submitted with the work and appear on the submission review page beside the field they explain. Editable text boxes are exempt from both: they already demand real writing, and they now start from the design's authored text so students edit rather than retype it.

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 instructor-only. Provider and model selection stay yours: they are cost and access decisions, not experiment design. So do the raw structural collections, team assignments and agent order. A round's transitions and its participating agents are not in that list any more: both can be made student-editable, transitions as one unit. Design-level "Max rounds executed" and "Show branch conditions to students" also stay yours. Anything instructor-only runs as you set it in the design. To hand students full control of everything including the provider, 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 a recorded source design no longer exists, or simply "Edited in Studio" when the assignment has no source design on record, which is how every copied assignment starts. 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.
• Pal hosts the lessons. Pal opens each lesson with a short intro, cheers a right answer, encourages after a wrong one, and offers the next lesson when you finish. The hosting is pre-written script, never generated, so tutorials stay free and never call a model.
• Modules unlock independently. Start any module right away; inside a module, lessons run in order. Each module card shows how many of its lessons you have done. Your progress is saved to your account when you're signed in (so it follows you across devices) and in this browser otherwise.
• Completion is earned in the sitting. Marking a lesson complete needs that lesson's answer checks passed in the same sitting. If you reload mid-lesson, redo its short checks and finish again; lessons are short on purpose.
• Self-paced. Re-enter any lesson any time; completing a lesson again never changes its original completion date.

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.

Tutorial assignments & certificates

Instructors can assign the tutorials as a classroom assignment. In the Assignment Studio, turn on Tutorial certificate in the Student agency section and pick the required lessons (all selected by default; picking a lesson includes the earlier lessons of its module). The assignment page then shows students each required lesson with its completion state and date, and a "Hand in my certificate" button that enables once every required lesson is complete.

• Earlier work counts. Lessons finished before the assignment existed satisfy it, and the certificate cites the real original dates.
• The certificate is the submission. Handing in freezes a certificate of completion: your name as you provided it, your account email, and each required lesson with its completion date. It is built by the server from your saved progress; there is nothing to type. The instructor reviews and grades the certificate like any submission, and a printable page is linked from the assignment after you hand in.
• Handing in again issues a fresh certificate. The lesson dates stay the original facts; the name and the hand-in date are current.
• Verification is by account. The name on the face is the one the student provided (their classroom roster name, or their account display name); the account email printed beside it is what an instructor checks a printed copy against.

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.

When a round has conditions, the moderator is asked to state a verdict for every condition before it decides: met or not met, with one sentence of evidence from the discussion. When its reply carries those verdict lines and names a round, that decision is followed only if its own verdicts support it and every verdict line could be read; otherwise the named decision is not used for routing, After this round applies, and the announced reason is composed from the verdicts (the same happens when the moderator chooses no condition while marking one met, or names something that is not an option). When the moderator chooses no condition and nothing contradicts it, After this round applies with the moderator's own reason, and if some verdict lines could not be read the transcript says how many. A reply with no verdict lines at all is handled exactly as before: the decision is followed when it names a condition's round, so older designs and models that ignore the request are not broken. The verdicts show under the announcement for everyone who can see the transcript. The moderator is told exactly where the fallback leads before it decides, and the transcript names the destination either way. A decided move reads "Moving to The Iron Cage: ...", while a fallback reads Continuing to "..." (or "Ending the run") followed by the reason, so a run that argues for one branch and takes another is visible at a glance. If the moderator's reply never reached a readable decision, the note says so rather than showing an empty reason.

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.

Writing conditions that route reliably

The transition moderator reads your When texts word for word, is asked for a verdict on every condition, and must then answer with one exact round name, or NEXT when none of them fits. Three habits make that answer land where you meant:

Cover the "not yet" case explicitly. In a cyclical design (say, a Boom and Bust loop that may or may not ripen into a Revolution), the verdict "conditions have not formed yet" deserves its own condition pointing back into the cycle ("If the workers remain fragmented, go to Boom"). A moderator whose honest assessment matches one of your conditions can name that round; a moderator whose assessment falls between conditions is left with NEXT, and NEXT follows After this round, wherever that points.

Point After this round at the safe default. In a cycle, that is usually the earlier round: set the looping round's After this round to Jump to a round and pick the round that repeats the cycle, so an undecided reply repeats the loop rather than exiting it. Left on "Continue to the next round", an undecided reply walks forward into whatever comes next in your list, which in a cycle-then-climax design is exactly the round the moderator just argued the run was not ready for. The Studio's readiness review flags this shape as an advisory: a round with a branch that re-enters a cycle, however the rounds are ordered on the page, while its After this round leaves that cycle.

Phrase conditions as observable evidence, and put thresholds in Decision guidance. "At least two workers explicitly call for seizing production" routes more reliably than "revolutionary consciousness has formed", because the moderator can check it against the transcript rather than interpret it. Where several conditions share a standard, define it once in Decision guidance ("Reformist demands, however organized, are not revolutionary action").

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 stored condition texts are withheld from their path view; when a round's routing is a student-editable slot the workspace shows the conditions regardless, because the editing widget needs them. What the moderator writes in public is a different channel: its announcement and its verdict evidence are model-written from the discussion and instructed not to restate the conditions, which is an instruction rather than a guarantee.

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.