On-Call

https://drive.google.com/file/d/1AmzvK2MGix4yKHK7JD54na2nU9mCTQ9L/view?usp=drive_link

Coming into the hackathon, it was essential for me to build something to address a real problem, close to my personal life. So, even after the hackathon, I would remain using this project. My partner and I shared a similar background in often running programs / training processes on remote servers. A common issue that we would run into is that oftentimes, let's say early night, our process would crash and we would only later discover it the next morning when we SSH'd into the server. It was also important for me that I was not just throwing in voice agents for the sake of it, but that it would have been the optimal slash ideal point of contact for our product.

On call is A program that watches your terminal logs and processes that are running on air. A watcher pings the cloud agent. Then the cloud agent calls you and essentially lets you speak to it in natural language back and forth over the phone so that you can get your bug fixed and process back up and running.

We built it using a dummy server that would push error logs for the virtual phone service or bracket VOIP, close bracket, we used Twilio with a local Canadian number. We used 11 Labs voice as well as their voice agents for the back and forth discussion and then for execution and what would be on the remote server we used Cursor's cloud agents.

A big challenge we ran into was tuning the voice agent to give us only the information we needed and nothing more. At the start it was very, very verbose and not very helpful. Additionally, rate limits were an issue early on as we originally tried to speak back and forth directly to the cursor cloud agent. Then we decided we needed a relay, which was the 11 Labs agent, because we were hitting rate limits rapidly.

We're proud to have accomplished OnCall, a voice agent to fix runtime and process bugs. Even after the hackathon, this is something my partner and I would genuinely implement into our ML pipeline workflows to maximize uptime and not lose time to failed runs.

What's next is for Spencer and I, my partner, to get real use on it and make it work perfectly for our use cases. Then we would like to package it up nicely in a Git so it's accessible to everybody. And then potentially see how useful it is to us to share it with others as well through X or LinkedIn.