Help Center

Menu

Implement an agent

Implement an agent

An agent is available to visitors through a website or application.

The DXP Console configuration provides the agent and its answers; your website implementation provides the chat interface and the connection to the agent.

Do not publish an agent that has not been tested with the content and audience it is intended to serve.

Generated answers can be incomplete or incorrect when the underlying content is missing, conflicting, or out of date.

Implementation requirements

Before implementation, confirm that:

  • the agent is enabled;
  • the agent has a meaningful Default Response;
  • the required Content Intelligence topics are connected and monitored;
  • representative in-scope and out-of-scope questions have passed testing;
  • the website domain is registered with your DXP Organization; and
  • the implementation does not expose DXP Organization credentials or other secrets.

Contact your Squiz account team for the DXP Organization, region, agent identifier, and domain configuration required for your implementation.

Front-end implementation

Your site or application needs to:

  1. Open a WebSocket connection to the conversational search service for the configured agent.
  2. Send visitor questions as chat messages.
  3. Display answer text as it is received and show the final sources and metadata when available.
  4. Keep the conversation identifier for follow-up questions in the same conversation.
  5. Handle completion and error messages so visitors can submit another question.
  6. Provide a way to start a new conversation.

For the WebSocket connection contract, message types, streaming behavior, and client example, see Implement WebSocket. The connection contract and deployment approach can vary by the website platform and delivery model; do not copy connection values from another DXP Organization or site.

Streaming responses

The WebSocket implementation streams answer text in small updates before the final response metadata arrives. A client should append each text update to the current answer and then use the final response to render sources and metadata.

A client must also support responses where no streaming updates are sent and the complete answer is included in the final response. Do not display an empty answer just because the final response’s answer field is empty after streamed text has already been received.

Conversation state

A connection represents a conversation session. Keep the conversation identifier returned by the service when sending follow-up questions. If the connection closes, the session history may not be available after reconnecting; start a new conversation and make that state change clear in the interface.

Errors and unavailable answers

If the service returns an error, clear any partial answer and show a useful retry message. An answer that cannot be generated should use the agent’s Default Response. Do not display raw service errors, DXP Organization identifiers, session identifiers, or internal diagnostic information to visitors.

Release checklist

Use this checklist to confirm that the implementation is ready for release:

  1. Complete the front-end implementation in a test or staging environment.
  2. Check that the browser connects using the registered website domain.
  3. Test in-scope, out-of-scope, follow-up, and unavailable-answer scenarios.
  4. Confirm that source links, loading states, errors, and the new-conversation action work as expected.
  5. Deploy the implementation according to your website platform’s release process.
  6. Monitor the first live conversations and address unexpected answers promptly.