What the AI demo contains

How a run of the disposable Uclusion demo goes, who takes part, and what the exercise is testing.

The disposable demo hands a coding agent a small collaboration exercise against real Uclusion records, and ends by asking that agent what it thought. It is not a script the agent follows: it is given the published workflow and a workspace with a problem in it, and what it does is its own.

Uclusion’s demo files live in a throwaway directory under /tmp. The demo keeps your coding client’s existing login. Codex keeps its settings too, while the Claude sessions start in the throwaway directory and load none of your own Claude settings, instructions, skills or plugins, global or from your project. The demo’s workflow, MCP selection and additional permission grants do not require persistent changes to your client configuration. uclusion demo --remove removes the demo files and stops any demo sessions still running.

How a run goes

You paste the prompt from the Uclusion landing page into the coding agent you already have open.
That agent shows you what the install writes, what it will start, and what each started session is allowed to do. Nothing happens until you say yes.
It runs the demo install command for your selected client, Claude Code or Codex.
The installer takes a private demo workspace that Uclusion built in advance, so it is ready at once, and installs Uclusion’s own command-line client, workflow and instructions into the throwaway directory. If none is waiting, one is built on the spot, which takes a few minutes.
The installer prints a read-only progress command and a read-only result command, hands the exercise to a supervisor running on its own, and returns. Your agent follows the run with those two commands, so nothing waits on one long command that a client’s timeout could cut short.
The supervisor starts the workshop owner, waits until it is listening, then starts the evaluator with a one-line instruction naming the first job, such as Start J-Demo-1.
The evaluator works the job: reading records, asking questions, weighing options, and responding to the owner. This takes several minutes and nobody supervises it.
The owner answers through ordinary Uclusion records. Everything between the two travels that way, never through a private channel.
The evaluator presents its work for the owner’s review.
The owner responds, and the evaluator finishes the exercise. Its evaluation includes any completion actions that failed or remain unfinished.
The evaluator answers the evaluation questions as ordinary Uclusion records. It then publishes the complete evaluation to this run’s designated report file inside the disposable demo directory.
The supervisor sees the report and stops the sessions it started. The evaluator does not have to exit itself. The supervisor then measures how many tokens the evaluating agent spent on Uclusion itself, from that agent’s saved session log, and saves the breakdown beside the report. The evaluator never sees those numbers. uclusion demo --result --wait then prints the report unedited followed by the breakdown, and your agent shows both to you. See How many tokens Uclusion itself uses for what each line means.
Your agent briefly offers to answer your questions about the report and Uclusion, using the report, what it already knows about your local environment, and the supplied landing page, documentation, blog, and public UI repository as needed.

A report is ready only when the complete file has been published. Drafts, partial files, reports from earlier runs and terminal output do not finish the run. An evaluator failure before publication is a failed demo. Failure or interruption also stops the sessions started for that run.

Who takes part

Your agent installs the demo and shows you the result. The demo gives it two read-only commands and no other Uclusion access. uclusion demo --progress prints a single line estimating progress from the local notification log until the current run publishes its evaluation. It then reports 100% and points to demo --result. It reads only local files and changes nothing. With --wait it returns when the estimate moves, the report appears, or about 100 seconds elapse. uclusion demo --result prints the evaluator’s report once it is published, or says why there is none. With --wait it returns when the report appears, or after about 100 seconds. After showing the report, your agent offers concise answers to your questions using its existing context and the supplied resources.

The workshop owner plays the human side of the exercise. It learns when it is needed from uclusion watch and answers through records with its Uclusion MCP tools. The Claude owner holds that watch open itself and uses the CLI for nothing else. For Codex, the installer holds the watch and hands the owner each notification, so the Codex owner is never told about the CLI. On either client it starts no Poke listener, because it shares the evaluator’s credential and a listener would hand it the evaluator’s events. In the demo, that watch also logs the type of each notification it receives, which is what the progress estimate is made from: which kinds have appeared marks how far the exercise has got, because notifications are removed as well as added along the way. Its replies represent the human side of the exercise and notify the evaluator, which continues the work.

The evaluator is the agent being asked for an opinion. It receives the starting job, the evaluation questions and the published workflow. It uses ordinary Uclusion tools, with no owner’s script or coaching toward an answer. It reports on Uclusion alone and is told not to guess about your project.

The owner and the evaluator are separate client sessions holding the same restricted demo credential. They are separate processes rather than one agent and its sub-agent, because the exercise is asynchronous: an agent that ended its turn inside another’s session would not be there when the answer arrived.

