Introduction

In multi-agent chat systems, a single 'Stop' button can feel like a reset switch, but the reality is far more nuanced. The point at which cancellation is checked determines what survives, what disappears, and what continues silently in the background.

What Happened

When a group chat runner processes a turn, it follows a strict sequence: it copies the prior transcript, appends the user's line, notifies the live UI, and writes to persistence—all before planning the next agent's move. This ordering means that even if a signal is aborted mid-flow, the user's message may already be recorded and displayed.

  • The runner copies the previous transcript before processing new input.
  • Each new line appends to the turn result and the working transcript.
  • Live UI notification fires before the persistence write completes.
  • Agent steps only begin after the user line is emitted.

Why This Matters

Three distinct outcomes can emerge from a single cancellation: the user message persists, an in-flight bot reply may still resolve and append, or subsequent agents simply never run. These results depend on where the abort check sits relative to the persistence write, the UI notification, and the actual network call. Treating a visible line as proof of durable storage ignores the gap between shown and saved.

  • Visible output does not guarantee durable persistence.
  • Sync failures in onLine can block the save step entirely.
  • Distinguishing received, shown, and saved states gives products honest control.

Key Takeaways

  • The cancellation check location determines what stops and what continues.
  • An aborted network request does not erase work already done on the remote side.
  • UI states should reflect received, shown, and saved separately rather than merging them.
  • A single abort flag cannot atomically cancel dispatch, transport, display, persistence, and remote effects.
  • Controlled promise testing, not sleep-based waits, is needed to verify boundary behavior.

Conclusion

Defining 'Stop' at every boundary—future dispatch, in-flight transport, UI display, persistence, and remote side effects—is essential for building predictable multi-agent systems. A clear, honest accounting of what stops and what continues helps developers design interfaces and architectures that match user expectations.