Show HN: Local Email Client for AI Horseless Carriages

14 shahahmed 6 7/24/2025, 5:36:55 PM github.com ↗
The AI Horseless Carriages article spurred a lot of conversation about how we should just be giving users the system prompt box [0], and we were pretty surprised that a bunch of email clients didn’t pop up following this pattern [1].

So we went ahead and created a local [2] email client that you can run that processes your inbox with your own handwritten rules. It lets you label and archive based on natural language rules. You can draft responses with your own drafting prompt, and there’s a “research sender” option that uses web search to get public info on a sender. You can customize any of the prompts to fit your needs. We’d love to hear what you think and PRs/issues are welcome!

[0] https://news.ycombinator.com/item?id=43773813 [1] Superhuman seems to be pulling on this thread [2] uses OpenAI for this version, client runs locally, ollama support soon!

Comments (6)

forty · 1d ago
How do you prevent someone random from asking your bot to archive all your emails (for example) with a specifically crafted email ?
splitbrain · 1d ago
Yeah, and if this can also automatically send mails, we not only have prompt injection but also data exfiltration.
dbish · 1d ago
2 things right now, 1) it can only draft emails, requires human in the loop to send still. 2) every email you can think of as resetting the context so at most you can only prompt inject your email and get it classified differently or have the agent try to use one of the available tools just for that email, it won’t impact other emails.
dbish · 1d ago
We’d love to hear feedback on this. It’s a proof of concept but I really want to 1) offer agents within an inbox (and integrate to” “dispatch” work to agents running in services like n8n or retool), and 2) offer email inboxes for agents themselves just like coworkers.

Lots of cool stuff to build here, and one day soon expand to the full office suite for ai agents.

supah · 15h ago
Why not just create its own email like usual. Provide a MCP to the inbox?
dbish · 8h ago
A few reasons:

1. Some people want to have a very clear set of rules/process for which emails are "viewable" by an AI Agent, so a seperate "inbox" makes it a little easier for people to understand what an Agent is looking at (and add more customizability, controls, traceability, etc.)

2. Human/AI collaboration still requires some UX, we are not (yet) at the point of a fully automated agent that just does stuff and tells you what it did, I expect most apps need an AI-native version that have collaboration UX specifically made for giving feedback to an AI, approving what its done, etc. and MCP is just a way to specificy API access in a sense and not enough.

3. This first version is locally run and manually triggered (reactive) for fetching new emails, but we if you want to automatically run agents as new email comes in (proactive - which is our goal) we need a server to be processing new email and triggering the right agent, so this is one step towards that rather then just trying to give an MCP server to Claude or another assistant that is reactive instead of proactive.