Introduction

If you are adding a realtime video sales agent to a Vue 3 CRM dashboard, the hard part is not rendering a face. The hard part is keeping three streams in sync: the conversation state, the agent’s media pipeline, and your CRM UI. The agent needs to listen, think, speak, and update a visual presence without making the app feel laggy or brittle.

This post walks through the architecture for embedding a conversational video agent into an existing Vue 3 dashboard. By the end, you should know how to structure the media layer, how to wire agent events into your CRM state, how to keep secrets out of the browser, and where a purpose-built avatar API can remove a lot of glue code.

Start with the right mental model

A realtime sales agent is usually two systems talking to each other:

• Conversation plane: speech-to-text, LLM reasoning, tool calls, and text-to-speech.

• Media plane: microphone capture, audio transport, and the video avatar stream that lip-syncs to the spoken output.

In a browser dashboard, the media plane is usually WebRTC-based because you want low latency, jitter handling, and bidirectional audio/video delivery. The conversation plane may run in your backend, in a voice-agent framework, or in a managed service. The key is that the avatar should follow the agent’s audio timing, not the other way around. If the agent emits text tokens faster than the media can play them, the UI will feel desynced even if the transcript is technically correct.

For a CRM workflow, the practical event model looks like this:

1. The rep opens a lead record in the Vue dashboard.

2. The dashboard starts or joins a realtime session for that lead.

3. The agent greets the rep or customer, then listens for input.

4. Transcript, call state, and session metadata flow back into the CRM panel.

5. When the call ends, the session summary and artifacts are stored against the lead.

That split matters because it tells you what belongs in Vue state and what belongs in your backend. Vue should own UI state, optimistic interactions, and live session rendering. Your backend should own session creation, authentication, persistence, and any business logic you don’t want exposed in the browser.

Design the Vue 3 integration around session state, not widgets

It is tempting to treat the avatar as a standalone component. That works for a demo, but in a CRM it becomes brittle fast. A better approach is to model the session as a composable or store module, then render the avatar as one consumer of that state.

At minimum, you want these pieces in your Vue app:

• Session metadata: lead ID, agent ID, call status, start time.

• Transport state: connected, reconnecting, muted, network quality.

• Conversation state: transcript, partial transcript, speaking indicator.

• UI actions: start call, hang up, handoff to human, send note.

A composable keeps the call logic isolated from the dashboard layout:

import { ref, computed } from 'vue'

}

import { ref, computed } from 'vue'

}

import { ref, computed } from 'vue'

}

The important part is not the exact code; it is the boundary. The browser should never contain long-lived API keys, and the avatar session should be started with a short-lived credential or server-mediated connection. That keeps your dashboard safe even if a browser tab is inspected.

Wire CRM events into the agent lifecycle

In a sales workflow, the agent is not just answering questions. It is also a UI participant. You usually want it to react to CRM events like lead stage changes, meeting booking status, or a note from the rep.

For example, when a rep opens a lead page, you may want to seed the session with context:

const payload = {

})

const payload = {

})

const payload = {

})

That backend endpoint can return whatever your media layer needs to begin the session. The exact shape depends on the API you use, but the architecture should stay the same: the CRM sends context, the backend creates a session, and the frontend only receives the minimum needed to connect.

Once the session is live, keep a narrow set of event handlers:

• Transcript updates append to the lead timeline.

• Call state changes toggle the avatar UI and controls.

• Tool results update CRM fields, not just local component state.

• Disconnects trigger retries or a handoff flow.

Do not make the dashboard infer business state from media state. A disconnected avatar does not necessarily mean the opportunity is lost. It just means the transport broke, or the session ended.

Keep latency low and failure modes boring

Realtime video agents are sensitive to every extra hop. In practice, the biggest causes of a bad experience are:

• Starting the agent too late, after the rep has already begun speaking.

• Doing heavy backend work before the session is created.

• Running transcript ingestion on the UI thread.

• Exposing a token that can be reused outside the intended dashboard session.

A few implementation rules help a lot:

1. Prefetch session credentials when the lead page loads, not after the user clicks “Call.”

2. Separate call setup from media join so you can render loading and retry states cleanly.

3. Debounce CRM writes from transcript events to avoid spamming your own backend.

4. Use short-lived session tokens and server-side authorization tied to the current user and lead.

Also be explicit about what happens when the avatar stream drops. A good dashboard can fall back to audio-only, show a reconnecting state, or let the rep continue the conversation while the media layer recovers. Users will forgive a brief reconnect; they will not forgive a frozen face with no explanation.

Where Protoface fits in this architecture

This is the point where Protoface can remove a lot of custom media glue. If you already have a voice agent, the LiveKit Agents plugin can add a synchronized talking face to that agent with very little extra code. If you are managing sessions yourself, the REST API gives you a backend-controlled way to create and manage avatars and realtime sessions. And if you want to stay out of the media plumbing entirely, the iframe embed path keeps API keys out of the browser.

For a Vue CRM dashboard, the most common pattern is:

• Vue renders the lead workspace and call controls.

• Your backend creates the avatar or session with an API key.

• The browser receives only a session-specific connection payload.

• The avatar stream is mounted into a panel beside the lead record.

A REST call to create a session will look familiar if you have built any backend-mediated media flow before:

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

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

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

Exact fields and response shapes are documented in the API reference, but the integration pattern is stable: create server-side, connect client-side, and keep the browser limited to ephemeral session data. If you are implementing the backend in Python, the SDK is the cleanest place to centralize that logic; if you are already on LiveKit, the plugin is a straightforward way to attach the avatar to an agent pipeline.

A practical Vue 3 UI layout

In the CRM, the avatar should be a component of the workspace, not a modal. That means it needs to coexist with notes, history, deal stage, and action buttons without dominating the screen. A sane layout is a two-column grid: lead data on the left, agent panel on the right, with transcript and actions stacked under the avatar.

In Vue terms, that often means:

• a parent page component that owns the session lifecycle,

• a sidebar avatar component that only handles rendering and transport events,

• and a transcript component that subscribes to the same store.

This avoids prop drilling and keeps the avatar reusable. If you later want to use the same agent on a support screen, you can swap the lead context while preserving the session logic.

One thing to resist is over-coupling the avatar UI to the CRM schema. The agent should receive a normalized context object, not your entire opportunity model. The more you leak internal structure into the session contract, the more painful schema changes become.

Conclusion

Integrating a realtime video sales agent into a Vue 3 CRM dashboard is mostly an exercise in clean boundaries: browser versus backend, session state versus UI state, and media transport versus business logic. If you keep those layers separate, the implementation stays maintainable even as you add handoff flows, transcript storage, or more complex agent behavior.

For the avatar and session layer, start with the docs, pick the integration surface that matches your stack, and build the CRM around a narrow session contract. The public documentation at docs.protoface.com is the right place to verify request shapes and integration details. If you want examples to copy from, the quickstarts linked in the repo are a good next stop.