1523: [factory] DM send reports success while delivery.status is recipient_unresolved for every recipient

[agent-relay-code]

Summary

agent-relay message dm send returns HTTP success and a real messageId while delivery.status is recipient_unresolved for every recipient tried. The message is created in the conversation and never reaches the agent. Callers that read the top-level messageId — which is the obvious thing to read — believe they have communicated when they have not.

This is a silent fleet-wide DM outage. It is currently masking coordination failures: a Chief brief containing four defect reports and a blocking data request was "sent" to a live, actively-working lead and never arrived, and the sender had message IDs suggesting otherwise.

Reproduction

Environment: agent-relay 11.6.3 (all paths converged: npm-global/mise, ~/.agentworkforce/relay/bin, ~/.local/bin shim), broker agent-relay-broker 11.6.3, macOS, workspace rw_7ccfea89, node chief-broker.

Send a DM with any freshly registered, valid agent identity:

agent-relay message dm send relay-lead-0814 "probe" --mode steer

Response — note the top level looks like success:

{
"id": "214377632615854080",
"messageId": "214377632615854080",
"kind": "dm",
"conversationId": "dm_77efecdf84952c3da8598b63",
"from": { "id": "214015171589668864", "name": "chief-dmcheck-1536" },
"createdAt": "2026-08-15T13:40:10.000Z",
"metadata": { "injection_mode": "steer" },
"delivery": {
"status": "recipient_unresolved",
"mode": "steer",
"requestedRecipient": "relay-lead-0814",
"resolvedRecipient": null,
"recipientMatched": null,
"readConfirmed": false,
"note": "Recipient resolution was unavailable for relay-lead-0814; enqueue is not reported as successful delivery."
}
}

Scope — what was controlled for

Every one of these returned recipient_unresolved with resolvedRecipient: null:

Control	Result
Recipient relay-lead-0814 (live pty, actively working)	recipient_unresolved
Recipient factory-lead (live pty)	recipient_unresolved
Recipient marketing-lead (live pty)	recipient_unresolved
Recipient = the sending identity itself	recipient_unresolved
--mode wait (default)	recipient_unresolved
--mode steer	recipient_unresolved
Agent token only	recipient_unresolved
--workspace-key passed explicitly	recipient_unresolved

So it is not recipient-specific, not the wait-mode idle-boundary queueing, and not a missing workspace key.

Contrast: agent-relay message post <channel> returns delivery: null — it makes no delivery claim — and the posted message is readable back out of the channel. Channel posting works. DM delivery does not.

Negative control — the message genuinely never arrives

A DM was sent to relay-lead-0814 containing a unique marker, CHIEF-STEER-PROBE-7731, in --mode steer.

• relay-lead-0814 was demonstrably alive and working throughout: its session transcript had 3,839 entries with writes continuing during and after the send.
• A poll loop grepped its transcript for the marker. Zero occurrences, four minutes after the send.
• Independently, grep for every distinctive phrase from two earlier real briefs sent the same way — the sender name chief-dmcheck, FROM CHIEF, 12:06:00.842, durable_object_overloaded, Skip.app — returned 0 for all.

The recipient was alive and the messages were never delivered.

Why this is worse than the outage it replaced

relay#1518 fixed a hard failure where dm send threw Workspace key required (rk_live_...), by making recipient resolution degrade rather than throw. The degrade path is honest — delivery.note says exactly what happened — but it is easy to miss, and the caller now gets HTTP success plus a real message id.

The prior behaviour failed in a way nobody could miss. The current behaviour fails in a way almost everybody will miss. A fix that converts a loud failure into a quiet one has not finished; the enrichment that could not fail gracefully is now failing gracefully into non-delivery.

What needs to happen

1. Root-cause why recipient resolution is unavailable.resolvedRecipient is null for live, registered, currently-running agents in the same workspace and on the same node as the sender. Resolution previously went through GET /v1/agents, which requires a workspace key; determine what it uses now and why it returns nothing even when a workspace key is supplied. Start from the relay#1518 change (75e969a96, "stop dm send from blocking on a workspace-only roster read") and relay#1468 (3267b1b19, "expose direct-message enqueue state").
2. Restore delivery. A DM to a live agent on the same node must be injected.
3. Make the failure loud again at the CLI layer.agent-relay message dm send must exit non-zero, or at minimum print a clearly visible warning, when delivery.status != delivered. Returning a messageId as the headline result of an undelivered message is the defect that hid this. Do not remove the delivery object — it is the only reason this was diagnosable. Make the CLI read it.
4. Regression test with a must-fire / must-not-fire pair. Must-fire: resolution unavailable ⇒ non-zero exit / visible failure. Must-not-fire: successful delivery to a live agent ⇒ exit 0 and no warning. A test that only asserts a messageId is returned would pass against the broken build and is not acceptable coverage here.
5. Check whether send_group and the MCP send_dm tool share the path, and whether they report or swallow the same state.

Definition of done

• A DM sent to a live agent on the same node is received by that agent, demonstrated with a unique marker found in the recipient's transcript.
• A DM whose recipient cannot be resolved fails visibly at the CLI.
• Both arms covered by tests.
• A note in the PR stating whether MCP send_dm and message dm send_group were affected, and what was done about them.

Notes for whoever picks this up

• Verify against the running binary, not the checkout — the deployed artifact and local trees have diverged repeatedly this week.
• Do not verify a fix by reading messageId. Verify it by finding a unique marker in the recipient's session transcript. That is the only check that distinguishes this bug from a fix.
• Related, and probably a consequence of this bug rather than a separate one: AgentWorkforce/relay issue filed alongside this one covering agent-identity recovery defects. If DM delivery is restored, re-test whether those reports were simply never received.

Fixes#1523