MXGo.ai: privacy-first AI layer for your emails that works without any installation

Most AI tools try to pull you out of your workflow.Email → copy content → paste into tool → get result → come back. That loop is the real inefficiency. While building MXGo.ai, the goal was simple: What if we didn’t build another app… and instead turned email itself into the interface? This article breaks down how we built an AI-powered email automation system that lets users summarize, analyze, research, and generate outputs—just by forwarding emails. The core idea: email as an execution interface Instead of building a dashboard, we treated email like an API surface. Users don’t log into MXGo. They just forward an email to a specific handle to get a response back in their inbox Example: send tosummary@mxgo.ai→ get a summary send toresearch@mxgo.ai→ get insights send toschedule@mxgo.ai→ get reminders for recurring tasks This design decision simplified everything on the frontend but made the backend significantly more complex. System architecture The system can be broken into four layers: Email ingestion Task routing AI processing Response generation Each layer had to work reliably because email is inherently asynchronous and unpredictable. Handling email ingestion reliably The first challenge was receiving and parsing emails across providers. We needed to support: Forwarded emails (with nested threads) Attachments (PDFs, docs, images) Different formats (HTML, plain text) Key implementation steps: Set up inbound email parsing (via SMTP/webhooks depending on provider) Normalize email structure into a standard internal format Extract sender, subject, body (cleaned from HTML noise), attachments Forwarded emails were especially tricky because the actual content is often buried inside multiple layers of quoted text. We built parsers to isolate the latest meaningful content, instead of processing entire threads blindly. Task routing using email handles Once an email is parsed, the next step is deciding what to do with it. We used email handles as task triggers.Instead of building a command system inside the email body, the recipient address itself defines the action. Example mapping: summary@ → summarization pipeline translate@ → translation pipeline analyze@ → document analysis This keeps the UX extremely simple while allowing flexible backend expansion. Processing attachments without breaking flow Attachments are where most email workflows break. Users typically:Download file → Open separately → Analyze manually We wanted to eliminate that completely. The system processes attachments automatically: PDFs → parsed and chunked Documents → text extracted Images → processed via vision models The key challenge was context merging. We don’t just process attachments separately. We combine: Email context, attachment content. This allows outputs like: “Here’s a summary of the email + key insights from the attached report.” Building the AI processing layer The AI layer is not a single prompt. It’s a pipeline. Each task has its own flow: 1. Summarization pipeline Clean input Chunk long content Generate structured summary 2. research pipeline Extract intent from email Expand queries Generate insights 3. Document analysis Parse attachment Identify key sections Generate explanation or output We also added: Context limits handling (chunking + stitching) & Output formatting (bullet summaries, reports, etc.) Generating structured outputs (reports, PDFs) For tasks like report generation, plain text responses are not enough. We built output formatters that: Structure responses into sections Convert them into clean layouts Optionally generate PDFs This allows users to forward something like: “Analyze this document” And receive a structured report which is ready to share or download Keeping everything inside email One of the biggest wins was eliminating tool switching. Users can: Forward → get result Reply → refine output Forward again → trigger another action This creates a loop entirely inside email. No dashboards. No logins. Designing a privacy-first system Email data is sensitive by default. So, the system was designed with strict constraints: Emails are processed transiently No long-term storage of content Attachments are discarded after processing For enterprise use cases, we also made the system that is deployable in self-hosted environments and isolated from external data flows Privacy was not a feature. It was a requirement. What this unlocks With this system in place, email becomes more than communication. It becomes an execution layer. Users can: Summarize long threads instantly Extract insights from attachments Generate reports without switching tools Automate repetitive workflows All without leaving their inbox. Where this fits This approach overlaps withAI inbox triage systems, Email-to-workflow automation and document intelligence platforms But the key difference is that the interface is still email. Everything else happens behind the scenes. In conclusion Most productivity tools try to replace existing workflows. MXGo.ai does the opposite. It works inside one of the oldest and most widely used interfaces, email and upgrades it with AI capabilities. From a build perspective, the interesting part isn’t just the AI. It’s how: Email becomes the trigger Routing replaces UI Pipelines replace single prompts Sometimes, the best interface is the one user already use. You can read complete case study here:https://www.zobyt.com/work/mxgo-ai-save-4-hours-every-week-with-ai-email-agents At Zobyt, we have built several systems like this to enable transparency and efficiency through technology. If you’re interested in something similar, do reach out todiscuss@zobyt.com