Introduction

When you add ElevenLabs Agents to a production system, logging is not just about debugging failed requests. It is how you understand latency, correlate TTS and LLM behavior, catch regressions in voice turn-taking, and prove whether a bad user experience came from your agent logic, your transport layer, or the avatar/video pipeline around it.

That becomes especially important once you attach a realtime avatar. A spoken turn can involve ASR, agent reasoning, TTS streaming, video frame generation, WebRTC transport, and browser playback. If you only look at console output, you will miss the shape of the problem. If you only look at backend traces, you may miss what the browser actually experienced. The useful answer is usually a combination: local console logs for immediate feedback, OpenTelemetry for distributed correlation, and backend traces for durable, queryable observability.

This post compares those three strategies in the context of an ElevenLabs-powered voice agent, then shows where Protoface fits when you want the avatar side of the stack to stay observable without exposing unnecessary complexity to the frontend.

Console logs: the fastest signal, and the easiest to overuse

Console logging is still the first thing most teams reach for, and for good reason. It is immediate, cheap, and easy to add around an agent lifecycle:

• session start and teardown

• tool invocation and tool results

• model inputs and outputs

• voice activity detection boundaries

• streaming milestones such as first token, first audio chunk, or turn completion

For local development, a well-structured log line often answers the question faster than any dashboard. The key is to make the logs structured and low-noise. Free-form strings are hard to search and nearly impossible to correlate across components.

import logging

import logging

import logging

There are two common mistakes here. First, logging payloads that are too large or sensitive. You generally do not want full prompts, raw transcripts, or API keys in logs. Second, relying on logs as your only source of truth. Console logs are ephemeral. They are not a trace system, and they do not naturally preserve parent-child relationships between spans of work.

Use console logs for:

• fast local debugging

• high-level lifecycle events

• human-readable breadcrumbs during rollout

Do not use them as a substitute for request correlation or latency analysis.

OpenTelemetry: the right abstraction for distributed realtime systems

OpenTelemetry (OTel) gives you a common way to represent a unit of work as a trace with spans, attributes, events, and status. For an ElevenLabs agent, that means you can track a single user turn across multiple services and libraries, even if the speech synthesis, tool execution, and avatar rendering happen in different processes.

The important idea is that a “turn” is not one function call. It is a distributed transaction-like flow:

1. a browser or telephony event arrives

2. the agent decides whether to respond or invoke a tool

3. TTS begins streaming audio

4. the avatar pipeline consumes the stream and emits video frames

5. the transport layer delivers audio and video to the client

With OTel, you can represent that flow as a parent span for the turn and child spans for each stage. Then you can ask useful questions like: Did latency spike in model reasoning, or did the avatar path fall behind after TTS started?

A minimal pattern looks like this:

from opentelemetry import trace

from opentelemetry import trace

from opentelemetry import trace

The value is not the library itself; it is the discipline around what you measure:

• Attributes should identify the session, tenant, model, voice, and quality tier.

• Spans should map to actual latency-bearing work, not every helper function.

• Events should mark boundaries such as “first token,” “first audio byte,” or “playback interrupted.”

For realtime systems, this matters because latency is cumulative. A 150 ms delay in agent reasoning, a 300 ms delay in TTS warmup, and a 120 ms delay in video frame generation can all be acceptable individually but still produce a noticeably sluggish avatar. OTel lets you see the stack, not just the symptom.

Backend traces: durable observability after the request is gone

Backend traces are what you query when the user already closed the tab and the issue is no longer reproducible on your laptop. They are where you answer questions like:

• Which sessions had repeated turn interruptions?

• Which quality tier correlates with the highest startup latency?

• Did a particular deploy increase avatar frame lag?

• Are errors concentrated in one region, one customer, or one voice configuration?

Compared with console output, traces are durable. Compared with raw metrics, they keep enough causality to explain a problem. For ElevenLabs Agents, the most useful traces are usually those that stitch together the whole realtime path rather than logging isolated API calls.

If you are instrumenting an agent stack, a good practical rule is:

• use logs for human-readable breadcrumbs

• use traces for causal chains

• use metrics for aggregates and alerting

That separation keeps your observability stack from turning into a single overloaded blob of JSON.

Also, be explicit about cardinality. Session IDs are usually fine in traces, but if you attach high-cardinality labels to every metric without discipline, your backend will become expensive and hard to query. Store rich identifiers in trace attributes; keep metrics intentionally coarse.

What changes when a realtime avatar is in the loop

The avatar layer introduces one more observable boundary: the agent may finish generating audio, but the user still experiences a delay if video frame generation, transport buffering, or browser playback falls behind. That means you need observability at the handoff points, not just inside the model code.

A practical tracing model is to mark three milestones:

• agent response ready — the first usable token or response fragment exists

• audio stream started — TTS has begun producing audio bytes

• avatar playback started — the frontend is actually receiving synchronized media

If those times drift apart, the user experience degrades even if your backend “looks healthy.” This is where logs alone tend to mislead you; the service can report success while the user sees lag.

When debugging a session, look for mismatches between server-side completion and client-side playback. In a realtime avatar system, the truth is in the end-to-end path.

Where Protoface fits

Protoface is useful here because it gives you a clear boundary around the avatar/session side of the stack. If you are integrating a voice agent via the LiveKit plugin, the avatar becomes part of the agent pipeline rather than an opaque frontend add-on. That makes it easier to attach logging and trace IDs at the right point in the flow, especially when you are trying to understand whether a slowdown came from the agent, the TTS layer, or the avatar/video path.

For example, in a LiveKit-based agent you can keep your own structured logs around the turn lifecycle while the plugin handles synchronized avatar playback. The plugin and the quickstarts in the ElevenLabs Agents quickstart are a good reference point if you want to see how the pieces fit together in practice. For API details, auth, and session management, keep the docs open while wiring up your instrumentation so your trace attributes match the actual session model.

# Illustrative curl request for creating a session via the REST API

# Illustrative curl request for creating a session via the REST API

# Illustrative curl request for creating a session via the REST API

That kind of session boundary is a natural place to start a trace span and attach identifiers like session ID, avatar ID, and quality tier. The exact fields depend on your integration, but the principle is stable: make the avatar session a first-class part of your observability model, not an afterthought.

Conclusion

If you are building ElevenLabs Agents with realtime avatars, the best logging strategy is not one strategy. Use console logs for quick diagnosis, OpenTelemetry for distributed causality, and backend traces for durable analysis after the fact. Each has a different job, and they work best when you keep their responsibilities separate.

In practice, start by adding structured logs around turn boundaries, then add trace spans for the high-latency stages, then make sure session and avatar identifiers flow through your backend consistently. Once that is in place, you can debug real user sessions instead of guessing from screenshots and stack traces.

If you are wiring this up today, start with the relevant quickstart, confirm your session lifecycle, and then instrument the path end to end. The docs at docs.protoface.com are the right place to check exact request fields, SDK usage, and integration specifics.