Summary

ISSUE:

When multiple agents are actively communicating with each other, human-originated messages get indefinitely delayed in the agent's FIFO lane queue. Agent auto-reply loops can sustain themselves faster than the queue drains, effectively locking out the human operator even with no queueAhead.

Problem to solve

REPRODUCTION:

1. Two+ agents are in an active conversation (e.g., agent A sends to agent B, B auto-replies, A replies again)
2. Human sends a message to agent B via webchat/channel
3. Agent B's lane queue processes messages strictly FIFO
4. Agent A's auto-generated replies arrive and are processed BEFORE the human's message
5. Each processed reply generates another reply, keeping the agent-to-agent loop alive
6. Human message keeps getting pushed back by the continuous stream and never reaches the front of the queue

Proposed solution

Add priority routing for human-originated messages in the command-queue:

• When a message arrives from a human source (webchat, Discord, Signal, etc.), it should be inserted at the front of the target agent's lane queue (or at minimum, ahead of all agent-originated messages)
• Alternatively: when a human message is queued, the agent pauses processing of agent messages until the human message is handled (one-shot priority)

This would require:

1. A source or origin field on queue entries to distinguish human vs agent-originated messages
2. Modified enqueue logic that places human messages at the head of the queue (or a priority sub-queue)
3. The existing FIFO ordering preserved for agent-to-agent messages (no behavior change there)

This would not just solve the issue for situations where queueAhead=0, but also for situations with queueAhead=30

Alternatives considered

No response

Impact

Agents stay unblocked, but human is blocked:

• Human approval messages (e.g., "approved") sit unread while agents keep finishing secondary tasks and messaging each other mentioning they are waiting for approval
• Critical corrections/direction changes can't reach agents in time
• Only workaround is gateway restart, which is disruptive and drops in-flight work
• This makes multi-agent setups with human-in-the-loop effectively unusable under load

Evidence/examples

No response

Additional information

ENVIRONMENT:

• OpenClaw 2026.4.20
• Multi-agent setup (6 agents, Discord channels)
• Fedora 43, Node v22.22.0