lk agent simulate: propagate --deployment through SimulationRun create into AgentDispatch

[rdysell]

Summary

lk agent simulate against a live Cloud agent (--agent-name) has no way to select a non-production deployment. Omitted dispatch deployment defaults to production. Shared agent names (one Cloud agent with production + staging + dev deployments) make staging simulations unsafe: they silently hit production workers.

lk dispatch create already supports --deployment. CreateAgentDispatchRequest.deployment exists in protocol. SimulationRun.Create.Request does not have a deployment field. CLI cmd/lk/simulate.go still has:

// TODO (steveyoon): add agent deployment support
// agentDeployment string

Verified on CLI v2.18.1 (installed) and v2.18.6 / main (2026-09-04): lk agent simulate --help documents --agent-name and does not document --deployment.

Protocol @livekit/protocol@1.51.0 added audio impairments and CI metadata to SimulationRun.Create.Request, still no deployment field:

• project_id, agent_name, num_simulations, region, scenario_group, concurrency, mode, background_noise, low_quality_microphone, packet_loss, ci

Required feature (CLI alone is not enough)

1. lk agent simulate --deployment <name> (e.g. staging)
2. Thread that value through SimulationRun create API (SimulationRun.Create.Request.deployment)
3. LiveKit simulation backend must set CreateAgentDispatchRequest.deployment (or equivalent job routing) so the simulated user waits on the same room the pinned worker joins

A CLI flag that is discarded by the create request is not a pin. Rewriting --agent-name to a placeholder and calling lk dispatch create --deployment staging is not a valid pin: Cloud simulate waits for the original --agent-name to join its own room.

Safety motivation

Omitted deployment defaults to production. Staging/dev simulations on a shared agent name (myudda-agent on one Cloud agent id) are then production traffic, which is unsafe and misleading for memory / retrieval acceptance.

Related protocol gap

Please also add deployment on SimulationRun.Create.Request in livekit/protocol protobufs/livekit_agent_simulation.proto, and have the Cloud simulation service honor it when dispatching the agent job.

Environment

• livekit-cli 2.18.1 / 2.18.6
• livekit-agents 1.7.1
• livekit-protocol (PyPI) 1.1.26

[rdysell]

Opened #966 — lk agent simulate --deployment / -d, requires --agent-name, and writes SimulationRun.Create.Request field 14.

Protocol: livekit/protocol#1780

A merged CLI flag is still not a staging pin until Cloud copies that field onto AgentDispatch. our wrapper stays fail-closed until lk agent simulate --help documents --deployment and a staging CSIM lands on LIVEKIT_AGENT_DEPLOYMENT=staging.