handle chat

[esokullu]

Can WebBrain handle chats with real or virtual support agents now?

Short answer: The building blocks to interact with chat exist; however, there is no end-to-end "chat handling" feature specifically designed to autonomously manage a support chat (like GoDaddy's) over long periods. Doing this reliably is technically medium-to-hard.

First topic: What do we have, and what is missing?

Currently available:

• Reading chat history and the composer via the accessibility tree.
• Typing messages and clicking Send.
• The concept of messaging.target_kind: "active_conversation" in the planner.
• Specialized workflows on certain sites like Gmail, LinkedIn, and Douyin that anchor the recipient and verify the sent message.
• wait_for_stable for short waits.
• schedule_resume (line 525), which can resume the same conversation later during long external waits.

However, active_conversation alone is not a verified counterparty; the code explicitly notes this is merely planner intent (message-recipient-guard.js (line 73)). For GoDaddy, there is no adapter, no recipient anchoring, and no terminal proof that "the message was actually sent to this support representative."

Consequently, what is missing:

• An event-based chat state machine that tracks incoming support messages.
• Clear stages: "Waiting for transfer / Agent connected / We responded / Counterparty replied / Issue resolved".
• Ability to read only new messages after a resume.
• Idempotency / deduplication checks preventing the same message from being sent twice.
• Definitive verification of the outgoing message bubble and the correct conversation thread.
• Multi-hour waiting support and tab/session persistence.
• Safe stopping / pausing when OTP, PIN, payment, authentication, or a new user decision is required.

---

The ideal flow in this trace should roughly look like this:

1. Read the conversation once.
2. If the request hasn't been sent yet, send it once.
3. Verify the outgoing message in the chat history.
4. If waiting for a human agent, return via schedule_resume after e.g. 1–2 minutes instead of continuously calling wait_for_stable.
5. Upon resume, read the transcript delta and respond if necessary.
6. Do not report success without independently verifying all three: refund, auto-renewal status, and case number.

In short, it is feasible; but it is not as simple as "find a textarea, type, and send." Especially in real-world customer support scenarios, the long wait times, uncertain delivery, and risk of re-sending require a dedicated workflow.