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.
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.
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.
Lots of cool stuff to build here, and one day soon expand to the full office suite for ai agents.
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.