Multi AI Chat example is not working when deployed

[nechmads]

If you run the Multi AI Chat example (https://github.com/cloudflare/agents/tree/main/examples/multi-ai-chat) locally, everything works just fine.

But if you deploy it and try to run it, the agent never receives messages and of course never replies.

I found this out, as we tried to mimic the same thing into our app and it worked perfectly locally but was totally broken after we deployed it. I decided to try and run the example code and saw it behaves exactly the same.

Does anyone know why? Tried to debug it with Claude for hours, but neither of us could make it work.

[muhammadmobi]

This was very likely a bug in the agents package itself, not in your code. It was fixed in agents@0.12.1.

In the version you were on, sub-agent (facet) chats connect through the parent's URL (/agents/inbox/demo-user/sub/chat/{chatId}), and the browser WebSocket was handed over to the child Chat facet. That works in wrangler dev. On deployed Workers, though, a Durable Object can't do native I/O on a WebSocket owned by a different DO. So the chat socket connected, but messages never reached the agent. That's exactly the "works locally, silent when deployed" behavior you saw.

#1443 (merged the same day you posted) fixed it by keeping the WebSocket owned by the parent agent and forwarding connect/message/close events to the child facet over RPC. It was verified by deploying this multi-ai-chat example. A related startup fix, #1425, shipped in 0.12.0 (background in #1410).

To fix it:

npm i agents@latest @cloudflare/ai-chat@latest

Then redeploy. If it still fails, run npx wrangler tail while you send a message. An error like Cannot perform I/O on behalf of a different Durable Object would mean you're still on an older version somewhere, for example a stale lockfile.

Also worth knowing: the example's README now recommends one top-level Durable Object per chat for apps with many long-lived chats per user, instead of facets. See examples/next/routing. That may be a better fit for your app.

[yaohuangguan]

This turned out to be a real deployed-only bug rather than an application configuration issue.

The same problem was reproduced in #1437 and fixed in #1443. The root cause was sub-agent browser WebSockets crossing Durable Object/facet I/O ownership boundaries in deployed Workers. Local development didn’t expose the same failure mode.

The fix keeps the browser WebSocket owned by the parent Agent and forwards the child agent’s connect/message/close events over RPC instead. It also included a couple of resume/stream replay fixes discovered while testing the same flow.

So if anyone lands here with the same symptom, I’d first make sure you’re on a version of agents / @cloudflare/ai-chat containing #1443 and redeploy before debugging your own routing. The current multi-ai-chat example already uses the fixed path.