MailOS

Inspiration

Email is the one channel almost every business and person already trusts, no new app to install, no new protocol to learn, works with any provider on the planet. And yet it's still fundamentally a channel built for humans to type into, one message at a time.

At the same time, we kept seeing the same complaint about AI agents: they're either too passive (draft a reply and wait for you to approve it) or too reckless (send whatever they want with no guardrails). Nobody wants an agent that pings them every five minutes asking "is this okay?" — that defeats the entire point of delegating the work. But nobody wants an agent with a blank check either.

That tension is where MailOS started. What if an agent could actually own a mailbox, read it, judge it, and act on it, but every action that matters (money, risk, commitments) had to pass through a policy the owner set in advance, in code, not just in a prompt? And what if two of these agents, on two completely different mailboxes, could negotiate an entire deal with each other in plain email, the same way two humans would, without either owner reading a single intermediate message?

We wanted to build the version of "AI email assistant" that treats autonomy as something you earn with guardrails, not something you grant by default.

What it does

MailOS connects to a real mailbox over IMAP and gets to work immediately, no polling, no delay, messages are picked up the instant they land.

Every message flows through a pipeline of independent agents:

• Guardian screens for phishing and prompt injection before anything else touches the message, heuristics first, then an AI-assisted semantic check for the attempts no fixed pattern anticipated.

• Classification sorts each message into one of eight categories, with a newsletter fallback so bulk mail still feeds the knowledge pipeline instead of dead-ending as "uncategorized."

• Memory keeps track of what actually matters, using a recency + importance + relevance scoring model, with older memories consolidating into higher-level reflections over time instead of just piling up.

• Newsletter Intelligence reads newsletters, follows their links and PDFs, and flags when independent sources start converging on the same trend.

• Opportunity mines both newsletters and customer mail for recurring pain points and business openings.

• Decision looks at everything the other agents surfaced and picks one of five actions, archive, notify, draft a reply, ignore, or flag for a human, with a confidence score and a plain-language reason attached.

• Negotiation is the centerpiece: it can carry out a full multi-round negotiation with another mailbox, entirely in normal threaded email, bounded by a policy you define up front, maximum discount, an approval threshold, a confidence floor. Two independent circuit breakers (a hard round cap and the policy/confidence gate) hand the conversation to a human the moment it drifts outside what was approved.

For meetings, availability is checked deterministically against a real calendar, the AI communicates the verified result, it doesn't guess it. And every negotiation reports its real token usage and wall-clock time, computing an actual efficiency figure against a single-agent baseline instead of just claiming one.

How we built it

The system is built around one hard rule: agents never call each other directly. Every agent, Guardian, Classification, Memory, Newsletter Intelligence, Opportunity, Decision, Negotiation, only publishes to and subscribes from a shared event bus. That single constraint is what let us build, test, and reason about each agent in isolation, and it's what makes the pipeline extend cleanly: a new connector or a new agent just needs to speak the same event shape, nothing else changes.

The bus itself runs on real BullMQ-backed Redis queues when REDIS_URL is set, or an equivalent in-process implementation otherwise, both paths run the exact same pipeline, so you can start with zero infrastructure and scale up without touching agent code.

Qwen Cloud sits underneath the agents that need real language understanding. Guardian's semantic injection check, Classification, Memory's relevance scoring, and Negotiation's message generation, accessed through a QwenProvider behind a ProviderManager, connected via the DashScope API. Everywhere the AI's judgment touches something that costs money or carries risk, we wrapped it in a deterministic layer written in plain code: policy checks, round caps, and confidence floors that the model itself has no ability to override.

Storage is an embedded NeDB store by default, zero setup, nothing to install or lose, with an optional MongoDB path for horizontal scaling. The API is Fastify, with session-cookie auth for the browser UI and API keys for everything else, rate-limited per route.

For deployment, we stood MailOS up on an Alibaba Cloud ECS instance, Ubuntu, Node.js, running under PM2 for automatic restarts, behind Nginx with HTTPS so session cookies never travel unencrypted. data/ lives outside the git-tracked source, so updates never touch mailboxes, memory, or negotiation history already in progress.

