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 to [e-mail] → get a summary
• send to [e-mail] → get insights
• send to [e-mail] → 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:

1. Email ingestion
2. Task routing
3. AI processing
4. 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:

1. Forwarded emails (with nested threads)
2. Attachments (PDFs, docs, images)
3. Different formats (HTML, plain text)

Key implementation steps:

1. Set up inbound email parsing (via SMTP/webhooks depending on provider)
2. Normalize email structure into a standard internal format
3. 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:

1. Structure responses into sections
2. Convert them into clean layouts
3. 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:

1. Forward → get result
2. Reply → refine output
3. 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:

1. Emails are processed transiently
2. No long-term storage of content
3. 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 with AI 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 to [e-mail]