Guide
Agent events on the same WebSocket as chat
When humans and copilots share a room, debugging and handoffs are easier if tool_call, tool_result, and user messages share one ordered stream — not a side channel.
Pain from AI-at-work threads
- Operators ask: what did the agent do, in which order, relative to the user?
- Split transports (chat in one pipe, tools in another) make replay and support harder.
- Observability improves when the room timeline is the source of truth.
What FluxyChat streams on the room socket
- User messages with deliveryStatus and clientMessageId.
- tool_call, tool_result, tool_error, and agentRun events on the same timeline.
- Optional webhooks for downstream automation — still keyed to room + project.
- Console + D1 for history export when you need audit, not only live fan-out.
Demo narrative
In the operator console, open a room with an agent configured: mention the agent, watch tool events appear beside human messages, then inspect runs from the agents page. That is the workflow product teams describe when they want copilots inside SaaS, not a separate debug UI.
React hook
const { messages, invokeAgent, agentTyping } = useChat({
roomId,
client,
agentId: "agt_…",
});
// messages includes user posts and agent/tool events for your UI to renderProduction next step
FluxyChat packages the same stack: RoomDurableObject, D1 history, multi-tenant JWT, reconnect-aware SDK, and operator console. MIT self-host or hosted beta.
Topics: agent tool calls websocket · copilot realtime chat · ai agent observability · shared workspace chat
Canonical path: /guides/agent-events-same-websocket-stream