Introduction

Most travel concierge products start as a chat box and end up feeling like a ticket form. The gap is not just UX polish; it’s the mismatch between a text-only interface and the actual job. Trip planning is conversational, iterative, and often time-sensitive. A user asks about dates, constraints, budget, baggage, loyalty status, and alternatives, then expects the system to remember context and respond quickly. Adding a live voice agent helps, but a voice-only agent can still feel impersonal. A synchronized avatar gives the interaction a face, which makes the exchange easier to follow and closer to a real concierge experience.

In this post, I’ll walk through how to build a Webflow-embedded travel concierge with streaming voice and a realtime avatar. The goal is not a toy demo. By the end, you should understand the architecture, the media flow, the latency constraints, and the implementation choices that matter when you put a conversational agent in front of real users.

What the system actually needs to do

A travel concierge is a realtime application, not a standard request/response app. The user speaks, the agent listens, the agent reasons or calls tools, then the agent responds with audio while the avatar’s face tracks the generated speech. In practice, that means you need three synchronized streams:

• Audio in: microphone capture from the browser.

• LLM / agent loop: speech-to-text, reasoning, tool calls, response generation.

• Audio out + avatar video: low-latency streamed speech and a lip-synced face.

The core technical constraint is latency. If the avatar lags behind the voice, the interaction feels broken. If the voice agent hesitates too long, users stop talking naturally and the whole experience degrades. In practice, you want to keep the round trip tight enough that the turn-taking feels conversational. That means streaming everywhere you can, avoiding unnecessary buffering, and keeping the avatar tightly coupled to the agent output rather than trying to “render” a video after the fact.

Designing the browser experience in Webflow

Webflow is a good fit for the front end because the embedding surface is simple: you can drop in an iframe or a small script snippet without turning the whole site into a custom web app. For a concierge, the embedded surface should behave like a focused widget rather than a full-page product. Keep the layout small and predictable, and let the conversation own the interaction.

Two implementation details matter immediately:

1. Audio permissions and autoplay: browsers will not reliably autoplay audio without a user gesture. Make the first interaction a click or tap that explicitly starts the session.

2. Session lifecycle: the conversation should map to a realtime session, not a static page load. If the user navigates away or closes the widget, the session should end cleanly.

If you are building the concierge as an embedded component, the easiest model is to let the iframe own the realtime session and expose only the minimal integration points to the parent page: open/close, maybe some prefilled context like destination, dates, or trip type. That keeps your API keys and media plumbing out of the browser surface.

Voice-agent architecture: keep the agent loop and media loop separate

A clean mental model is to split the system into two layers:

• Agent layer: decides what to say, when to ask clarifying questions, and when to call tools like flight search or booking APIs.

• Media layer: handles realtime audio transport and avatar sync.

This separation matters because the agent layer can evolve independently. You may start with a simple prompt-driven assistant, then add retrieval over destination content, then plug in booking tools or inventory search. The media layer should not care whether the response came from an LLM, a retrieval system, or a rules engine. It just needs a streaming response that can be rendered as speech and synchronized video.

For travel, the agent usually benefits from a small set of structured tools:

• searching flights or hotels

• checking itinerary constraints

• updating a session profile with preferences

• escalating to a human when the user asks for changes the model should not guess at

Keep tool results structured. Do not ask the model to infer booking availability from prose if you can return explicit fields. The avatar is just the presentation layer; correctness still comes from the underlying agent and data sources.

Streaming voice and lip sync: the failure modes to watch

Realtime avatars expose a few common failure modes that are easy to miss in local testing:

• Audio-video drift: the avatar mouth movements must track the spoken output, not the text token stream. If your TTS provider changes pace or pauses unpredictably, the avatar pipeline needs to stay aligned with the actual audio.

• Turn-taking collisions: if the user interrupts the agent, you need a clear policy for barge-in. Stop speech, stop animation, and reset the session state in a controlled way.

