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.

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.