Adding a real-time avatar should not turn into a decision to outsource the product itself. The better question is narrower: which layer is genuinely strategic for your team to own?
For many SaaS products, the enduring differentiation is the workflow, domain context, agent behavior, product data, and interface around the avatar. In that case, evaluating a dedicated avatar layer can be more sensible than making motion generation and rendering a new in-house platform. If animation behavior and rendering are themselves core product IP, building may be justified—but it brings an ongoing ownership commitment, not just a launch project.
Spatius is an avatar interaction layer. Its Motion Server receives approved avatar speech audio and returns motion data; AvatarKit renders the avatar locally in the client. Your application remains responsible for the intelligence and the product: ASR, LLM, TTS, context and retrieval, permissions, tools, workflows, decisioning, analytics, and handoff. Review the current Spatius Docs Map before making an architecture decision.
Start by separating the product from the avatar layer
The phrase “AI avatar” often groups together systems that should be assessed independently. A useful decision starts by drawing the boundary.
| Layer | Usually owned by your SaaS product | A real-time avatar layer can handle |
|---|---|---|
| Conversation | ASR, LLM, TTS, prompts, turn-taking, interruption rules | Uses the final approved avatar speech audio |
| Product intelligence | Context, retrieval, customer data, permissions, policy, tools, workflows, and business rules | Does not replace those systems |
| Avatar presentation | Product placement, UI controls, measurement, and fallback experience | Audio-to-motion processing and local avatar rendering, according to the chosen integration path |
With Spatius, that boundary is specific rather than abstract: the Motion Server converts avatar speech audio to motion data, and AvatarKit uses the returned motion data to render the avatar on the client. The avatar layer does not become your agent, agent orchestration, video-generation system, or source of truth for product data.
This framing changes the build-versus-buy conversation. You are not choosing between control and no control. You are choosing where control produces customer value, and where a documented integration boundary is more valuable than internal ownership.
When integrating is usually the stronger choice
Integration is often a good fit when the avatar is an experience layer around work your product already does well. That might be guided onboarding, a product walkthrough, a support flow, practice and simulation, or an in-product assistant.
In these situations, the questions worth prioritizing are:
- Can the avatar receive the speech produced by our existing application or agent?
- Can we retain ownership of customer context, permissions, tools, and workflow decisions?
- Does the integration path fit our client and backend architecture?
- Can our product team change the user journey without treating the avatar runtime as a separate platform project?
Choosing a specialist layer does not mean treating it as a black box. It means defining responsibilities deliberately: your application owns the conversation and product policy; the avatar layer owns the motion and rendering tasks it documents.
When building is the right strategic investment
Building is more defensible when the motion or rendering system is itself a durable part of what customers buy from you. Examples can include a uniquely proprietary presentation system, a required runtime model that a documented integration cannot provide, or an organization that already has a dedicated team ready to operate this capability.
Before committing, make the ownership explicit:
- Who owns the runtime roadmap after the first release?
- Who maintains client compatibility, regression testing, monitoring, and incident response?
- What quality bar must the motion and rendered avatar meet for the actual user journey?
- What new product requirements become your responsibility whenever your agent, speech pipeline, or client experience changes?
Building is not inherently more controlled if no team owns those answers over time.
Choose the integration path after the ownership decision
“Real time” is not one universal architecture. Pick an integration model after you know what you intend to own and where your speech audio is produced.
Direct Mode for a client-rendered avatar experience
In Direct Mode, your backend creates 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. The backend issues the token; it is not the runtime relay for that audio and motion path.
This can be relevant when the product already produces the speech the avatar should present and wants the avatar to live in the client experience. For other architectures, start with the docs map and evaluate the documented path that fits your application rather than choosing on the basis of a generic protocol label.
Compare the whole operating surface, not just a prototype
A prototype can demonstrate whether an avatar belongs in a user journey. It does not account for everything a team must own once that journey becomes a maintained production surface.
Use your actual product conditions to compare the options:
| Area | Questions to answer |
|---|---|
| Initial implementation | Who designs the client integration, authentication, state handling, and error behavior? |
| Product integration | How does the correct speech, product context, and user permission state reach the right system? |
| Quality assurance | Who tests interruptions, reconnects, client lifecycle changes, and fallbacks in your supported product flow? |
| Ongoing operations | Who owns compatibility work, monitoring, support investigation, and incident response? |
| Product iteration | How easily can scripts, UI controls, and avatar behavior change as your workflow evolves? |
| Commercial evaluation | What are the approved usage assumptions, internal engineering costs, procurement needs, and support expectations? |
Avoid using generic pricing, infrastructure, bandwidth, or performance claims as a substitute for this analysis. Those decisions should come from your approved plan and representative product testing.
Use a decision record, not a slogan
The following matrix is a way to guide an internal decision; it is not a promise that one option is always cheaper or simpler.
| Decision factor | Integrating an avatar layer is often a fit when… | Building is often a fit when… |
|---|---|---|
| Differentiation | Customer value mainly comes from your workflow, agent, or data. | Motion and rendering are core differentiated product IP. |
| Ownership | You want a documented boundary and to focus the team elsewhere. | You need to control the full runtime roadmap and implementation details. |
| Architecture | A documented path fits your current product model. | Critical product constraints cannot be met by an available integration path. |
| Operations | You want to limit the runtime surface area your team maintains directly. | A dedicated team is prepared to own the runtime long term. |
| Learning | You need to validate a focused user journey first. | You have validated the use case and know why custom implementation is necessary. |
Pilot one job before making a platform decision
Start with a journey where the avatar has a clear role: help a trial user complete an important setup step, present a contextual product walkthrough, or support a controlled practice scenario. Define what the user should accomplish and the metric your application will measure.
Before expanding, write down:
- which system owns each step of the interaction;
- which integration path and client lifecycle you are evaluating;
- how the product handles authentication, user controls, interruptions, errors, and handoff;
- how product content, context, permissions, and tools are governed; and
- what evidence would justify extending the experience to another workflow.
That record makes a later build-versus-buy decision more concrete. It also protects against a common mistake: treating the visual layer as the product while leaving the customer-critical workflow undefined.
FAQ
Does integrating an avatar layer replace our AI agent?
No. Your application remains responsible for ASR, LLM, TTS, context and retrieval, product data, permissions, tools, workflows, decisioning, analytics, and handoff. Spatius provides the documented audio-to-motion and local rendering layer.
Does Spatius return a finished video?
No. Motion Server receives avatar speech audio and returns motion data. AvatarKit renders the avatar locally in the client. See the Spatius Docs Map for the current product boundary.
Does Direct Mode move our runtime logic into the Spatius backend?
No. In Direct Mode, your backend creates a Session Token. AvatarKit communicates with Motion Server over WebSocket for the avatar audio and motion path, while your application continues to own its agent, product logic, and data responsibilities. See the Direct Mode overview.
Map the decision to one real product flow
The best next step is a technical conversation around one workflow your team already understands—not a generic scorecard. Map the speech path, client experience, data boundary, and responsibilities you want to retain.
Request a Demo to discuss how a real-time avatar layer could fit your SaaS product.