• Long tool latency: if flight search takes several seconds, the assistant should acknowledge the request quickly and then continue once the result arrives. Dead air is worse than an explicit “one moment.”

For a concierge, I recommend a response style that is short, confirmatory, and operational. For example: “I’m checking flights to Tokyo for your dates. I’ll compare nonstop options and anything under your budget.” That gives the user feedback immediately while preserving room for tool execution.

You also want to treat the avatar as stateful UI. When the agent is listening, it should look like it is listening. When it is speaking, the mouth should animate. When the agent is thinking or waiting on tools, the face should still feel alive but not actively speaking. Those are small details, but they reduce the uncanny feel of a talking head pinned to a backend.

Embedding the concierge in Webflow without exposing secrets

If you want the simplest deployment path, customer-managed iframe embeds are the practical option. They let you add an interactive avatar to a site with no backend code and no API key in the browser. That is a big deal for Webflow, because many teams want to ship a polished front end without standing up a separate app server just to broker realtime sessions.

The security model is straightforward: the embed can be restricted by parent origin allowlist, and the session can be scoped with per-embed voice and custom instructions. Rate limits per IP and duration help prevent abuse. From a developer standpoint, that means you can set up a concierge for a campaign page, a destination guide, or a customer portal without turning the page into an API surface.

A typical flow looks like this:

1. Configure the avatar and session behavior in your dashboard.

2. Embed the iframe on the Webflow page.

3. Pass minimal context from the page, such as destination or campaign metadata.

4. Let the iframe handle mic access, realtime transport, and avatar rendering.

That approach is especially useful when the concierge is more of a productized experience than a deeply customized app. If you need tighter integration with your own agent backend, use the API directly instead.

Programmatic control with the REST API and Python SDK

When you do need backend control, the REST API is the right layer for managing avatars and sessions. Authenticate with an API key, create a session, then hand the resulting session information to your client or embed flow. The exact payload fields are documented, but the shape is what you would expect from a realtime service: create, update, inspect, and tear down.

curl -X POST https://api.protoface.com/v1/sessions \
}'

curl -X POST https://api.protoface.com/v1/sessions \
}'

curl -X POST https://api.protoface.com/v1/sessions \
}'

For Python backends, the SDK is useful when you want to wire session creation into your own app logic. A travel app can, for example, create a session when a user opens the concierge, attach trip context, then log the session for analytics or follow-up.

from protoface import Client

print(session.id)

from protoface import Client

print(session.id)

from protoface import Client

print(session.id)

Keep in mind that the code above is illustrative. Use the documented fields and session lifecycle described in docs.protoface.com. The important architectural point is that session creation belongs on the server side, even if the actual media experience is delivered in the browser.

Where this fits in the stack

For a Webflow travel concierge, the practical split is:

• Webflow for the page and embed surface.

• Realtime agent backend for speech, tool calls, and session state.

• Streaming avatar layer for synchronized face animation.

Protoface fits at the avatar/session layer. If your voice agent is already running elsewhere, you can add a face without rewriting the agent. If you are starting from scratch, the LiveKit integration is the fastest path when your agent already lives in that ecosystem. The plugin is available in the LiveKit agents stack and is documented in the relevant GitHub repository, which is the best place to look for examples and integration patterns.

That said, do not overcomplicate the first version. A concierge that can greet a user, gather dates and preferences, summarize options, and hand off to booking or support is already useful. You do not need a fully autonomous travel agent to get value from a realtime avatar. You need a coherent conversational loop, low latency, and a deployment path that your team can operate.

Conclusion

If you are building a Webflow travel concierge, treat it as a realtime media system with an agent attached, not the other way around. Keep the browser integration simple, keep the agent state explicit, and keep the avatar synchronized to the actual spoken output. The hard problems are latency, turn-taking, and state management, not the visual skin.

For implementation details, session management, and the supported surfaces, start with the docs at docs.protoface.com. If you prefer to work from examples, use the quickstarts and plugin repositories as references, then adapt the session flow to your own concierge logic.