This skill is a practical, 'use-it-while-debugging' reference for getting a LiveKit + Letta voice agent working reliably.
This skill is a practical, "use-it-while-debugging" reference for getting a LiveKit + Letta voice agent working reliably.
Override the right LiveKit hook
llm_node, not generate_reply.Only ONE voice-agent process can run at a time
Use dev mode for local testing
start can sit waiting for dispatch and look "broken."dev mode is the fast path.Run this when things are wedged, timeouts are happening, or audio is cutting out. It kills old processes, restarts LiveKit in dev mode, then restarts the Letta voice agent.
pkill -9 -f letta_voice_agent.py
pkill -f livekit-server
sleep 2
cd /home/adamsl/ottomator-agents/livekit-agent
nohup ./livekit-server --dev --bind 0.0.0.0 > /tmp/livekit.log 2>&1 &
cd /home/adamsl/planner/a2a_communicating_agents/hybrid_letta_agents
/home/adamsl/planner/.venv/bin/python3 letta_voice_agent.py dev > /tmp/letta_voice_agent.log 2>&1 &
LiveKit responding (not just "listening")
curl -v http://localhost:7880/ 2>&1 | head -20
If this hangs or times out, LiveKit is stuck โ restart it.
Confirm you don't have duplicate voice-agent processes
ps aux | grep letta_voice_agent | grep -v grep
You should see exactly one.
Confirm Letta routing is actually being used
Watch your logs for your ๐ค marker (or equivalent logging) that proves llm_node is being hit.
If the browser tries:
ws://127.0.0.1:7880//rtc
Use instead:
ws://localhost:7880
Reason: The client appends /rtc, and some configs end up producing a double-slash.
Most common causes:
generate_reply instead of llm_node)llm_node and confirm your override is in place.