Hi LiveKit team, We're sizing a self-hosted LiveKit deployment on EKS for a voice AI use case — S2S agents handling outbound calls in Spanish, ~3–5 min average duration, expected peak concurrency around 8–10% of daily volume. A few questions where your guidance would help us avoid over- or under-provisioning: 1. 10K calls/day baseline. For a steady-state of ~10K daily calls with the profile above, what's your rule of thumb for SFU pod count, agent worker pods, and node sizing (CPU/RAM, NIC)? Any specific guidance on media server CPU per concurrent participant for AI agent calls vs. human-to-human, given the audio is essentially 1:1 (agent ↔️ caller) but with continuous TTS/STT load? 2. Scaling to 100K calls/day. When customers move from ~10K to ~100K daily, do you typically see linear scaling of the SFU tier, or do bottlenecks shift elsewhere (signaling, TURN, Redis, ingress/egress, agent dispatch)? Any architectural patterns you'd recommend at that scale — multi-region, sharded node pools, dedicated agent pools per use case? 3. Dedicated K8s cluster. At what scale do you see customers move LiveKit onto a dedicated cluster vs. running it alongside other workloads? We currently share an EKS cluster with the rest of our platform (Cilium CNI in ENI mode with kube-proxy replacement, IRSA, Kyverno, Tetragon). Are there isolation or perf reasons — kernel networking, CPU pinning, NIC saturation, noisy-neighbor on UDP/RTP — that push toward a dedicated cluster earlier than raw call volume alone would suggest? Happy to share more detail on the agent stack, codec choices, and traffic profile if useful. Thanks, Ángel