Introduction

Adding a shopping assistant to a Webflow site sounds simple until you try to make it actually useful: it needs to hear the user, understand product intent, call into your commerce logic, and respond with a face that feels present rather than bolted on. The hard part is not any one model. It is the wiring between speech-to-text (STT), the LLM, and the streaming layer that carries a low-latency, lip-synced avatar back to the browser.

This guide walks through that pipeline from a developer’s point of view. By the end, you should be able to reason about the moving pieces, choose the right integration pattern for a Webflow deployment, and avoid the usual failure modes around latency, turn-taking, and browser embed constraints.

The core architecture: STT, LLM, and avatar streaming

A shopping assistant is usually a realtime voice agent with a visual front end. The user speaks in the browser, STT turns audio into text, the LLM decides what to say or what tool to call, and a TTS or audio layer produces the spoken reply. The avatar layer sits alongside that pipeline and consumes the same conversational turn so it can stream a synchronized talking face.

The important detail is that the avatar should not be treated as a separate “video generator” bolted onto the end. It needs to stay aligned with the conversational state:

• Input path: microphone audio → STT → transcript

• Reasoning path: transcript + context + tools → LLM

• Output path: LLM response → speech/audio synthesis → realtime avatar animation

For shopping use cases, the assistant usually needs more than free-form chat. It often needs to look up inventory, surface product details, compare variants, and respect store policies. That means your agent should have clear tool boundaries. A good pattern is to keep the LLM responsible for dialogue and intent extraction, while deterministic backend functions handle catalog search, pricing, shipping, and cart operations.

Latency matters. If the STT endpoint is slow, the user hears pauses before the agent even understands the utterance. If the LLM response time is unpredictable, the avatar will appear to “think” too long. If the video stream lags behind audio, lip sync becomes visibly wrong. In practice, you want short turn times, incremental streaming where possible, and a backend architecture that avoids unnecessary hops.

Designing the assistant around product intent

For a Webflow shopping assistant, the most useful behavior is usually not open-ended conversation. It is guided discovery:

• “Show me black running shoes under $150.”

• “What’s the difference between the medium and wide fit?”

• “Do you have this in stock in size 10?”

• “Can you add the blue one to my cart?”

That means your agent should extract structured intent early. Even if the model is doing the conversation, you generally want to normalize user requests into a small schema such as category, color, size, price ceiling, brand, and action. This gives you a stable backend contract and prevents the assistant from inventing product details.

A practical flow looks like this:

1. User speaks into the Webflow embed.

2. STT converts speech to text.

3. The LLM classifies the request and optionally calls a product-search or cart tool.

4. The agent formulates a response based on real store data.

5. The avatar streams the response with synchronized mouth movement.

The main implementation choice is where the realtime session lives. For a site like Webflow, you usually do not want to put your API key in the browser and you do not want to stitch together your own media backend unless you need to. The simplest safe model is a managed embed or a server-side session creation flow that keeps secrets off the client.

Wiring the voice agent to a realtime avatar

If your shopping assistant is already implemented as a voice agent, the avatar should attach to the same session rather than creating a second conversational channel. That keeps turn-taking, interruption handling, and transcript state consistent. The avatar layer is effectively a synchronized presentation surface for the agent.

In systems built on LiveKit Agents, this tends to be a plugin-style integration: the agent keeps doing STT, LLM, and audio generation, while the avatar plugin adds the video face. The benefit is that you do not have to redesign the agent; you only add the streaming visual layer.

Illustrative Python setup:

from livekit.agents import Agent

agent.attach_avatar(avatar)

from livekit.agents import Agent

agent.attach_avatar(avatar)

from livekit.agents import Agent

agent.attach_avatar(avatar)

The exact configuration names depend on the SDK or plugin version, but the integration pattern is stable: the voice agent owns the conversation, and the avatar is bound to that conversation state. In a shopping assistant, that matters because interruptions are common. Users change their minds mid-sentence, ask follow-up questions, or switch from “compare items” to “buy this one” without warning.

Two practical gotchas:

• Don’t let the avatar drive the transcript. The model’s conversational state should remain authoritative. The face is output, not logic.

• Keep tool calls deterministic. The agent can phrase results naturally, but price, stock, and variant data should come from your backend, not from the model’s memory.

Webflow-specific deployment choices

Webflow changes the ergonomics a bit. The frontend is easy to embed, but you still need a secure way to create sessions, authorize access, and avoid exposing sensitive keys. For a realtime shopping assistant, the safest default is to terminate privileged work on your backend and let the browser consume only an embeddable session.

That split matters for a few reasons:

• Security: the browser should never hold a long-lived secret key.

• Control: you may want to rate-limit usage, scope the assistant to a specific page, or apply custom instructions per embed.

• Operability: session creation, logging, and quota enforcement are easier to observe server-side.

If you are building a shopping assistant that should live inside a Webflow page with minimal backend work, an iframe-based embed is often the cleanest option. If you already have a custom app backend and want full control over session lifecycle, a server-driven API flow is more appropriate. In both cases, the important constraint is the same: the browser should only talk to a scoped, realtime session, not to your core API credentials.

Using Protoface in the flow

Protoface fits at the avatar layer, where the agent’s spoken output becomes a lip-synced face in the browser. For developers already running a voice agent, the shortest path is usually to attach the avatar to the existing session rather than rebuild the agent stack. If you want to wire this up through Python, the SDK and docs are the right place to start: docs.protoface.com and the Python SDK repo are the most relevant references.

A minimal server-side session creation flow might look like this:

import requests

session = resp.json()

import requests

session = resp.json()

import requests

session = resp.json()

That is intentionally schematic. The point is the shape of the integration: create a session server-side, return only the minimal session data needed by the client, and keep the API key in your backend. If you prefer a plugin approach inside LiveKit Agents, the plugin repo is the better starting point: GitHub organization and the Protoface plugin and examples there show how to attach the avatar to an existing agent pipeline.

Implementation details that matter in production

Most production issues come from the edges, not the “hello world” path. A few things to plan for:

• Turn handling: users interrupt. Your agent should support barge-in without leaving the avatar speaking stale text.

• Fallback behavior: if the avatar stream drops, the shopping assistant should still function as a voice agent.

• Response length: concise replies keep the visual experience snappy. Use short confirmations and progressive disclosure.

• Tool grounding: for anything that affects inventory, price, shipping, or checkout, return real data from your backend.

• Policy boundaries: define what the assistant can and cannot do before it talks to customers.

From a UX standpoint, the avatar should reinforce trust, not distract from the shopping task. In retail flows, the best assistants behave a bit like a helpful associate: quick acknowledgment, specific answers, and no theatrical pauses. If the model is unsure, it should ask a clarifying question or hand off, not improvise.

For teams already using Pipecat or LiveKit, the same architectural guidance applies. The avatar integration is a presentation concern; the agent architecture still needs clean STT, model routing, and tool boundaries. If your stack already standardizes on Pipecat, the Protoface integration guide in the docs is the place to map that into your existing server pipeline.

Conclusion

A Webflow shopping assistant works well when you separate concerns: STT handles speech recognition, the LLM handles language and orchestration, tools handle commerce logic, and the avatar layer renders the conversation as a realtime face. The implementation details vary by stack, but the design rules are stable: keep secrets server-side, ground product answers in real data, and keep latency low enough that the experience feels continuous.

If you are building this now, start with a narrow shopping flow and a small tool surface, then add the avatar once the conversation is stable. The docs at docs.protoface.com cover the API, SDKs, and embed options in more detail, and the quickstarts linked from the repo are useful if you want to adapt an existing agent rather than start from scratch.