Summary

When a user sends multiple messages in quick succession while an agent is still processing a previous message, several observable behaviors occur that create a confusing user experience. I would like to understand the intended design and whether these behaviors are expected or represent areas for improvement.

Observed Behaviors

1. Message Content Replacement (Not Queueing)

Observation: When message B arrives while message A is being processed, message A's content appears to be replaced/discarded, and only message B is processed.

Expected vs Actual:

• User expectation: Both messages would be processed sequentially (FIFO)
• Actual behavior: Only the most recent message is processed

Question: Is the intended design that new messages should interrupt and replace pending ones, rather than queueing? This creates data loss from the user's perspective.

2. Response References Wrong Message (Confirmed Bug)

Observation: In some cases, the agent's response appears to reference message A (the first message) while actually answering message B (the second message), or vice versa. The context seems to get mismatched.

Example:

• User sends: "Check the weather in New York"
• User sends (3 seconds later): "Check the weather in Los Angeles"
• Agent responds about Los Angeles weather but the reply context/threading suggests it's responding to the New York message

This appears to be a bug where the message context/metadata gets out of sync with the actual content being processed.

3. Task Termination Behavior is Unclear

Observation: When a new message arrives during active processing, it's unclear whether the previous task:

• Is immediately terminated (hard stop)
• Continues running to completion despite the interrupt signal
• Is gracefully wound down at the next checkpoint

From the user's perspective, long-running operations (e.g., terminal commands, file searches) appear to continue even after sending a new message, creating confusion about whether the interrupt actually worked.

Question: What is the intended termination semantics? Should users expect immediate cancellation, or is the cooperative interruption model the explicit design choice?

Design Intent Questions

1. Interrupt vs Queue Philosophy: Is the design intentionally "last message wins" (LIFO) rather than FIFO? If so, would it be helpful to notify users when a message is being replaced rather than silently dropping it?

2. Preemptive vs Cooperative Interruption: The code shows _interrupt_requested flags being checked at various checkpoints. Was this cooperative model chosen to prevent data corruption (e.g., half-written files), or would a more aggressive termination model be considered?

3. UX for Message Replacement: Would you be open to a notification like "⏹️ Previous task cancelled, processing new request..." so users understand their first message was dropped?

Context

This was observed when using the Telegram integration, where users naturally send follow-up messages before receiving responses (especially during long-running operations). The current behavior feels contradictory:

• The system accepts new input immediately
• But it silently drops previous input
• And may still complete the previous operation anyway
• While referencing the wrong original message

Would appreciate clarification on which behaviors are intentional vs potential issues to address.

Environment:

• Platform: Telegram
• hermes-agent version: Latest main branch (as of 2025-01)