AWS Builder Center
Building an E-commerce AI Agent with AWS Serverless: Connecting the Agent to Your Webshop (5/7)

Building an E-commerce AI Agent with AWS Serverless: Connecting the Agent to Your Webshop (5/7)

Integrate an AI agent into an existing webshop using streaming, AG-UI, client-side tool execution, and a custom chat widget.

Series: Building an E-commerce AI Agent with AWS Serverless (7 articles)

  1. …
  2. 5
    Building an E-commerce AI Agent with AWS Serverless: Connecting the Agent to Your Webshop (5/7) This article

Connecting the agent to the shop

Tools are simple functions that an AI agent can call to perform specific tasks. Each tool has a name, a description, and a set of input parameters. The  How AI agents work  chapter in Part 1 explains how tool calls fit into the agent's workflow.
Tools are essential because an LLM cannot interact with our application on its own. It can generate text, but it cannot search our product catalogue, check stock availability, or add products to a shopping cart without tools.
The LLM decides which tool to use and provides the parameters. The agent executes the function, returns the result to the LLM, and continues until it can provide a final answer.
Tool descriptions are particularly important. The LLM relies on these descriptions to understand what each tool does, when to use it, and which parameters to provide. Poor descriptions can lead to incorrect tool selection or invalid parameters.
We should also keep the number of available tools reasonably small. Too many overlapping or similar tools can confuse the LLM, increase token usage, and lead to unnecessary or incorrect tool calls.
For our shopping assistant, tools can be used in several ways:
Searching for a product
Searches the catalogue for a request such as “light hiking shoes for rain” and returns product IDs, links and relevant facts. The agent uses those results to answer. This is agentic RAG: the LLM decides when to retrieve product information using a tool.
Shop FAQ skill
Loads the shop's delivery, payment and returns guidance when needed. A skill is reference material for the agent, rather than a function that changes the shop. Part 1 explains this approach in  FAQs as a skill .
Adding to the cart
Sends a real product ID and quantity to the browser. The widget calls the shop's existing cart function and reports whether it worked. The agent confirms success only after that result. Part 1's  Tools can be executed on a client  explains the tool-call flow, while Part 6's  Keeping webshop authentication separate  explains the integration and security advantages.
Get information about past orders
Lets a signed-in customer ask about past orders. This tool can also execute in the browser, using the webshop's existing authentication and API integration. The shop's backend still verifies that the customer is authorized to access the requested orders.
Suggest future actions
Offers buttons after an answer, such as “Show cheaper options” or “Add to cart.” A question button sends a new chat message; a cart button calls a client action with a product ID already returned by search. The widget receives these as an AG-UI  CUSTOM  event and runs an action only when the customer clicks.

Communication Between the Client and AI Agent

Our shopping assistant needs more than a simple request-response API. We want to stream answers as they are generated, show users what the agent is doing and its progress, display product recommendations, and execute certain tools directly in the browser. To achieve this, we need a way to transport information between the client and the agent, and a common protocol that defines what that information means.

HTTP versus WebSockets

There are two main ways to communicate with our agent:
  • HTTP: The browser sends a request, and the agent streams the response back over the same connection.
  • WebSockets: A persistent, bidirectional connection where both the browser and agent can send messages at any time. WebSockets are useful for applications that require continuous two-way communication, such as real-time voice conversations. However, they add connection management and complexity.
For our text-based shopping assistant, HTTP streaming is sufficient. The browser sends a question, and the agent streams back its answer and other events. When the browser needs to send another message or a tool result, it can make another HTTP request.

Plain text streaming

The simplest approach is to stream plain text over an HTTP response. Instead of waiting for the agent to finish, the browser receives text chunks as the LLM generates them and displays them immediately.
For example, the browser might receive in parts:
I found three
waterproof hiking shoes.
This works well for a simple chatbot, but it has an important limitation: we can only stream text. We also want to communicate what the agent is doing, show progress, transfer product information, and execute tools in the browser. Plain text streaming does not provide a structured way to distinguish between these different types of information.

Server-Sent Events (SSE)

Server-Sent Events (SSE) is a general-purpose standard for streaming events over HTTP. It is not specific to AI applications. SSE allows us to stream structured events rather than just plain text.
Each event can have a name and a data payload. For example:
event: text_delta
data: {"delta":"I found three "}

event: text_delta
data: {"delta":"waterproof hiking shoes."}

