Introduction
Registering a LiveKit agent brings its runs under governance like any other framework: register, instrument, and its traces are collected from that point on. Everything downstream — policies, controls, incidents, cost, evaluation — then works exactly as it does for any other asset.
Where to find it
AI Governance > Agent Registry > Register Agent > LiveKit. Instrumentation instructions appear on the agent's Setup tab afterwards.
There is no discovery connection for this platform — LiveKit is not in + Add Application. Agents arrive by registration, not by sweep.
The flow
Register the agent — Platform, name, owner. It arrives as
Setup Pending.Follow the Setup tab — LiveKit setup is Python only and uses the plain OpenTelemetry SDK, with no API key. Follow the numbered steps the panel shows.
Run the agent once — Status flips to
Activeon the first trace.Point a policy at it — Instrumentation gives observation, not governance.
Note: Register at the granularity you want to govern. A single application often runs more than one distinct agent. The registry record is simultaneously the unit of ownership, of policy coverage and of cost attribution — so if two parts of your application need different owners, different rules, or separated cost, they are two records.
What to think about for a real-time agent
Agents that operate in a live session rather than a request-response exchange raise two governance questions worth deciding before you instrument:
What counts as one run? — Session, trace and span are three zoom levels, and how your instrumentation divides a live interaction determines what every downstream number means. An entire conversation as a single trace makes cost per trace and latency close to meaningless. See Sessions, Traces & Spans.
Which surfaces carry the content you care about? — Controls read five points — user input, agent output, tool input, tool output and tool name. What reaches those points depends entirely on what your instrumentation emits.
Emit tool calls, not just model calls
This is the decision that determines how much governance is available to you at all. An agent reporting only its model calls produces complete-looking traces in which no tool-surface control can ever fire — and nothing warns you, because the dashboard looks healthy.
If you emit | You get |
Model calls only | Cost, latency, volume. No tool governance at all |
Model calls + tool calls | The full picture, including every tool-surface control |
Tool results as well | Prompt-injection detection on retrieved content |
One limit to be clear about
An agent registered this way is on an advisory footing: controls evaluate and record, and actions other than Flag need an enforcement point the platform provides. Prevention therefore lives inside the agent — most reliably by not giving it a tool it must never call. See Governing Vendors Without a Control API.
Troubleshooting
Symptom | Check |
Stuck on | Has the agent run since instrumentation? Exporters fail silently, so a misconfigured deployment looks identical to an idle one |
One enormous trace per conversation | An instrumentation choice, not a fault — but it flattens every per-run number. Consider a finer boundary |
Traces arrive, cost does not | Token usage is not on the spans, or no rate exists for that model |
Tool-surface controls never fire | Tool spans are not being emitted |