livekit-protocol: generate the livekit.agent package

[theomonnom]

livekit-protocol ships the .proto sources for the agent package but generates
no Rust for them, so downstream crates hand-generate and vendor their own copy.
This generates them here instead.

Four files, two of them generated:

file	change
generate_proto.sh	+4 protos: agent/livekit_agent_{dev,session,text,inference}.proto
src/lib.rs	pub mod agent { include!("livekit.agent.rs"); }
src/livekit.agent.rs	1,573 lines, generated
src/livekit.agent.serde.rs	14,313 lines, generated

So the review is generate_proto.sh and lib.rs; the other two are generator
output.

No submodule bump. All four protos already exist at the currently pinned
28e604c0:

$ git ls-tree --name-only 28e604c0 protobufs/agent/
protobufs/agent/livekit_agent_{dev,inference,session,text}.proto

so this regenerates against the existing pin. Moving the submodule would drag in
~600 lines of unrelated churn in src/livekit.{rs,serde.rs}, four times the size
of the change anyone needs to read — that belongs in its own PR if it is needed
at all.

🤖 Generated with Claude Code

[github-actions]

No changeset found

This PR modifies versioned packages but doesn't include a changeset. The following packages require a version bump:

• livekit
• livekit-api
• livekit-common
• livekit-data-stream
• livekit-datatrack
• livekit-ffi
• livekit-protocol
• livekit-signaling
• livekit-token
• livekit-uniffi

A package must be bumped when its own files change, and whenever a package it depends on is bumped (so downstream consumers get a matching release).

Click here to create a changeset for the missing packages

The link pre-populates a changeset file with patch bumps for the missing packages. You can also add them to your existing changeset. Edit the bump types as needed before committing.

If this change doesn't require a version bump, add the internal label to this PR.

[devin-ai-integration]

Note

This report is out of date. Scroll down for Devin Review's latest report on this PR.

🔍 Devin Review: 2 flags

Not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)

[devin-ai-integration]

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Pinned schemas roll back public protocol

Regeneration drops newer fields from MetricsRecordingHeader, Job, and ConnectWhatsAppCallRequest, plus the Simulation participant variant. Existing consumers stop compiling or silently discard these wire values.

3 flags not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)

[xianshijing-lk]

can you double check if the PR can be compiled ?

Claude reported a compilation issue with the PR :
The regression

The PR is not purely additive. Regenerating the protos also removes four things from the existing client-facing livekit package:

│ removed │ location │
│ MetricsRecordingHeader.job_id / .simulated / .redaction_enabled │ tags 8, 9, 10 │
│ participant_info::KindDetail::Simulation │ enum value 5 │
│ Job.enable_redaction │ tag 13 │
│ ConnectWhatsAppCallRequest.wait_until_answered │ tag 3 │

Why it doesn't compile

Three of those are silent API regressions — nothing in the repo referenced them. But KindDetail::Simulation is matched exhaustively, with no wildcard arm, at livekit/src/proto.rs:185:

participant_info::KindDetail::BridgeRtsp => {
participant::ParticipantKindDetail::BridgeRtsp
}
participant_info::KindDetail::Simulation => { // <-- variant no longer exists
participant::ParticipantKindDetail::Simulation
}

The SDK-side enum (livekit/src/room/participant/mod.rs:65) still has Simulation, so only the proto side breaks — an unresolved-variant error. That's a hard build failure of the livekit crate, not just a semver-visible removal.

Root cause

Main's checked-in generated files had drifted ahead of the pinned submodule. The pin is 462a90c7 (not 28e604c0 as the PR body claims), and at that pin:

• livekit_models.proto reads BRIDGE_RTSP = 4; // NEXT_ID: 5 — no SIMULATION
• livekit_metrics.proto's MetricsRecordingHeader stops at field 7

So the regeneration was faithful to the pin; the pin is what's stale. Someone had previously regenerated against a newer protocol without bumping the submodule.

Crucially, the author didn't do this by hand. The PR's head commit is:

ba35c31 "generated protobuf"
author: github-actions[bot]

[xianshijing-lk]

lgtm assuming it compiles