event: done
data: {}
SSE uses the  text/event-stream  content type. Each event is separated by a blank line, and the browser processes events as they arrive.
We can now distinguish different events, such as text updates, product-search progress, and tool calls. However, SSE only defines how events are transmitted, not what they mean. The names text_delta and done are conventions we invented. Another application could use completely different event names and data structures. We could define our own event protocol, but there is already a standard designed specifically for AI agents.

Agent–User Interaction Protocol (AG-UI)

AG-UI is an open protocol that standardizes communication between AI agents and user interfaces.
It defines event types for streaming text, agent execution, tool calls, state changes, errors, and other interactions. These events can be transported using SSE.
For example, instead of inventing our own text_delta event, AG-UI defines standard events:
{"type":"TEXT_MESSAGE_START","messageId":"m1","role":"assistant"}
{"type":"TEXT_MESSAGE_CONTENT","messageId":"m1","delta":"I found three "}
{"type":"TEXT_MESSAGE_CONTENT","messageId":"m1","delta":"waterproof hiking shoes."}
{"type":"TEXT_MESSAGE_END","messageId":"m1"}
AG-UI also defines events for tool calls. For example, when the agent wants to add a product to the cart:
{"type":"TOOL_CALL_START","toolCallId":"cart-1","toolCallName":"add_to_cart"}
{"type":"TOOL_CALL_ARGS","toolCallId":"cart-1","delta":"{\"productId\":\"4096\",\"quantity\":1}"}
{"type":"TOOL_CALL_END","toolCallId":"cart-1"}
The browser can receive these events, execute the requested tool, and return the result to the agent.
AG-UI also supports  CUSTOM  events for application-specific features. For example, we use a custom suggested_actions event to display buttons such as “Show cheaper options” or “Show similar products”.
The advantage of AG-UI is that we don't need to invent and maintain our own event protocol. It also allows us to use compatible frontend libraries and potentially replace our chat widget without redesigning the communication between the client and agent.
For our shopping assistant, we'll use HTTP streaming with SSE to transport AG-UI events.

Web widget

The web widget is the chat interface embedded in the webshop. It displays the conversation, streams replies from the agent, shows its progress, and handles interactive elements such as product cards, suggested actions, and browser-side tools.
We have two main options: use an existing chat UI library or build a custom widget.

Existing libraries

 CopilotKit  is one ready-made option. It provides chat panels and popups with native AG-UI support, streaming, tool activity, generative UI, and extensive customization. Its prebuilt web UI is React-based, which is convenient if the webshop already uses React. Otherwise, it introduces React and a relatively large set of frontend dependencies just for the chat widget.
Other alternatives include:
  • assistant-ui — an open-source React chat UI with an AG-UI adapter and highly customizable components.
  • Vercel AI SDK UI — provides chat hooks and UI building blocks, but uses its own streaming format, so an adapter is needed for our AG-UI backend.
  • NLUX — a lightweight chat UI with custom backend adapters, but without native AG-UI support.
  • @ag-ui/client — implements the AG-UI client protocol without providing a finished UI, making it a useful foundation for a custom widget.

Building a custom widget with an AI coding agent

For our shopping assistant, building a custom widget is probably the best option.
With modern AI coding agents, we can build a fully functional chat widget without spending days implementing everything from scratch. An AI coding agent can generate the interface, integrate AG-UI streaming, handle tool calls, and implement common chat functionality.
More importantly, we can adapt the widget to our exact needs, rather than working around the limitations of an existing library. We can match the webshop's design, create custom product cards, add suggested actions, and integrate directly with its shopping cart and customer account functionality.
A custom widget also gives us several advantages:
  • Full control over design and behavior, including shop-specific interactions.
  • Fewer dependencies, without introducing React into a webshop that doesn't already use it.
  • Easier integration with existing frontend functionality and authentication.
  • No dependency on a particular chat UI library or its release cycle.
The basic message list, input box, and AG-UI stream handling are relatively straightforward. However, we still need to pay attention to interrupted streams, retries, loading and error states, accessibility, restoring conversations, and preventing duplicate execution of browser actions.

Series: Building an E-commerce AI Agent with AWS Serverless (7 articles)

  1. …
  2. 5
    Building an E-commerce AI Agent with AWS Serverless: Connecting the Agent to Your Webshop (5/7) This article
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article