Orbit ships AI video avatar agents: you bind one of your existing AI conversation agents to a rendered talking-head avatar persona, and that persona either joins a live video room as a digital host, or renders a personalized video message from a script with merge tags. Renders are queued and tracked from queued to rendering to completed, and every completed clip carries a signed content credential so recipients and reviewers can verify that the asset is the one Orbit produced. The capability is part of the RTC-PaaS pillar and rides the same Video API surface the rooms, broadcast, and recording features already use.
This page explains what ships today, how a clip is produced end to end, and the questions teams ask before they put an avatar in front of customers.
What an avatar persona is in Orbit's terminology
An avatar persona is the tenant-managed binding between two things: a conversational agent (the dialog "brain" — the same agent stack Orbit's AIaaS pillar uses for voice and messaging) and a rendered-avatar provider persona reference (the replica or avatar id you hold at your chosen talking-head provider). The persona also carries the operator-facing label shown in pickers, an optional greeting it speaks on join, an optional locale hint for TTS, and an enabled flag so a persona can be retained without being dispatched. The registry is capped at 50 personas per tenant to keep the library bounded.
Orbit stores only a non-secret provider persona reference — the avatar id at your provider — never provider credentials. Provisioning the provider account and minting the bot-participant token are the avatar-runtime's job when it consumes a join plan.
Two ways an avatar gets used: live rooms and queued renders
A persona binds to one of two motions, both backed by the same registry entry.
1. Join a live video room as a digital host
When a persona is dispatched into a live room, the avatar-runtime resolves the persona into a join plan — the recorded room name, the underlying conversational agent, the avatar provider + persona reference, and the opening greeting — and joins the room as a bot participant that renders the talking-head video driven by that agent's turns. The room itself is the same moderated, in-browser WebRTC room Orbit's video API already ships: the digital host appears in the participant list, moderation rules still apply, and the session's recording and summary land on the contact record with the other channels. This is the pattern for high-touch flows where a conversational presence is the point — onboarding walkthroughs, telehealth intake, premium support — when staffing a human host per call does not scale.
2. Queue an on-demand clip from a script and merge tags
The async counterpart is a render job: you post a request against the persona with a script template (up to 5000 characters) that may contain {{merge_tag}} tokens, plus an optional merge_fields map (up to 20 keys, each up to 64 characters) supplying the per-recipient values, and an optional locale override for TTS. The render request is persisted as a deterministic, pollable job that your provider integration or render runtime consumes — the same "no net-new infra" split as the live join plan, so Orbit never holds your provider credentials.
Once your runtime reports progress via the render-job status update, the job moves through queued → rendering → completed (or failed, with an error message preserved), and the resulting clip's output_url is a plain HTTPS link — selected on any surface the existing content pipeline already accepts a generic media URL: a campaign send, a 1:1 MMS or WhatsApp message.
Both modes bind the same persona id, so the avatar your customer met in the room and the clip that lands in their inbox share one visual persona and one dialog brain.
Signed content credential per clip
Every render that reaches completed is minted a content credential — a tamper-evident watermark plus a disclosure manifest, the same synthetic-media provenance guarantee Orbit already ships for cloned-voice audio. The credential is persisted on the render record and travels with the clip when its output_url is attached downstream.
Recipients or reviewers can confirm a given token's authenticity via the render surface's POST /verify endpoint. The token alone validates; if a caller also supplies the clip — either as base64 or as a SHA-256 digest — the verify response bind-checks it and reports a video_mismatch when a valid token has been re-stapled onto a different clip. The credential gives the persona's synthetic media a chain of provenance that audit and compliance review can inspect.
Where the capability lives in the platform
The avatar-agent capability is part of RTC-PaaS, the pillar that also ships video rooms, live broadcast, recording, co-browse, and session replay. The marketing pillar page at RTC-PaaS describes it alongside those sibling capabilities, and the underlying transport is the same Video API Orbit's embeddable room surface already binds to — including the same X-API-Key + video:read/video:write scopes the other video routes use.
- Persona registry:
GET/POST /api/v1/video/avatar-agents,PATCH/DELETE /api/v1/video/avatar-agents/:id— list, register, update, or remove personas. - Join plan:
GET /api/v1/video/avatar-agents/:id/join-plan?room=<name>— the dispatch descriptor the avatar-runtime consumes to enter a room. - Render jobs:
GET/POST /api/v1/video/avatar-video-renders,GET/PATCH/DELETE /api/v1/video/avatar-video-renders/:id,POST /api/v1/video/avatar-video-renders/verify— script a render, list, poll, report status, remove, and verify a content credential.
Tiered access matches the other video surfaces: reads require the video:read scope and writes layer video:write, with mutations limited to the owner, admin, or developer role.
Use cases
Concierge video recaps
A property-management company, an insurance agent, and a private-banking desk all have the same pattern: a high-touch customer records a live session and wants a short recap they can forward to family members or a signing committee. The concierge avatar is dispatched into a video room, reads the intake or policy summary, and follows the scripted closing line; once the job completes, the recap clip's link is posted back to the customer's WhatsApp thread, with the signed credential attached so the recipient can verify what they are opening.
Personalized campaign clips
An e-commerce team personalizes its back-in-stock or cart-recovery video at scale: the persona template is written once ("Hi {{first_name}}, your {{product_name}} is back on the shelf"), the campaign's contact list supplies the merge-field map per recipient, and the render runtime consumes the queue in bulk. The finished clip attaches to the campaign send the same way a static image or product card would — the render queue just happens to drop a video URL instead of a hosted image.
Frequently asked questions
What is an AI video avatar agent?
An AI video avatar agent binds one of your conversational agents — the dialog brain — to a rendered talking-head persona at a provider such as Tavus, HeyGen, or D-ID. The persona either joins a live video room as a digital host, or renders a personalized video clip asynchronously from a script plus merge tags. Orbit stores only your non-secret persona reference at the provider; the provider account and credentials remain on your own integration.
Does Orbit call the render provider's API directly?
No. Orbit persists the render request as a pollable job and never holds your provider credentials — it stores only your avatar reference id. Your provider integration or render runtime consumes the job and reports progress back, the same split the live-room join plan uses. That keeps every provider-side secret out of the tenant's stored configuration.
How do I know the clip my recipient opens is the one Orbit produced?
Each completed render carries a signed content credential — a tamper-evident watermark plus disclosure manifest, the same synthetic-media provenance Orbit already ships for cloned voice audio. Your recipient (or an auditor) posts the token to the /api/v1/video/avatar-video-renders/verify endpoint, and optionally supplies the clip itself, so a re-stapled token reports a video mismatch instead of a false pass.
Can the persona be shared between live rooms and queued renders?
Yes, and that is the point. A single persona entry binds one conversational agent and one provider avatar, and that same id is referenced by both the room join plan and the render-job surface. The avatar your customer met in the room and the clip that lands in their inbox share one visual persona and one dialog brain.
What does the tenant control?
Your own provider persona reference, the script template, the merge-field values, the locale override, and whether the persona is enabled or retained. The provider account, the rendering infrastructure, and the room's media edge remain your integration to operate; Orbit stores none of that.
Product framing — what ships, today
This is not a roadmap promise. The persona registry, the join-plan resolver, the render job queue with status reporting, the verify endpoint, and the content-credential mint are all declared under /api/v1/video/avatar-agents and /api/v1/video/avatar-video-renders today, with TTS locale overrides, the 20-key merge-field binding, and the 5000-character template limit the shipped surface enforces. The render pipeline is framed as queue → completed because that is the honest model: Orbit queues and tracks the job, and your chosen avatar provider performs the actual talking-head render.
Published 29 August 2026.