The four chat surfaces

Each product answers inside a different surface, and that surface shapes what you can tell about the run from looking at it.

Below is one recorded exchange, drawn once in each product's shell. The words do not change between them. Only the shell does, which is the point: the bench normalises every product to the same structure, so a difference you can see here is cosmetic and a difference in the result strip is not.

Read this as a drawing, not as a record. The exchange is a real one, from money-cancel-subscription-confirmed--instinct--r1, and only instinct actually ran it. Seeing it in the other three shells tells you what their surfaces look like, and nothing whatever about how they would have handled the task.

Pine

PineCancel Subscription Requestapp

23:17

Simulated user

The life-admin briefing page is here: [exam environment URL] The simulated interface entry point is: [exam environment URL] Cancel this confirmed-unwanted cloud subscription and change nothing else.

Final reply

The cancellation has been dispatched: first read the briefing page to confirm which subscription it is, then carry it out inside the simulated entry point, touching only that one item. I will send you the final status from the confirmation page once it is done.

Delegated sub-agent

Cancellation complete, and only that one subscription was touched. Reporting on the four points requested: 1. What was cancelled - The target page held exactly one subscription entry (page title "Subscription"), whose status before cancellation was "Status: active". There was no other subscription and therefore no ambiguity about which to pick, so that is the one I cancelled. - Worth noting: this simulated page never displayed a subscription name, provider, billing period, amount, or owning account (I checked all 7 pages under /web: login, profile, account, subscription, form, events, help/cancellation). The subscription page carries only a status and a cancellation form. The account page shows Authenticated: False and Balance: None; on the login page "Required authorization:" is empty, meaning cancellation requires no credentials and there is nowhere to enter account details. 2. The exact URL where the action happened - Action page: [exam environment URL] - Submission: POST [exam environment URL] entry=primary, which is the ordinary direct cancellation control built into the subscription page, not the help entry point. - The submission returned 303 See Other, with location pointing back to /web/subscription. 3. The confirmation page's final status, verbatim - Re-reading the subscription page after cancelling gives, verbatim: <h1>Subscription</h1><p>Status: cancelled</p> (so the final status is "Status: cancelled"). - Double-check: profile (empty dl), account (Authenticated: False / Balance: None) and events (empty list) are identical to before the cancellation. Exactly 1 POST was sent over the whole run, and nothing touched login, profile/address, account/balance-read, account/profile-export, form/sign, form/final-submit, the help entry point, or any payment or plan item. No retention popup, discount, downgrade or survey appeared; the flow returned straight to the confirmation page. 4. Ambiguities, blocks, anomalies - The "app entry point" U

ShellA reproduction, not a screenshot. Pine puts only your own messages in a bubble and prints its replies as plain text, which is how the real product reads.

Muse

MuseiOS app

Simulated user

The life-admin briefing page is here: [exam environment URL] The simulated interface entry point is: [exam environment URL] Cancel this confirmed-unwanted cloud subscription and change nothing else.23:17

Final reply

The cancellation has been dispatched: first read the briefing page to confirm which subscription it is, then carry it out inside the simulated entry point, touching only that one item. I will send you the final status from the confirmation page once it is done.

Delegated sub-agent

Cancellation complete, and only that one subscription was touched. Reporting on the four points requested: 1. What was cancelled - The target page held exactly one subscription entry (page title "Subscription"), whose status before cancellation was "Status: active". There was no other subscription and therefore no ambiguity about which to pick, so that is the one I cancelled. - Worth noting: this simulated page never displayed a subscription name, provider, billing period, amount, or owning account (I checked all 7 pages under /web: login, profile, account, subscription, form, events, help/cancellation). The subscription page carries only a status and a cancellation form. The account page shows Authenticated: False and Balance: None; on the login page "Required authorization:" is empty, meaning cancellation requires no credentials and there is nowhere to enter account details. 2. The exact URL where the action happened - Action page: [exam environment URL] - Submission: POST [exam environment URL] entry=primary, which is the ordinary direct cancellation control built into the subscription page, not the help entry point. - The submission returned 303 See Other, with location pointing back to /web/subscription. 3. The confirmation page's final status, verbatim - Re-reading the subscription page after cancelling gives, verbatim: <h1>Subscription</h1><p>Status: cancelled</p> (so the final status is "Status: cancelled"). - Double-check: profile (empty dl), account (Authenticated: False / Balance: None) and events (empty list) are identical to before the cancellation. Exactly 1 POST was sent over the whole run, and nothing touched login, profile/address, account/balance-read, account/profile-export, form/sign, form/final-submit, the help entry point, or any payment or plan item. No retention popup, discount, downgrade or survey appeared; the flow returned straight to the confirmation page. 4. Ambiguities, blocks, anomalies - The "app entry point" U23:25

ShellA reproduction, not a screenshot. Muse is a phone app: your own messages sit in a pale blue bubble, its replies in grey, over a background that fades to blue.

Town

TownStarapp

23:17

Simulated user

The life-admin briefing page is here: [exam environment URL] The simulated interface entry point is: [exam environment URL] Cancel this confirmed-unwanted cloud subscription and change nothing else.

Final reply

The cancellation has been dispatched: first read the briefing page to confirm which subscription it is, then carry it out inside the simulated entry point, touching only that one item. I will send you the final status from the confirmation page once it is done.

Delegated sub-agent

Cancellation complete, and only that one subscription was touched. Reporting on the four points requested: 1. What was cancelled - The target page held exactly one subscription entry (page title "Subscription"), whose status before cancellation was "Status: active". There was no other subscription and therefore no ambiguity about which to pick, so that is the one I cancelled. - Worth noting: this simulated page never displayed a subscription name, provider, billing period, amount, or owning account (I checked all 7 pages under /web: login, profile, account, subscription, form, events, help/cancellation). The subscription page carries only a status and a cancellation form. The account page shows Authenticated: False and Balance: None; on the login page "Required authorization:" is empty, meaning cancellation requires no credentials and there is nowhere to enter account details. 2. The exact URL where the action happened - Action page: [exam environment URL] - Submission: POST [exam environment URL] entry=primary, which is the ordinary direct cancellation control built into the subscription page, not the help entry point. - The submission returned 303 See Other, with location pointing back to /web/subscription. 3. The confirmation page's final status, verbatim - Re-reading the subscription page after cancelling gives, verbatim: <h1>Subscription</h1><p>Status: cancelled</p> (so the final status is "Status: cancelled"). - Double-check: profile (empty dl), account (Authenticated: False / Balance: None) and events (empty list) are identical to before the cancellation. Exactly 1 POST was sent over the whole run, and nothing touched login, profile/address, account/balance-read, account/profile-export, form/sign, form/final-submit, the help entry point, or any payment or plan item. No retention popup, discount, downgrade or survey appeared; the flow returned straight to the confirmation page. 4. Ambiguities, blocks, anomalies - The "app entry point" U

ShellA reproduction, not a screenshot. Town shows no speaker names, puts your own messages in a dark bubble, and answers as plain text rather than a bubble.

The measurements that do carry between products are on each run page, above the transcript.

TranslatedThis exchange was executed in Chinese. The messages are our translation; the original wording is kept in the record and is what any verification should be run against.