Verified UI

The verified UI is a Slack client, built against Slack’s own client and checked against it, that runs on the simulator’s own Web API. An agent works in a workspace through the Slack client in a browser, through the Web API or both, and a grader reads what it did. Whatever the agent does in the client lands in the simulator’s state, so a task can begin with a seeded workspace and a timed event and end with a read of the Web API:

curl -s -X POST "$RYSTIC_URL/_rystic/scenario" -d '{"name":"design_studio"}' -o /dev/null
curl -s -X POST "$RYSTIC_URL/_rystic/credentials" -H 'Content-Type: application/json' -d '{"bindings":{"xoxp-ui-UWDC0000002":"UWDC0000002"}}' -o /dev/null -w '%{http_code}\n'
# -> 204
curl -s -X POST "$RYSTIC_URL/_rystic/inject" -H 'Content-Type: application/json' -d '{"events":[{"id":"noor-asks","at":"+10m","as":"UWDC0000002","call":{"method":"POST","path":"/api/chat.postMessage","headers":{"X-Rystic-Surface":"client"},"body":{"channel":"CWDC0000004","text":"Can someone check the Hartwell invoice?"}}}]}' -o /dev/null -w '%{http_code}\n'
# -> 204
curl -s -X POST "$RYSTIC_URL/_rystic/clock" -d '{"advance_seconds": 600}' -o /dev/null -w '%{http_code}\n'
# -> 204
curl -s "$RYSTIC_URL/api/conversations.history?channel=CWDC0000004&limit=1" -H 'Authorization: Bearer xoxb-local' | jq -c '.messages[0] | {user, text, bot_id}'
# -> {"user":"UWDC0000002","text":"Can someone check the Hartwell invoice?","bot_id":null}

The verified UI is Pro and Enterprise; the Web API and the workspace UI stay on every plan. It ships as an image beside the simulator’s, registry.rystic.ai/slack-twin-ui:<ver>, pulled with the same docker login registry.rystic.ai as the simulator (your API key, or an Enterprise license file). The front door hands it out only to a plan or a license that carries verified_ui, and the UI serves only a simulator whose grant carries it, so a Free key gets a refusal page naming the feature. What a verified UI is says which plans carry it.

Run it beside the simulator

rystic ui runs the client against a running instance. It pulls the image, or, with no Docker on the machine, downloads the UI’s archive and runs it on your Node 22 or later:

rystic run slack-twin -d --scenario design_studio --env SLACK_TWIN_SOCKET_MODE=1
rystic ui slack

The first run fetches the UI with your key or license, the way rystic pull fetches the simulator, and a Free key is refused with feature_not_in_plan, naming verified_ui. -name picks another instance and -port another port. The command binds a user token to every seeded person, again after every reset, scenario load, seed load and simulator restart, and prints the URL, http://127.0.0.1:18433. Add ?as=<user id> to start as someone else, or switch person from the avatar at the foot of the rail, and theme=dark for Slack’s dark theme. Without Socket Mode the UI shows only what it reads, with no live updates.

Run it by hand or in Compose

Run the image yourself, or in Compose beside the simulator, where the UI reaches it by its service name:

docker run --rm -p 127.0.0.1:18433:18433 -e RYSTIC_TWIN_URL=http://host.docker.internal:8080 registry.rystic.ai/slack-twin-ui:<ver>   # Docker Desktop
docker run --rm --network host -e RYSTIC_UI_HOST=127.0.0.1 -e RYSTIC_TWIN_URL=http://127.0.0.1:8080 registry.rystic.ai/slack-twin-ui:<ver>   # a Linux daemon

services:
  slack-twin:
    image: registry.rystic.ai/slack-twin:<ver>
    environment:
      RYSTIC_TOKEN: ${RYSTIC_TOKEN}
      SLACK_TWIN_SOCKET_MODE: "1"
    ports: ["8080:8080"]
  slack-ui:
    image: registry.rystic.ai/slack-twin-ui:<ver>
    environment:
      RYSTIC_TWIN_URL: http://slack-twin:8080
    ports: ["127.0.0.1:18433:18433"]
    depends_on: [slack-twin]

