Thanksgiving Is for Family. Mine Was for Code.

Earlier this week I recorded a ten-second voice note asking for a dinner reservation, put my phone down, and went back to what I was doing. A few minutes later the confirmation was waiting for me. I could have made that booking myself, obviously. I've been making my own dinner reservations for decades with a reasonably good success rate. What I couldn't have done was make it without stopping everything else, and that small difference is the whole reason I've spent the last few days building a personal AI assistant I call ack.

Why build my own when Meta just shipped one?

Meta launched Muse on September 8, and I'll admit the idea is a good one. It's a personal agent that books travel, sends email, fills out forms and keeps working in the background after you close the app. Each user gets what Meta calls the Muse Secure VM, an isolated Linux machine with its own browser, CPU, memory and storage, so the agent has a persistent computer to work from. That persistent computer is the part I actually wanted. An assistant that can open a browser and click through a booking page is far more useful than one that can only tell you which booking page to visit.

The catch is where that computer lives. Zuckerberg's own pitch is that your data and credentials sit on the Muse Secure VM, which is a polite way of saying they sit in Meta's data centre. To make Muse useful you connect your email, your calendar, your payment methods and, according to Fox Business, categories as personal as health and the smart home. Meta promises Muse conversations won't feed its ad systems, and maybe that promise holds. I've watched Meta's privacy promises age over the last fifteen years, though, and I'd rather not run the experiment with my inbox. Muse is also US-only for now, which made the decision easier. If I want a personal agent with a computer behind it, I'll run the computer myself.

So what can ack actually do?

More than I expected after a few days of work. ack has a voice mode that can make and receive phone calls, an SMS mode, and both currently ride on Twilio. It ingests and sends email through SendGrid. It manages todos, reminders and scheduled tasks, which is how it ended up tracking a UPS package for me and pinging me whenever the status changed (the package is fine, thanks for asking). There's an iOS app on the front end, which is where those voice notes come from. Calendar access comes through MCP, and that's the part I'm quietly proudest of, because I didn't have to build it.

A while back I wrote about EventStream, a small self-hosted calendar aggregator with an MCP server bolted on. At the time it solved one annoying problem for me and nothing else. This week ack plugged into it in about the time it took to paste a URL. The same thing happened with the Asterisk server I already run for telephony. Most of ack is glue between pieces I'd built for other reasons, plus a few good ideas borrowed from other open-source assistant projects. That's why it came together in days instead of months, and it's the best argument I've seen yet for building small utilities that do one job and expose a clean interface.

The two most useful things it's done so far are thoroughly unglamorous. It made that dinner reservation, and it finds me GO Train times. Neither one is going to make a keynote stage. Both are exactly the kind of two-minute errand that breaks your concentration, and handing them off to something that reports back when it's done feels genuinely different from asking a chatbot a question and waiting for the answer.

ack itself is still in testing. There's a long list of rough edges and I'd like to sand a few of them down before anyone else has to look at the code. I'm hoping to open-source it soon. In the meantime, two pieces of it are ready now.

What's being released today?

The first is imsgd. I wanted ack to read and send iMessages, and the obvious answer was BlueBubbles. BlueBubbles is a great project, but it does a lot more than I needed and carries a lot more overhead than I wanted on my Mac. imsgd is a single Go binary with no Electron, no cloud services and no Firebase. It runs on a Mac signed in to Messages and gives apps on your local network an HTTP API to read chats, receive new messages in real time over WebSocket or signed webhooks, and send text and attachments with confirmation that each one actually went out. It learned a lot from BlueBubbles, but it's a fresh, smaller design and the API isn't BlueBubbles-compatible. Sending runs through AppleScript, so things like reactions, edits and creating group chats aren't possible without disabling System Integrity Protection, which I wasn't prepared to do on my daily machine. imsgd will still report those events when they happen on your other devices.

From an architecture perspective, imsgd isn't the messaging layer. ack has its own ack-messages service that provides a generic messaging interface - imsgd is simply the Apple-specific provider behind it. If I want Signal or WhatsApp later, that's another small provider, and ack never needs to know the difference. It's the old Unix philosophy at work: do one thing and do it well, then let something else handle the next thing. One warning worth repeating from the README is that imsgd can read every message on your account and send as you, so treat its API keys like passwords and keep it on a network you trust.

The second project is sports-mcp, an MCP server for live scores, schedules and team information. It's built on the same data sources behind pulseboard.ca, covering the NFL, NHL, NBA, MLB, NCAA football and men's basketball, the Premier League, La Liga and the Bundesliga. Ask it how the Leafs did last night and it understands "leafs" without needing a team ID. Postseason games come back with the round and series status attached, a feature I'd have enjoyed a lot more if the Jays were still playing. It also exposes the same operations over plain REST for anything that doesn't speak MCP. Upstream traffic doesn't grow with demand, since one scoreboard call per league per day serves every client, and access logs store a salted, rotating hash of the client IP in place of the IP itself.

There's a public instance running at sports-mcp.pulseboard.ca if you want to point your own assistant at it. Anonymous clients get roughly 60 requests a minute. Please don't make me lower that.

Where does this go next?

The personal agent space is about to get crowded. Meta has Muse, OpenAI and Anthropic keep folding agent features into their own assistants, and open-source projects are moving faster than any of them. Most of that energy is going into building the agent. Far less is going into the boring connective tissue an agent needs to be useful: something that can read your messages, check your calendar or tell you the score without shipping your life to someone else's data centre. Those small pieces are where I think people like me can actually contribute, because each one is useful on its own whether or not anyone ever runs ack.

So grab imsgd or sports-mcp, break them, and file issues. If you've built something similar, I'd love to compare notes. ack will follow once I'm no longer embarrassed by parts of it. Some people spend Thanksgiving weekend with family and a turkey. I spent mine with a Mac, multiple code repos and a UPS tracking number, and I'd do it again.