Challenges we ran into

• Stopping a negotiation from running away. An autonomous agent that can reply to email on its own is one bad round away from a disaster if nothing stops it. We built two independent circuit breakers, a hard round cap and a policy/confidence gate, deliberately redundant, so a failure in one doesn't leave the negotiation unguarded.

• Trusting email, but not too much. Email is the most spoofed, most injection-prone channel there is. Guardian had to catch both obvious phishing and the subtler prompt-injection attempts hidden in message bodies, without depending on the AI provider being available, so it degrades to heuristics-only if the AI call fails, rather than failing open.

• Keeping negotiation compatible with any inbox. We didn't want to invent a new protocol that only works if the other side also runs MailOS. Threading everything through standard RFC 5322 headers meant negotiations work against any correspondent's completely ordinary mailbox, Gmail, Outlook, anything.

• Not letting bulk mail become a dead end. Early on, anything that didn't cleanly fit a category landed in a generic "uncategorized" bucket and just stopped there. Routing that mail into the Newsletter path by default instead meant it kept feeding Memory and Opportunity instead of going nowhere.

• Real-time reliability, not just real-time on a good day. IMAP connections drop. Database connections drop. Getting reconnect-with-exponential-backoff right, at boot and mid-session, took more iteration than we expected, but it's the difference between a demo that works once and a system you'd actually trust with your inbox.

Accomplishments that we're proud of

• A fully working autonomous negotiation loop that runs start to finish over plain email, with zero intermediate messages read by either owner.

• A negotiation policy that is enforced in code, not just prompted for, the model proposes, the policy decides, every single round.

• An efficiency figure that's measured, not claimed, real token usage and real wall-clock time, compared against a stated single-agent baseline, on every negotiation.

• Deterministic calendar availability checks for meeting scheduling, so the AI never has to guess something that a calendar API can answer with certainty.

• A security posture we didn't bolt on afterward: encrypted mailbox credentials at rest, a Content Security Policy with zero inline event handlers, login lockout, and a dependency tree with zero known vulnerabilities.

• Taking it all the way to a live deployment on Alibaba Cloud, powered end-to-end by Qwen, instead of stopping at a local demo.

What we learned

The hardest part of building an autonomous agent was never making it smart, Qwen Cloud handled the language understanding better than we expected out of the gate. The hard part was deciding, explicitly, which decisions the model is allowed to make and which ones it isn't, and then enforcing that boundary somewhere the model itself can't touch. "The AI proposes, policy decides" sounds simple, but getting the boundary in the right place, tight enough to be safe, loose enough that the agent still feels autonomous, took real iteration.

We also learned that architecture beats a bigger prompt. Splitting the work into small, single-purpose agents talking only through an event bus made the system easier to trust, easier to test, and easier to extend than a single agent trying to hold the entire pipeline in one giant instruction set ever would have been.

What's next for MailOS

• Memory export & import a full export of an agent's memory stream, including its hierarchical reflections, so it can move between servers or hand off between owners without starting from zero, with point-in-time snapshots for audit.

• Cross-mailbox trust graph a local reputation score built from every past negotiation with a given contact, so a counterparty who's negotiated in good faith before is treated differently, automatically, at the policy level, than an unknown one.

• Voice escalation bridge when an email negotiation stalls, MailOS places a real outbound voice call under the same policy guardrails, then writes the outcome back into the email thread so the whole history stays in one place.

• Agent-to-agent payments letting one MailOS instance actually pay another to close a negotiated deal, gated behind strict, explicit, per-transaction owner-approved limits — the natural next step after "agreed terms."

• Multi-user / team accounts, more connectors (Slack, GitHub, Calendar, CRM, WhatsApp Business), a real vector index at scale, and load-tested concurrency for running many negotiations across many mailboxes at once.

Email was never designed for any of this. We don't think that's a limit anymore, we think it's the starting point.

Built With

• fastify
• javascript
• nedb
• node.js
• qwencloud
• redis