Introduction

If you are building a voice agent, sales assistant, support bot, or game NPC, you eventually run into the same question: should the user watch a pre-recorded onboarding video, or should they interact with a realtime avatar that speaks and reacts as the conversation unfolds?

The difference is not cosmetic. A static video is a fixed asset: it can explain, orient, and reassure, but it cannot observe state, respond to latency, or adapt its delivery. A realtime avatar is part of the runtime: it is tied to the agent’s turn-taking, audio stream, and session state, so it can lip-sync to live speech and stay synchronized with the conversation.

By the end of this post, you should be able to reason about the architectural differences, understand the integration trade-offs, and choose the right surface for your product: a video asset, a streaming avatar, or both.

Static onboarding video: predictable, cheap, and completely non-interactive

A static onboarding video is usually the simplest possible experience: render a sequence of frames, play audio, and optionally attach captions or controls. The content is pre-authored, the timeline is fixed, and the player does not need to coordinate with a live model or voice stack.

That makes it useful when the task is one-way communication:

• Explaining how to use a feature.

• Giving a product tour.

• Setting expectations before a call or demo.

• Providing compliance or training material that must be identical for every user.

The technical properties are straightforward:

• No turn-taking: the video does not wait for the user.

• No runtime inference: once rendered, the content is fixed.

• No session state: there is nothing to keep synchronized besides playback position.

• No latency sensitivity: buffering matters, but conversational latency does not.

The main advantages are simplicity and determinism. You can cache it aggressively, serve it from a CDN, and avoid any backend dependency beyond video hosting. The main limitation is also obvious: the user cannot ask follow-up questions, interrupt, or get a custom response.

Realtime AI avatar experience: a synchronized runtime, not a media file

A realtime avatar is different in kind. It is not a pre-rendered clip; it is a live session that takes text or speech input, produces response text or audio, and renders a face that is synchronized with that output. In practice, this means the avatar is coupled to the same event loop as your agent.

For developers, the important detail is that the avatar is usually not “playing a video” in the traditional sense. Instead, the system emits a stream of frames or a live video track that is driven by the agent’s response timing. If the agent pauses, the face pauses. If the agent starts speaking, the avatar mouth movement, facial motion, and audio alignment need to stay consistent with the current turn.

This introduces a few systems concerns that static onboarding never has:

• Turn coordination: when does the avatar start and stop speaking?

• Latency management: how long between user input and visible response?

• State propagation: what context is available to the avatar during the session?

• Transport: how do audio and video get from the runtime to the browser with low delay?

What actually changes in the stack

If you are used to shipping static media, the biggest shift is that realtime avatars behave more like a service endpoint than a file asset. The browser or client does not just fetch a URL and render it; it participates in a session.

That session typically has a few stages:

1. The app creates or authorizes a session.

2. The user’s audio or text is routed into the agent.

3. The agent generates the response.

4. The avatar renders synchronized visual speech for that response.

5. The client receives live media with enough timing fidelity to feel conversational.

Because the experience is live, quality depends on the whole chain, not just the avatar renderer. If your voice model is slow, the avatar will feel slow. If your transport is jittery, lip sync will drift. If session state is inconsistent, the avatar can speak with the wrong instructions or voice.

Choosing between the two: the practical decision tree

In most product flows, the choice is not “video or avatar” in the abstract. It is whether the interaction needs to be deterministic or adaptive.

Use a static onboarding video when:

• The message is identical for everyone.

• There is no need for back-and-forth.

• You want the lowest operational complexity.

• You want something that degrades gracefully with simple hosting.

Use a realtime avatar when:

• The user needs to ask questions or interrupt.

• The face needs to stay in sync with a live voice agent.

• You want an interactive web experience, not just a video.

• You care about the social layer of the conversation: eye contact, speaking rhythm, and immediacy.

