Testing a webchat agent

Most customer-facing support agents are reached through a chat widget, not a published API. The widget is a client; underneath it there is nearly always something we can talk to directly.

Find the transport

Open your own widget with the browser network panel recording, and send one message. You will see one of three things:

• A JSON POST per message - the simplest case. Copy the URL, the headers and the request body shape.
• A WebSocket connection - frames stream back as the agent types. Note how the last frame of a turn is distinguished from the others; that is the turnComplete signal.
• Server-sent events - a long-lived HTTP response streaming chunks. Not yet supported; use the underlying API if there is one.

Find the tool record

This is the part that decides whether testing is possible at all. The widget usually does not receive the tool record. It only needs the words. Look instead at the service behind it, where the record almost always exists because something has to log it.

If it genuinely does not exist, that is the finding. Ask your agent team to emit the calls alongside the reply. Until they do, no tool, ours or anyone's, can tell you whether your agent does what it says.

Point us at staging, not production

A run issues real refunds, cancels real subscriptions and changes real addresses if you let it. Agents marked Production are refused for exactly this reason. Use a staging deployment with seeded data that matches the scenario preconditions.

Prefer the socket

If the widget uses WebSocket, configure that rather than any REST fallback. Streaming tells us whether a tool call preceded or followed the sentence claiming it, over a request/response API that ordering is unknowable, and the checks that depend on it will say so rather than guess.