You're seeing the agent watchdog kill the job because the tool call (simple RAG) made the agent process unresponsive. The logs show the agent sent SIGUSR1 and then the process exited with code -10 (SIGUSR1), which means the watchdog attempted to get a stack dump and then force-killed the hung worker. What likely caused it (given you're using Polly + Transcribe with a RAG tool): • The RAG tool performed a synchronous/blocking operation (blocking network call, blocking file I/O, or CPU-heavy work) that prevented the agent from responding to health pings. • Long external request latency (embedding/vector DB, external APIs) without timeouts or retries. • Pod resource constraints or throttling in EKS increased execution time so the agent missed health checks. Immediate actions to try • Make the RAG tool fully asynchronous (use async HTTP client,

async/await

) so it doesn't block the event loop. • Add explicit timeouts and retry logic around external calls (e.g.,

asyncio.wait_for(..., timeout=10)

). • Avoid blocking calls like

requests

,

time.sleep()

, or heavy synchronous CPU tasks inside the tool — move them to background tasks if needed. • Increase pod CPU/memory limits in EKS (or use non-burstable instances) to avoid throttling. • Instrument and log durations inside the tool (start/end timestamps) to identify slow steps. Diagnostics I can help with • Which parts of your RAG workflow are synchronous (embedding calls, DB queries, local inference)? • Share the tool code snippet (especially external call patterns) and your pod resource limits — I can point out exact changes to make it non-blocking. • Frequency of this error and whether it correlates with high load or specific queries. Would you like me to review the RAG tool code or your pod resource config next? Sources: Troubleshooting Latency and Timeout Errors with Turn Detection on AWS | External data and RAG | LiveKit Docs | Tool definition and use | LiveKit docs