On a machine that cannot pull (Enterprise), run docker save registry.rystic.ai/slack-twin-ui:<ver> | gzip > slack-twin-ui.tar.gz where you can pull and docker load where you cannot. Without Docker, rystic ui slack -fetch-only on the machine where rystic pull ran installs the archive beside the simulator. The UI talks only to the simulator, on loopback or its Compose network.

One container for a platform

A platform that packages environments as container images and lets its users write tasks on top of them runs one container per task. It holds the Slack simulator and its verified UI:

Build the image

The image is built from the two images each release ships, the simulator’s and its UI’s, and rebuilds neither. Save this as Dockerfile.ui-stack:

# A simulator and its verified UI in one container, behind one entrypoint and
# one health check, for a platform whose environment is a single image. It is
# built FROM the two images a release ships, the simulator's and its UI's, and
# rebuilds neither: the simulator keeps its license stamp and the UI keeps its
# plan gate, so a license without verified_ui gets the UI's 403 page here too.
#
#   docker build -f Dockerfile.ui-stack \
#     --build-arg TWIN_IMAGE=registry.rystic.ai/slack-twin:<ver> \
#     --build-arg UI_IMAGE=registry.rystic.ai/slack-twin-ui:<ver> -t slack-env .
#   docker run -d -p 8080:8080 -p 18433:18433 -e RYSTIC_LICENSE="$RYSTIC_LICENSE" \
#     -e SLACK_TWIN_SOCKET_MODE=1 slack-env --scenario design_studio
#
# Arguments after the image name go to the simulator, and so does the
# container's environment. The entrypoint starts the simulator, starts the UI
# once the simulator answers (the UI's own entrypoint, which binds its tokens
# and serves), and stops the container when either process stops. The health
# check passes only while both answer 200. The build context is unused.
ARG TWIN_IMAGE
ARG UI_IMAGE
FROM ${TWIN_IMAGE} AS twin

FROM ${UI_IMAGE}
USER root
COPY --from=twin /opt/rystic /opt/rystic
COPY --chmod=755 <<'EOF' /usr/local/bin/rystic-stack
#!/bin/sh
set -u
urls=/tmp/rystic-stack.urls
if [ "${1:-}" = health ]; then
  [ -r "$urls" ] || exit 1
  while read -r url; do wget -q -T 3 -O /dev/null "$url" || exit 1; done < "$urls"
  exit 0
fi
dir=$(dirname /opt/rystic/twins/*/current)
product=${dir##*/}
twin="http://127.0.0.1:${RYSTIC_ADDR##*:}"
eval "$(node -e 'const m = require("/ui/rystic-ui.json"); console.log(`twin_env=${m.twin_env}; ui_port=\${${m.port_env}:-${m.port}}`)')"
tp= up= stopping=0
trap 'stopping=1; kill $tp $up 2>/dev/null' INT TERM
"$dir/$(cat "$dir/current")/$product" "$@" &
tp=$!
until [ "$stopping" = 1 ] || wget -q -T 2 -O /dev/null "$twin/_rystic/version"; do
  kill -0 "$tp" 2>/dev/null || break
  sleep 0.2
done
if [ "$stopping" = 0 ] && kill -0 "$tp" 2>/dev/null; then
  eval "export $twin_env=\"\${$twin_env:-$twin}\""
  sh /ui/entrypoint.sh &
  up=$!
  printf '%s\n%s\n' "$twin/_rystic/version" "http://127.0.0.1:$ui_port/" > "$urls"
  while [ "$stopping" = 0 ] && kill -0 "$tp" 2>/dev/null && kill -0 "$up" 2>/dev/null; do sleep 1; done
fi
kill $tp $up 2>/dev/null
wait
[ "$stopping" = 1 ]
EOF
ENV RYSTIC_ADDR=0.0.0.0:8080 \
    RYSTIC_HOME=/opt/rystic \
    RYSTIC_LICENSE=""
EXPOSE 8080
USER node
WORKDIR /home/node
HEALTHCHECK --interval=5s --timeout=8s --start-period=30s --retries=3 \
  CMD ["/usr/local/bin/rystic-stack", "health"]
ENTRYPOINT ["/usr/local/bin/rystic-stack"]

Build it and start one environment:

