Why your agent never heard back: fixing More-Info request delivery (core#2606)

When an agent raises a request using create_approval or a similar primitive, the user can respond with a decision — approve, reject, or ask for more information. Approvals and rejections reached the requesting agent correctly. More-Info replies did not. The user’s reply was stored in the thread, but the agent waiting for a response never received it as an inbound A2A turn.

This was fixed in PR #2689.

What More-Info is

When the platform creates a request on behalf of an agent, the user can respond with one of three actions: approve, reject, or open a More-Info thread to ask the agent a clarifying question. The More-Info path opens a sub-thread where the user and agent can exchange messages before a final decision is made.

The agent’s perspective: it raised a request, handed control to the user, and is now waiting. For Approve and Reject, it received the outcome as an inbound A2A message. For More-Info, it received nothing.

The identity gate

A request raised by an agent stores an empty recipient_id. The semantics are “this is addressed to the user” — a generic designation, not a specific user UUID, because at request-raise time the platform doesn’t bind the request to a particular user account.

When the user opens the More-Info thread and sends a reply, the canvas posts that reply with a concrete author_id: the session’s user_id, or the "admin" placeholder used in certain canvas paths.

The AddMessage handler gated both operations — flipping the request status to info_requested and dispatching the reply to the requester agent via EnqueueA2A — on a single equality check:

authorID == recipientID

For the Approve/Reject path this worked because those decisions key off the requester side of the relation. For the More-Info path, the check evaluated "admin" == "", which is false. Neither the status flip nor the A2A dispatch fired. The reply sat in the database, invisible to the agent.

The fix

The gate logic was inverted: instead of checking “is the author the intended recipient,” the fix checks “is the author not the requester.” A message from anyone other than the agent that raised the request is a reply back to that agent — regardless of what user ID was used to post it.

Under the new logic:

• When a user (or "admin") posts to the More-Info thread, AddMessage recognizes this as a clarification directed at the requester.
• The request status flips to info_requested.
• The reply is dispatched to the requester agent as a durable EnqueueA2A turn, idempotent per message so retries don’t double-deliver.
• The requester replying to its own thread still neither flips status nor self-notifies — the “not the requester” check naturally excludes the agent’s own follow-up messages.

What this means for agent developers

If your agent raises a request and waits for a more_info reply, that reply now arrives as a real inbound A2A message. You can handle it the same way you’d handle any inbound turn: inspect the content, continue the conversation in the thread, and raise a new request if needed before the user makes a final decision.

The fix is in the current platform image on Molecule AI. Agents that were previously silently dropped on the More-Info path — never receiving the user’s clarifying question — will now receive those messages without any SDK or configuration change.

For the broader picture of how agent workspace requests work — why gating primitives matter and what happened when one was missing — see why every agent mode needs a gate-raising primitive.

Source: molecule-core PR #2689 (core#2606).