An AI avatar pilot is not a reason to rebuild your agent or redesign your product. It is a focused way to test whether a visual, spoken presenter improves one user moment—such as a difficult onboarding step, an in-product explanation, or a guided support workflow.
For a Spatius integration, keep the system boundary clear. Your application owns the intelligence and product decisions: ASR, LLM, TTS, knowledge, context, retrieval, permissions, data, tool calls, workflows, analytics, turn-taking, and handoff. Spatius turns avatar speech audio into motion data, and AvatarKit renders the avatar locally in the client. It does not return a finished video or take over your agent. The Spatius Developer Docs Map is the source of truth for the current product architecture.
Key takeaways
- Start with one high-friction product moment, not an avatar across every surface.
- Preserve the application and agent boundaries your team already operates.
- Choose an integration path that matches your runtime instead of treating one protocol as universal.
- Give pilot users clear controls to interrupt, leave, or choose another path.
- Decide what evidence you need before expanding beyond the first workflow.
Choose one product moment to test
The first question is not “Where can we put an avatar?” It is “Where could a spoken visual explanation make an existing product task easier to understand?” Start with a moment where users already need guidance and where your team can observe the next step they take.
For a B2B SaaS product, that might be a setup checkpoint, a complex feature explanation, a support flow with a known point of confusion, or a product-demo moment. The right pilot has a defined audience, an approved response scope, and a next product action that remains under the user’s control.
Avoid treating the first release as an “avatar everywhere” experiment. A small pilot gives product, engineering, and customer-facing teams one implementation to evaluate together. It also makes it easier to separate the value of the interaction from the novelty of the interface.
Define the conversation contract
Before implementation, write down what the avatar may present and what it may not do. The contract should include:
- The user moment and response types in scope.
- The knowledge sources, permissions, and tool calls your agent may use.
- The actions that always require user confirmation.
- The interruption, exit, fallback, and human-handoff paths.
An avatar can present an answer. Your application still determines whether that answer is permitted, accurate for the current context, and connected to the right workflow.
Keep the system boundary intact
Teams often blur “AI avatar” and “AI agent” into one category. They are different layers. An agent interprets input, retrieves information, applies business rules, and decides what happens next. An avatar makes the resulting speech visible and more human-facing.
In a Spatius implementation, your application or existing agent stack produces avatar speech audio. Motion Server transforms that audio into motion data. AvatarKit receives the motion data and renders the avatar locally in the client.
This division keeps product ownership clear during a pilot. Your team continues to decide what information the agent can access, what it can say, what it can do, and how the user moves through the product.
Choose the integration path that fits your runtime
Do not select an architecture because a transport label sounds appropriate in a comparison table. Start with the runtime you already have and the level of control your backend needs. The Spatius integration guide outlines the current documented paths.
Direct Mode for an existing speech-audio flow
Use Direct Mode when your application already has avatar speech audio from TTS, an agent framework, or another audio source and you want the client to handle avatar playback. Your backend signs a Session Token. AvatarKit in the client uses that token to connect to Motion Server over WebSocket, sends avatar speech audio, receives motion data, and renders the avatar locally.
Your backend remains the owner of the agent runtime. It continues to run ASR, LLM, TTS, retrieval, agent policy, and product workflows; the token endpoint does not replace that work.
Use other paths when backend ownership is necessary
If your current voice-agent runtime has a documented integration path, evaluate it in the context of your own system. Choose Backend Mode when your backend needs to own the audio pipeline and downstream delivery. This gives your team additional runtime responsibilities, including the delivery, recovery, and observability behavior you choose to operate.
Roll out the pilot as a product experience
The technical connection is only part of the pilot. Decide who can access it, what they see before it starts, and how they can leave or change the interaction. If you already use feature flags, an internal or opt-in cohort can make the first release easier to govern before broader rollout.
Test the whole path, not only avatar playback
Walk through the complete experience as a user would:
- A user starts the scoped product task.
- Your application evaluates context, permissions, and agent policy.
- Your speech layer produces permitted avatar speech audio.
- Motion Server converts the speech audio to motion data, and the client renders it locally.
- The user can interrupt, leave, choose another path, or complete the next product action.
Test recovery behavior in the same flow. Direct Mode includes an audio-only fallback if the Motion Server WebSocket fails to connect within 15 seconds. Treat that as one behavior to validate alongside your own product-level error handling, support, and recovery design. Refer to the Direct Mode documentation for current requirements.
Measure whether the pilot earns expansion
Do not promise an avatar will improve activation, support cost, or retention before your team has evidence from the selected workflow. Instead, decide what a useful result would look like for the audience and moment you chose.
Review signals such as:
- Whether eligible users start, complete, interrupt, or leave the interaction.
- Whether they reach the intended next product action.
- Explicit helpfulness feedback and qualitative support feedback.
- Recovery, exit, and handoff events that reveal friction.
- Whether your application logs give the team enough context to understand the experience.
Where appropriate, compare these signals with the normal experience for the same user moment. The goal is not a universal claim about avatars; it is a product decision about whether this interaction adds value in this context.
Frequently asked questions
Does a Spatius pilot replace my SaaS AI agent?
No. Your application or agent backend still owns ASR, LLM, TTS, knowledge, context, retrieval, permissions, data, tool calls, workflows, analytics, turn-taking, and handoff. Spatius converts avatar speech audio into motion data, and AvatarKit renders the avatar locally.
Does Spatius stream a finished avatar video to the client?
No. Motion Server returns motion data. AvatarKit renders the avatar locally in the client. See the Developer Docs Map for the product boundary.
Do I need a particular transport for an avatar pilot?
No. Direct Mode uses a client WebSocket connection to Motion Server. Choose other paths only when their runtime and transport responsibilities match the architecture you already operate.
When should we move from pilot to a broader release?
Move only after your team can explain the user moment, agent and data controls, technical recovery behavior, and the user evidence supporting expansion. Add the next workflow deliberately rather than assuming one successful demo applies everywhere.
Start with a pilot your team can learn from
The best first avatar deployment is narrow, governed, and measurable. It keeps the agent and product controls your team already owns while helping you evaluate one real interaction with real users.
If you are planning an AI avatar pilot and want to evaluate the integration path for your stack, Request a Demo.