docker build -f Dockerfile.ui-stack \
  --build-arg TWIN_IMAGE=registry.rystic.ai/slack-twin:0.0.20 \
  --build-arg UI_IMAGE=registry.rystic.ai/slack-twin-ui:0.0.20 -t slack-env .
docker run -d --name slack-env -p 8080:8080 -p 18433:18433 \
  -e RYSTIC_LICENSE="$RYSTIC_LICENSE" -e SLACK_TWIN_SOCKET_MODE=1 \
  slack-env --scenario design_studio

Arguments after the image name go to the simulator, and so does the container’s environment:

The UI serves only a simulator whose license or plan carries verified_ui. Under a license without it, every UI page answers 403 naming the feature, the Web API keeps working and the container’s health check fails.

Know when it is ready

The image’s health check passes once GET http://localhost:8080/_rystic/version and GET http://localhost:18433/ both answer 200, so docker inspect -f '{{.State.Health.Status}}' slack-env reads healthy. It runs every 5 seconds; a harness that wants to start sooner polls the two URLs itself. The UI’s port refuses connections until the simulator answers, because the UI starts only then; once it starts, / can answer 503 while it checks the simulator, so a readiness poll treats both as not ready yet.

On start, and again whenever the workspace changes, the UI binds a user token, xoxp-ui-<user id>, to every person in the workspace, so the client can act as anyone. The bindings land within a moment of / answering; a task that needs them checks one:

curl -s http://localhost:18433/api/auth.test -H 'Authorization: Bearer xoxp-ui-UWDC0000001'
# {"ok":true,"user":"dana","user_id":"UWDC0000001",...}

Point the browser at a conversation and a person:

http://localhost:18433/client/TWDC0000001/CWDC0000001?as=UWDC0000001

TWDC0000001 is the workspace, CWDC0000001 is #general and UWDC0000001 is dana. Leave out ?as= to open as SLACK_UI_ACTOR. The person can be switched from the avatar at the foot of the left rail.

Seed a workspace

Each task starts from a workspace you name. There are three ways to describe one, and they combine.

1. A built-in scenario. design_studio is a web design studio’s Slack a year in: sixty conversations and their threads, DMs, reactions, pins, files and bookmarks, from a cast of forty-three; Scenarios says what it holds. Boot it with --scenario design_studio, or load it into a running container with POST /_rystic/scenario {"name":"design_studio"}.
2. A scenario file. Users, channels, memberships and message history as Slack’s own objects, with a pinned clock, credentials and events. Seeding state has the shape and an example, and Scenarios and seeding covers every simulator. Load it with POST /_rystic/seed, or boot it with --seed.
3. Timed events. Something that happens during the episode: a teammate posts, someone reacts. An event fires when the simulator’s clock reaches it, either on its own under RYSTIC_PACE=1 or when your harness advances the clock.

The first example on this page is a timed event that posts as a person, ten minutes into the episode, with the clock advanced to fire it.

That post lands in #help (CWDC0000004) as noor typed it in the Slack client: her user, a client_msg_id and no bot_id. An event’s as needs a credential bound to that person, which the UI’s bindings provide; a scenario file can carry its own credentials and events instead. The full event format, including events that bind one call’s answer into the next, is in the control plane’s timeline reference.

Reset between episodes

POST /_rystic/scenario {"name":"design_studio"} resets the simulator and loads the scenario again in one call; POST /_rystic/reset leaves an empty workspace, and a POST /_rystic/seed after it loads yours. The UI stays signed in through all of them: after a reset, a scenario or seed load, a credential binding or a simulator restart, it binds every person’s token again before it redraws an open page. It binds with keep, so a binding your harness or scenario file made stays as it is.

curl -s -X POST http://localhost:8080/_rystic/scenario -d '{"name":"design_studio"}'

An open browser page redraws by itself after any of these; nobody reloads it. To know the redraw has happened, read GET http://localhost:18433/world.json: its generation rises once the changes stop for 150 ms (one second after the first at most) and the UI has bound its tokens again; the page then reloads signed in as the same person. Until then settling reads true, and a page opened meanwhile waits for it. After a reset the page also forgets the drafts and sidebar state it kept for the last episode. A page whose person has no bound token, as on an empty workspace, says it can’t sign in rather than act as anyone else.

Read the end state

