What the AI demo contains

The records a coding agent finds when it runs the disposable Uclusion demo, the workshop owner’s role, and what the exercise is testing.

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

That is why this page shows the records rather than a sequence of calls. The Markdown below is what the demo’s fixture creates, taken from the code that creates it, and the short codes are the ones its creation order produces. It is what the agent should find, not a transcript of a run.

The two participants

Two users appear in the records: the agent, and the workshop owner. Every comment and vote attributed to the owner is part of the exercise and fires in response to something the agent did. The owner has three planned interactions and can answer additional questions or suggestions from the supplied scenario. The owner stops when the agent presents its ordinary completion package and leaves every completion action unselected.

The agents share one demo connection. On the demo’s add_info, make_suggestion and approve_job_or_option tools, the owner explicitly passes participant: "human"; omitted participants default to ai. This records the declared participant without guessing from the kind of record or who voted first. It does not give the two agents separate authentication.

What the agent finds

start_demo returns a workspace id, the starting job short codes, and one short instructions field that points at a view note. It does not contain the exercise.

The view note carries constraints only: no application code, no application tests, no browser, no delegation; demo writes use the supplied sample data; take parameter names from the schemas start_demo returned; keep the process running and never display its proof. It contains no procedure for solving the exercise or prescribed wording for its records.

Work discovery returns two jobs, oldest first:

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

The assigned job

## Job J-Demo-1
### Document the volunteer loan handover decision
Volunteers hand loan records over on paper at collection, so the partner only
learns about a handover when someone types it in later. Publish an integration
decision handoff note for volunteer loan handovers in this job, separate from
its current intent/design capsule. The handover approach is agreed and recorded
here. The finished note must record the selected transport, supporting reasons,
agreed responsibilities and explicit implementation unknowns. Verify the
published note against the chosen option, relevant policy records and supplied
examples. Unknown partner-read capability and collection-confirmation behavior
are implementation follow-ups outside this document's acceptance scope; record
them without inventing answers. Completing this documentation job does not
require implementing the integration.

This job is in stage Doable.

#### Current intent/design capsule
##### Current intent/design capsule R-Demo-1 (for Job J-Demo-1)
Publish a decision handoff note in this job, separate from this governing
capsule, documenting the agreed approach: each volunteer loan handover is pushed
to the partner's webhook receiver at the moment it happens. The partner hosts
and maintains the receiver. A volunteer at collection sees the handover already
confirmed by the partner rather than finding out the next day. The note records
the selected transport, its supporting reasons, agreed responsibilities and
explicit implementation unknowns. Verify the published document against the
chosen option, relevant policy records and supplied examples. Unknown
partner-read capability and collection-confirmation behavior remain
implementation follow-ups outside the document's acceptance scope; the
deliverable does not invent answers or implement the integration.

The work product is a decision handoff note, separate from this governing capsule. The agent must verify that document against the agreed option and the supplied history. Unknown implementation facts remain explicit follow-ups; finishing the document does not mean the integration has been built.

The current design relies on a settled decision, so the agent’s first obligation under the workflow is to load it and check it has not gone stale. The decision it came from is still in the job, resolved, with its options intact:

#### Resolved
#### Question Q-Demo-1
How should a loan handover reach the partner system?

#### Option O-1
#### Nightly CSV to the shared drive
Write one file a night to the drive both sides already use, and let the partner
import it on its own schedule.

#### Option O-2
#### Partner pulls from a read-only endpoint
Publish the handovers we have recorded and let the partner read them whenever
it needs to.

#### Option O-3
#### Push each handover to the partner webhook
Send each handover to the partner's receiving endpoint at the moment it happens.

> ##### $${\color{green} 100 out of 100 - Very Certain Reason \space For}$$ E-1
Volunteers at collection need the partner to already know about a handover by
the time the borrower reaches them, and a file written overnight cannot do
that. The partner has offered to host and maintain the receiver, so the cost
and the maintenance burden that made us refuse this last year are gone. Push
rather than a pull endpoint because the partner runs no scheduler of its own
and asked us to drive the timing.

The reasons sit on the option that won, which is the only place a workspace export carries them. That is what makes them findable later by an agent that was not there when the decision was made.

The decision the design does not mention

Nothing in the assigned job refers to the other job. The export is what reaches it:

## Job J-Demo-2
### Outbound integration review

#### Resolved
#### Question Q-Demo-2
What may the loan system send outside the workshop, and how may it send it?

> #### Reply C-Demo-1
Settled after the handover approach was agreed, and it changes what that
approach may use. Nothing in the loan system may push directly to a partner
endpoint. Anything leaving the workshop goes to the shared drive, or to a
read-only endpoint we serve and the other side reads when it wants. Two
failures drove this. A partner endpoint we pushed to went down over a weekend
and the handovers that failed were only noticed on the Monday. A second partner
changed its URL without telling us. In both cases the volunteer had already
released the tool and saw nothing wrong. A file on the drive, or an endpoint we
serve ourselves, leaves the record where we can still see it.

So the design is current and forbidden at once, and the option it chose is the one the later review rules out. The two options that remain are both already in the record.

What the workflow requires of the agent

Three of its rules decide how the run goes, and none of them is repeated to the agent anywhere in the demo:

Search the export before relying on a design you did not write, and cite what you find. This is what surfaces the review.
Finding older input you had not read is not a new contract. It is raised as a question instead of used to rewrite the design, which is why the agent asks rather than quietly switching the approach.
When accepting a human suggestion that revises an option, update that option rather than replacing it, so the option keeps its identity and its votes.

What the owner does

Chooses the work. The agent presents the numbered list; the owner answers with 1.
Suggests a change to the option the agent voted for. A suggestion under that option, not a reply in the thread, which is what obliges the agent to revise the option itself.
Votes for that option, with reasons. Cast on the option, so the reasoning is carried by the record rather than by the conversation.

Each waits on something the agent has actually done. If the agent has not created a question with options and voted on one, the second action has nothing to attach to. The owner can handle an additional question or suggestion within its role, but cannot create the missing work on the agent’s behalf.

Alongside those interactions and after the vote, the owner can answer from the supplied facts and priorities. It identifies unknown partner capabilities, schedules or confirmation behavior as unknown; those can remain follow-ups in the decision handoff. It does not invent facts, coach tool usage, write the agent’s document or evaluate Uclusion for it. A request outside those boundaries ends the sample with the unanswered request and current state preserved.

A capsule update no longer ends the exercise. The agent must finish and verify the handoff document, open its ordinary review and present the completion package. The owner then stops without selecting all, none or any action number, and forwards the agent’s final message unchanged. The workflow permits inapplicable commits and pushes to be no-ops; the demo exercises reaching the package, not executing its actions.

What the exercise is actually testing

Whether the record was worth keeping, and whether the workflow was worth following.

The first is answered by the export. The agent arrives holding a design it did not write, and the reasons behind it, and the later decision that overrides it, are all recoverable from records written before it existed. An agent that finds them reaches a different answer than one reasoning from the job alone.

The second is answered by what the collaboration produces. The agent was not told which question to ask, which option to prefer, or to revise an option rather than argue with the suggestion. Its assigned work asks for a verified handoff document; the shipped workflow governs how it reaches that result and requests review. The run records whether those behaviors and the completion package actually occur, including any additional owner responses needed along the way.