Initially, the only way to talk to Sentinel was through the web UI on my local network. That was fine for development but it’s not exactly “autonomous AI assistant” territory.
I wanted it reachable from my phone. From anywhere. Through the channels I already use.
Signal was first. The idea was simple — send a message from my phone, Sentinel processes it, replies in the same thread. The reality was significantly less simple. Signal-cli is a Java application that holds a config lock at startup, which means you can’t spawn a second process while the first one is running. My initial approach of calling signal-cli send from the script blocked indefinitely because the daemon was already holding the lock.
The fix was to talk to the daemon directly through a Unix socket using JSON-RPC. No spawning, no locking, just socket communication. It works, but it took longer to figure out than I’d like to admit.
Telegram came next — more straightforward, though there’s a lifecycle gotcha with the Python library where you have to call start() after initialize() or the handlers never fire. The kind of thing that’s obvious once you know it and invisible until you do.
Then email (IMAP for receiving, SMTP for sending), calendar (CalDAV), and web search (through the Brave API). Each one followed the same pattern: research the integration, build the connector, wire it into the planner’s tool list, test it end-to-end.
The first time I sent a message from my phone and got a properly planned, scanned, and executed response back was a genuinely exciting moment. It felt like the system had graduated from a dev tool to something real.