Everything an agent did, in the UI or through the Web API, is in the simulator’s state and its call log.

1. The Web API, as any Slack client reads it: conversations.history, conversations.replies, reactions.get, pins.list and the rest, with a bound token or with X-Rystic-Actor: <user id> on any token.
2. GET /_rystic/inspect: the whole workspace as a register map, the shape POST /_rystic/seed takes.
3. GET /_rystic/calls: every request since the last reset, with the principal that made it, its args and whether Slack served it (ok, and error for a refusal). A post from the UI carries the acting person’s token, so the log says who did what.

A grader that checks dana replied in the studio-closure thread in #general:

import requests

B = "http://localhost:8080"
r = requests.get(f"{B}/api/conversations.replies",
                 params={"channel": "CWDC0000001", "ts": "1770993963.000133"},
                 headers={"Authorization": "Bearer xoxp-ui-UWDC0000001"}).json()
assert r["ok"], r
replies = [m for m in r["messages"][1:] if m.get("user") == "UWDC0000001"]
assert replies, "dana did not reply in the thread"

A message posted from the UI is the one a person types in Slack: its user is that person, it carries a client_msg_id and it has no bot_id. Message ts values come from the simulator’s clock, which design_studio pins at 2026-03-01T00:00:00Z, so compare text and authors rather than timestamps.

What the UI supports

Every row of the UI’s feature list, as its own tests last left it. Works means the UI does it against the simulator and a test checks the result through the Web API; the Web API column names the methods it calls, which are what a grader reads. Write tasks against the Works rows.

Works.

Gap: the UI shows it, and it does not yet work as it does in the real service.

Out: the UI leaves it out on purpose.

Measured footprint

Measured in November 2026 on a Linux x86_64 box with 8 vCPUs and 31 GB (an AWS m7i.2xlarge shared with other jobs), with every simulator and UI server on the same box as the browser that drove them.

Memory and CPU are per process, averaged over the environments; 100% CPU is one core. One environment’s simulator and UI server hold about 130 MB together and use about a fifth of a core while an agent works in the UI, and almost nothing while it is idle.

Cold start, for one environment: the simulator answered in 282 ms, the UI bound its tokens in 140 ms more and answered in another 112 ms, and a browser drew the first page 679 ms after opening it. From docker run, with an empty workspace, the container’s simulator answered at 398 ms, its UI at 604 ms, and the health check, whose first run is 5 seconds in, passed at 5.7 s.

How many fit on a box. Four environments ran side by side with no failed call and every p95 within about twice one environment’s. At eight, still with no failed call, the Web API p95 reached 123 ms, 3.5 times one environment’s 35 ms, and the run stopped there, before 16 and 32. Memory was far from the limit, under 1 GB for all eight; the simulators, UI servers and their browser pages shared the 8 vCPUs. Plan on about 130 MB and a fifth of a core per environment for the simulator and the UI server, plus the agent’s browser.

How it was measured. Each step started its environments from the same builds, each in design_studio with live updates on, and opened one headless Chromium page per environment. It held the pages idle for 15 seconds, then for 60 seconds every page at once opened #help, posted, opened a thread in #general and replied, and switched to another person and back. Then it reset each environment three times, reloading the scenario and binding the tokens again, and timed each until the page had redrawn. Memory and CPU were sampled every second for every simulator and UI server process, and the Web API times are every call the pages made, from the browser through the UI server to the simulator. A call fails when it answers a server error, never answers or answers "ok": false, and a post or reply counts only once the simulator has accepted it and the page shows it at the ts the simulator returned. A step counts as degraded when any page never draws, when more than 1% of calls and actions fail, or when a p95 passes three times the one-environment step’s (with floors of 100 ms for the Web API, 2 s for a UI action and 5 s for a redraw), and the run stops at the first one that does.

Limits

1. One workspace per container. Run one container per parallel episode; the measured footprint above says how many fit on a box.
2. The UI’s browser state is the browser’s. A reset clears what the UI kept for the last episode, but a harness that reuses a browser profile across tasks should still start each task at a URL that names its person.
3. Events need a clock. Without RYSTIC_PACE the clock moves only when you advance it or a request takes a simulated step, so a timed event fires when your harness says.
4. The simulator’s own limits are on the Slack simulator page.