There is also a hybrid pattern that works well in practice: start with a short static intro, then hand off into a realtime session when the user is ready to engage. That gets you the clarity of a scripted opener without giving up interactivity.

Implementation details that matter in production

Realtime avatar systems are easy to underestimate because the API surface looks small. The hard parts are usually around auth, session lifecycle, and keeping media aligned with agent state.

Three things are worth getting right early:

1. Keep credentials off the client unless the surface is explicitly designed for it. API keys belong server-side. If you need a browser embed, use an embed flow that is designed to avoid exposing secrets in the page.

2. Treat sessions as ephemeral. A session should be created, used, and torn down cleanly. Don’t assume the avatar is a static resource that can be reused forever; the runtime state matters.

3. Budget for latency. If your agent stack involves STT, LLM, and TTS, the avatar inherits those delays. The visual side cannot hide a slow backend.

A minimal REST call to create an avatar or session usually looks like this in shape, even though the exact fields depend on the endpoint documented in the API reference:

curl -X POST https://api.protoface.com/<endpoint> \
}'

curl -X POST https://api.protoface.com/<endpoint> \
}'

curl -X POST https://api.protoface.com/<endpoint> \
}'

And if you are wiring it into a Python application, the SDK path is usually the fastest way to manage avatars and sessions without hand-rolling HTTP for every operation:

from protoface import Client

print(session)

from protoface import Client

print(session)

from protoface import Client

print(session)

That snippet is intentionally generic; check the docs for the exact object names and request fields.

Where Protoface fits: putting a face on a live voice agent

This is the part where a realtime avatar platform earns its keep. If you already have a voice agent, you do not want to rebuild the entire media pipeline just to add a synchronized face. The common pattern is to plug the avatar renderer into the agent runtime.

For LiveKit-based agents, the livekit-plugins-protoface plugin lets you drop a Protoface avatar into the agent so the spoken output is mirrored by a live, lip-synced video face. The useful mental model is: your agent still owns the conversation logic, and the avatar becomes the visual endpoint for that same turn. The integration is documented in the plugin repo and the quickstart examples linked from GitHub.

If you are building in Python, the SDK and REST API are the cleanest way to manage avatars, sessions, and keys from backend code. If you need to expose the experience on a website without shipping secrets to the browser, the customer-managed iframe embed is the safest surface: the parent origin can be allowlisted, per-embed voice and instructions can be configured, and rate limits can be applied by IP and duration. That is materially different from dropping a generic video player on a page.

In other words, this is not “video hosting with a new skin.” It is an API-driven media runtime with a security model and session lifecycle.

Common gotchas

A few implementation mistakes show up repeatedly:

• Assuming lip sync is only a rendering problem. It is also a timing problem across TTS, transport, and session orchestration.

• Overloading the avatar with too much script. If the agent response is long and verbose, the visual experience will feel sluggish. Keep responses tight where possible.

• Mixing static and realtime semantics. A prerecorded intro should not pretend to be interactive; users notice when their input has no effect.

• Ignoring browser security boundaries. If you embed in the browser, prefer a mechanism that does not expose long-lived API keys.

For teams that want to get to production quickly, the dashboard is useful for session inspection, avatar management, API keys, usage, and in-browser testing before you wire everything into your application.

Conclusion

The difference between a static onboarding video and a realtime AI avatar experience is the difference between content and computation. A static video is fixed, cheap to distribute, and ideal for one-way communication. A realtime avatar is a live session component that needs state, synchronization, and careful latency management, but it can actually converse.

If you are adding a face to a voice agent, embedding an interactive support assistant, or building a conversational web experience, start from the runtime model first: how sessions are created, how audio is transported, and how the avatar stays in sync. From there, the implementation surface becomes much clearer.

For the API shape, SDK usage, plugin setup, and embed options, start with the docs at docs.protoface.com. If you want a practical starting point, the quickstarts linked from the GitHub repository are the fastest way to see the whole flow end to end.