For Codex, the owner runs through codex exec. Its first turn reads the brief and the job; the evaluator starts once that turn has ended cleanly. The installer runs the demo CLI’s watch command itself and, for each batch of notifications, resumes the owner’s session with codex exec resume. The evaluator runs through ordinary codex in an installer-controlled pseudoterminal, using the installed native Uclusion delivery adapter. Its uclusion demo --report command accepts the complete evaluation on standard input and publishes it atomically. The installer keeps the session inputs, owner output and evaluator terminal log in the run directory for diagnosis. For Claude, both sessions run as claude subprocesses started in the demo directory, and the evaluator publishes through the same uclusion demo --report command. The installer keeps the session inputs and both sessions’ output in the run directory.

Codex discovers the installed demo workflow through a disposable HOME, while its native CODEX_HOME retains authentication and settings. The demo selects its own Uclusion MCP server for each session, adds approval for its own CLI, and adds access to the demo files. These grants follow the Claude demo’s additive model: existing native permissions, including stricter rules, still apply.

Starting Codex and choosing permissions

Use the demo install command supplied by the landing-page prompt. The installer starts both agents automatically; you do not launch a second owner or evaluator. For ordinary work after installing Uclusion, start codex from your project and tell it go. The installed MCP registration selects the Uclusion environment.

The demo’s child sessions load the native Codex configuration identified by CODEX_HOME (normally ~/.codex), and both use its sandbox setting. The evaluator asks for approval under that configuration’s approval policy. The owner runs non-interactively through codex exec, so it never asks: a command the sandbox blocks simply fails for the owner, while the evaluator can ask to step outside the sandbox. The demo directory does not confine what a session can read under that sandbox. A one-off permission flag on the agent that installs the demo is not forwarded to those children. Choose their permissions in that native configuration before starting the demo; see the official OpenAI configuration guidance. Keep the native profile in its normal location rather than creating one under /tmp; the demo’s disposable files can still live under /tmp.

General sandbox compatibility has not been established by this rehearsal. Its isolated native profile under /tmp produced helper and socket errors in workspace-write mode. Full access let both agents start and export the workspace, but the exercise later stopped on a separate notification defect. That is evidence of a startup workaround, not a completed demo or a reason to disable the sandbox for every user. The installer preserves your configured permissions.

What the evaluator finds

A workspace with two jobs in it, oldest first:

1. J-Demo-1 — Document the volunteer loan handover decision
2. J-Demo-2 — Outbound integration review

J-Demo-1 is the assigned work: publish a decision handoff note for volunteer loan handovers, recording the agreed transport, the reasons, who is responsible for what, and what is still unknown. J-Demo-2 is an older review that overrides part of the design J-Demo-1 hands it. Nothing points at it. An agent that searches the workspace history finds it and reaches a different answer than one reasoning from its assigned job alone.

A standing view note carries constraints only: no application code, no application tests, no browser; use the supplied sample data for demo writes; take parameter names from the connected tool schemas. It contains no procedure for solving the exercise and no prescribed wording.

Three workflow rules decide how the run goes, and the demo repeats none of them to the agent:

Search the history before relying on a design you did not write, and cite what you find. This is what surfaces the older review.
Finding older input you had not read is not a new contract. Raise it as a question rather than quietly rewriting the design.
When accepting a suggestion that revises an option, record any required suggestion vote first, then update that option and resolve the suggestion in one call. The option keeps its identity and votes; its updated wording records acceptance without a separate reply.

What the owner does

Two planned decision interactions, each waiting on something the agent has actually done:

Suggests a change to the option the agent voted for - as a suggestion under that option, which is what obliges the agent to revise the option itself rather than argue in a reply.
Votes for that option, with its reasons - cast on the option, so the reasoning is carried by the record rather than by the conversation.

Beyond those it answers from the supplied facts, and marks unknown partner capabilities or confirmation behaviour as unknown so they stay as follow-ups. It does not invent facts, coach tool usage, write the agent’s document, or evaluate Uclusion on the agent’s behalf. If the agent never creates a question with options, the first interaction has nothing to attach to, and the owner cannot create that work for it.

The owner accepts the completion actions at the end of the exercise. The evaluator’s report includes their outcome and any unfinished actions.

What the exercise is testing

Two things: whether the record was worth keeping, and whether the workflow was worth following.

The first is answered by the history. The agent arrives holding a design it did not write. The reasons behind it, and the later decision that overrides it, are recoverable from records written before the agent existed.

The second is answered by what the collaboration produces. Nobody told the agent which question to ask, which option to prefer, or to revise an option rather than argue with the suggestion. The run records whether those behaviours actually occur - and then asks the agent, in its own words, whether any of it was useful.