What Stop stops

Side A: Stop stops the queue

Tap Stop and everything the agent has queued is cancelled: the model call, tool calls that have not run, table writes, background jobs, pushes. Each queued step checks "was Stop tapped?" right before it runs. The thread then shows a receipt: what ran, what did not.

Steel man. Stop is a brake, and a brake has to work every time. You tap Stop because something is wrong: the wrong photo, the wrong week, the wrong person. You cannot know which queued job carries the mistake, so you stop them all. A Stop that lets things slip through is a decorative pedal, and once a person catches it lying they stop trusting every button in the app. Agents on Moltbook make the same point about permissions: a grant you cannot revoke mid-queue was never revocable. One rule, no surprises.

Straw man. Stop is a panic button that nukes everything. You tap it to hush a long reply and lose a four-minute song render, the grocery list from ten minutes ago, and the reminder you set this morning. Every tap is a gamble, so people stop tapping it.

Side B: Stop stops the reply, the rest goes on

Tap Stop and the reply you are watching ends. The agent stops talking and listens. Work it already handed off keeps running: renders, saves, reminders, other threads.

Steel man. Stop is how you get the floor back. Most of the time you are not saying "undo everything," you are saying "enough, listen to me." The expensive, slow work (a song render, a meal breakdown, a week plan) is exactly the work you want to survive a tap. Background jobs already show as rows you can open; if you want one gone, you stop that one. This is how a person works with a helper: "hold on a second" does not mean "throw out everything you did today."

Straw man. Stop is a mute button. The agent keeps writing to your tables, sending, scheduling, while the screen says "Stopped." You find out a minute later when the wrong meal lands in your log. The screen lied to you.

The middle path (Yui's pick)

Stop ends the reply and cancels everything that reply queued that has not started yet. Work that is already running for a while, or that came from an earlier message, keeps going, and the receipt says so with a button to stop it too.

• Fresh work from this turn: cancelled.
• Long jobs already under way: keep going, named in the receipt, one tap to stop.
• Anything from earlier (reminders, timers, other threads): untouched.

The hero at the top of this page is that receipt.

Scenarios

1. Basil and the wrong photo. You snap your lunch, but it is the photo from yesterday. Basil starts working out the macros, saving the meal and updating your groceries. You tap Stop.

   • Side A: nothing is saved. Good.
   • Side B: the wrong meal lands in your log a few seconds later. Bad.
   • Middle: all three were queued by this turn, so all three are cancelled. Good.

2. Gouda's song and a quick question. Gouda is rendering a two-minute song. While it works, Gouda starts a long reply about chords. You tap Stop to ask something else.

   • Side A: the song render dies. You wanted it.
   • Side B: the reply stops, the song keeps going. Good.
   • Middle: the render was already running, so it keeps going, and the receipt says "Your song keeps rendering" with "Stop the song too." Good.

3. Penny plans the week. You ask Penny to plan your week. She has saved Monday and Tuesday when you notice she put your gym time over your 3 pm meeting. You tap Stop.

   • Side A: Wednesday to Sunday never get written. Monday and Tuesday stay, and the receipt says so.
   • Side B: Penny finishes all seven days with the clash. You fix it by hand.
   • Middle: same as Side A, because the rest of the week was queued by this turn.

4. A timer from this morning. Arnold started a rest timer an hour ago. Now he is answering a new question slowly and you tap Stop.

   • Side A, read strictly: is the timer part of "the queue"? If yes, it dies. Surprising.
   • Side B: the timer keeps going. Good.
   • Middle: earlier work is never touched. Good.

5. Yui files a card. You ask Yui to add something to the board and to tell the team. It has created the card and is about to post the note when you tap Stop.

   • Side A: the card stays (it already happened), the note is never sent.
   • Side B: the note goes out anyway.
   • Middle: the note was queued by this turn, so it is cancelled. The receipt says "Card created. Note not sent."

Whichever side wins: Stop has to hold where the work is saved

Added Sep 29, from a Moltbook thread that named the trap: "A polished Stop button has the same problem if the server still accepts the write. Lovely animation, though." So, for either side:

• Checked at the save, not at the start. Every write a turn makes re-checks "was Stop tapped?" in the same step that saves it. A job that read "go" ten minutes ago can't land after you tapped Stop.
• Not sure is its own answer. If a step was mid-flight when you tapped, and we can't tell whether it landed, the receipt says "not sure, checking" and then the truth. It never retries on its own, so one meal never becomes two.
• The receipt shows what happened, not what the agent meant to do.

The wider version of these rules is in four proposals: Fresh asks, Checked when it's saved, Not sure is an answer and Receipts.