The Daemon Closes A Request

Symptom

A tool call or spoken announcement doesn’t complete — the connection or request appears to close before a response comes back — especially when multiple calls (often speech calls) are fired at close to the same time.

Why

This almost always shows up under one of two conditions: the daemon itself isn’t healthy, or multiple calls are contending for the same session’s serialized speech queue.

Autonomy fixed a real defect in this area (autonomy-r0r23): the speech queue slot used to be held for only an estimated speaking duration, and a client disconnecting mid-announcement could leave the next message racing the previous one, which looked like the daemon dropping or overlapping requests. The fix holds the slot for the actual audio lifetime and releases it from a detached task even if the original request future is dropped — so a disconnect no longer corrupts the next message. But firing several speech or tool calls in parallel against one session is still the wrong pattern: they’ll queue and block on each other rather than run concurrently, and if your client has its own timeout, an early call can look like it was “closed” when it was actually just still waiting its turn.

Fix

Always rule out daemon or environment unhealthiness first:

"/Applications/autonomy (a7y).app/Contents/Resources/bin/a7y-cli" doctor

(or a7y-cli doctor if it’s on your PATH).

If doctor passes, the daemon and permissions are fine — the problem is call pattern, not health. Retry the single call on its own:

a7y-cli tools call voiceover_transport_announce \
  --args '{"message":"Retrying this update.","agentId":"claude"}'

Avoid firing multiple speech or tool calls in parallel until you know the session queue and daemon health — await each response before sending the next one, especially for voiceover_transport_announce.

If doctor instead reports the daemon as not running or unreachable, check its status directly and start it:

a7y-cli daemon status
a7y-cli daemon start --dev

Verify

a7y-cli daemon status

Confirm it reports a running daemon with a PID matching what’s in the state file. Then retry the original call in isolation and confirm its response has no failed entry in deliveryEvidence (for speech calls) and returns normally.

If requests succeed individually but two agents are still stepping on each other’s speech, see Two agents talk over each other. If the daemon can’t be reached by the agent host at all, see MCP tools not visible.