Conversation
…reads A human @mention is an explicit addressing decision, but dynamic and workflow threads handed every message to the LLM router, which re-decided who should answer. Since the thread picker adds every workspace agent as a participant by default, the router kept picking bystanders the user never added to the thread (openagents-org#333). Route human messages that carry a workspace-known @mention straight to the mentioned agents and skip the router call. Agent-authored mentions still go through the routers, and master mode keeps its star topology. Fixes openagents-org#333
|
@nolanchic is attempting to deploy a commit to the Raphael's projects Team on Vercel. A member of the Team first needs to authorize it. |
develop now resolves a LEADING @mention from an agent deterministically (_explicit_agent_targets), so the message in this test no longer reached the router. Move the mention off the first token; the test's point — only human mentions are made deterministic by this change — is unchanged.
zomux
left a comment
zomux
left a comment
There was a problem hiding this comment.
Approve. The bug is still live on current develop: the deterministic handling added since (_explicit_agent_targets) covers agent messages with a leading @mention and returns nothing for human senders, so a human's @mention in a dynamic thread still went to the LLM router. Verified on a merge with develop: your bypass tests fail without the change and pass with it, the built-in assistant's protection still applies (its mentions are stripped before this guard), auto-adding mentioned agents on a human message is pre-existing behavior, and the full backend failure set is identical to develop's. I pushed one commit: test_agent_mention_still_uses_llm_router opened with '@agent-master', which develop now resolves deterministically before the router, so the router was correctly not called; the mention is moved off the first token and the test's intent is unchanged. Design note for the record: human mentions also bypass workflow mode's plan-steered router, which I think is right.
3 participants
Fixes #333.
Reproducing the report: in a thread, @-mentioning one agent made other agents that were never added to it reply anyway. Two things stack to cause that. The thread picker adds every workspace agent as a channel participant by default, so "not part of the thread" isn't something the backend can see — everyone is a participant. And in a multi-agent thread with the default "dynamic" orchestration,
_handle_message_postedhands every message to the LLM router, which picks whoever it thinks should answer next based on the conversation. The router never sees the user's explicit choice: the "@name → route to that agent" rule in the handler's docstring only exists in the no-router fallback path. So the mention gets re-decided, a bystander answers, and routing then auto-adds it as a participant — from that point it's in the conversation for good.The fix is the smaller of the two changes discussed in the issue: when a human message carries a mention of a known workspace agent, treat it as the addressing decision it obviously is and route straight to those agents, skipping the router call. Agent-authored mentions still go through the routers (a peer @mentioning another peer is a delegation, not a user choice), and master mode keeps its star topology — the hub owns every human request.
Verified the tests catch the old behavior (they fail on main, pass here), and the full backend suite has the same failure set before and after this change. Added
TestHumanMentionDeterministicRoutingcovering: single mention bypasses the router, multiple mentions target all mentioned agents, unknown @tokens still fall through to the router, agent mentions still use the router, and master mode is unchanged.One follow-up worth considering separately: the default-everyone participant list in
createSessionis what makes threads look like whole-workspace broadcasts in the first place. Changing that is a product decision (empty threads, UI affordances), so I left it alone here.