I want to tell you a story. Not the polished kind you see on a pitch deck, but the real one — the late nights, the small wins, the moments I almost gave up, and how Qwen Cloud carried this whole thing on its back.
The problem that wouldn't leave me alone
If you have ever run a small business, or even just managed a busy inbox, you know the pain. Email doesn't stop. Customers dey ask questions. Suppliers dey negotiate price. Newsletters dey pile up unread. And somewhere in that pile is the one email that actually matters — the one you missed because you were tired and scrolling too fast.
I kept asking myself: why is email still this dumb? We have AI that can write essays, generate images, even hold a conversation better than some humans. But my inbox? Still sitting there, doing nothing, waiting for me to read every single message myself.
That question refused to leave me. So I decided to build something.
Why I chose Qwen Cloud
I tried a few things before I landed on Qwen. Some models were fast but shallow — they could classify an email as "spam" or "not spam" but couldn't hold a real negotiation across many back-and-forth messages. Some were smart but too expensive to run for every single email that touches an inbox, and email touches your inbox a lot.
Qwen Cloud surprised me. It was strong enough to read a messy, badly-formatted business email and actually understand the intent behind it — is this person trying to sell me something, complain, or trick me? It was fast enough that I could run it on almost every message without my server crying for help. And honestly, setting it up wasn't stressful at all. I created an account on Alibaba Cloud's Model Studio, generated an API key in a few minutes, dropped it into my .env file, and I was talking to Qwen from my code before my coffee got cold.
That was the moment I knew: this is the engine my project needed.
Building MailOS, one agent at a time
I didn't want to build "just another AI email assistant" that summarizes your inbox and calls it a day. I wanted something that could actually act — read mail, judge if it's dangerous, understand what it wants, and in some cases, respond and negotiate on its own, without me babysitting every message.
So I broke the work into small, focused agents, each one doing one job well:
Guardian checks every incoming email for phishing and prompt injection before anything else touches it. I built this one first because trust is everything — if my system can be tricked by a bad email, nothing else matters.
Classification figures out what kind of email it is — customer message, invoice, meeting request, newsletter, spam.
Memory remembers what matters. Not everything, just the important stuff, the way a good assistant would.
Newsletter Intelligence reads through newsletters, pulls out the ideas and trends worth knowing, so I don't have to read fifteen newsletters myself.
Decision looks at everything and decides: archive this, notify the owner, draft a reply, ignore it, or hand it over to a human because it's too important to guess.
Negotiation is the one I'm most proud of. This agent can actually go back and forth with another mailbox — asking for a better price, agreeing on payment terms — all inside a policy I set. It has a hard round limit and a confidence floor, so it never runs wild. If it's not sure, it stops and calls me.
Every one of these agents leans on Qwen Cloud to think. Not blindly — I never let the AI make the final call on money or risk by itself. The AI proposes, my code decides. That balance took me a while to get right, but it's the part I trust the most now.
The moment it actually worked
I remember the first time I watched MailOS negotiate a deal by itself. I sent an opening offer through the API, walked away to make food, and came back to find three full rounds of back-and-forth had happened — politely, professionally, in plain English, over normal email — and it landed inside the price range I had set. Nobody touched a keyboard except me at the very start.
I just sat there staring at my screen. That's when this stopped feeling like a hackathon project and started feeling like something real.
Taking it to Alibaba Cloud
Building it on my laptop was one thing. Making it live for the world was another matter entirely. I moved MailOS to an Alibaba Cloud ECS instance — a simple Ubuntu server, nothing fancy, 2 vCPUs and 2GB of RAM was more than enough to start. I installed Node.js, cloned my repo, set my environment variables, and ran the whole thing under PM2 so it restarts itself if anything goes wrong. Then I put it behind Nginx with HTTPS so my login sessions stay safe.
Watching MailOS run on a real server, connected to a real mailbox, reading real mail, all powered by Qwen Cloud sitting quietly in the background — that was a proud moment for me. No wahala, no drama. It just worked.
What I learned
Building MailOS taught me something I didn't expect: the hard part of AI agents isn't making them smart. It's making them trustworthy. Anybody can wire an API call to a language model and call it "AI-powered." The real work is in the guardrails — the policy checks, the round caps, the moments where the system says "I'm not sure, let a human decide." Qwen Cloud gave me the intelligence. I had to build the discipline around it.
Where this is going
MailOS isn't stopping here. I'm working on a way to export an agent's whole memory so you can move it between servers without starting from zero. I'm also building something wild — a trust score that remembers how every contact behaved in past negotiations, so MailOS treats a trustworthy supplier differently from a stranger, automatically. And the one that still makes people's eyes widen when I explain it: teaching MailOS to pick up the phone and make an actual voice call when an email negotiation stalls, then write the outcome back into the thread like nothing happened.
Email was never designed for this. But with Qwen Cloud doing the thinking underneath, I don't think that's a limitation anymore. It's just the starting point.
If you want to see it, break it, or build on top of it, MailOS is open source. Come and look at https://github.com/mitmelon/mailos.
Built with a lot of coffee, a lot of debugging, and Qwen Cloud carrying the intelligence the whole way.
Thanks for reading.
Top comments (10)
I think the most important sentence in the whole article is: “The AI proposes, my code decides.” That captures the difference between an AI demo and an AI system you can actually trust. I also appreciate that you focused on guardrails instead of only model quality. Round limits, confidence thresholds, and human escalation are much more interesting than simply saying a model is “smart.” One area I’d love to see expanded is the decision layer itself. For example, how are negotiation policies represented? Are they deterministic rules evaluated after the LLM proposes an action, or does the model participate in policy interpretation as well? Likewise, how does the Guardian distinguish prompt injection from legitimate business emails without becoming overly conservative?
The architecture sounds promising, and a deeper write-up on the policy engine and trust boundaries would be just as interesting as the choice of model.
Thanks, that means a lot, especially since "the AI proposes, my code decides" is genuinely the line I'd want people to walk away with over anything about model choice.
To answer both questions directly:
On the policy layer, it's deterministic, not model-interpreted. The negotiation policy is a plain settings object (maxDiscountPercent, maxRounds, requireApprovalAboveAmount, minConfidenceToAutoSend), and it's evaluated in code after the model proposes a move, not by the model. The LLM never sees the policy as something to reason about or satisfy, it just proposes a reply, and the policy check either lets it through, forces a smaller counter, or trips one of two circuit breakers (hard round cap, or confidence/approval threshold) and hands off to a human via webhook. So the model has zero write access to the rules that bound it, it's read-only context, not a participant in interpreting them. That separation was actually the part I iterated on the most; the first version I built let the model "explain why an exception was reasonable," and I killed that immediately once I realized it meant the model was quietly negotiating with its own guardrails.
On Guardian, it's staged rather than a single judgment call. Heuristics run first: known phishing patterns, header anomalies, that kind of thing, instant, zero AI cost, and they catch the obvious stuff without ever touching the model. The AI-assisted semantic check only fires for what the heuristics can't confidently rule on, the injection attempts that don't match any fixed pattern, hidden in what otherwise reads as a normal business email. That staging is also what keeps it from being overly conservative: most legitimate mail never reaches the AI layer at all, so there's no accumulating false-positive pressure from a model being asked to judge everything. And if the AI call itself fails or times out, Guardian falls back to heuristics-only rather than blocking, it degrades, it doesn't fail closed on availability.
You've actually put your finger on the part of this project I think is most underwritten publicly, the policy engine and the trust boundary between "the model can suggest this" and "the system will actually do this" deserves its own write-up rather than a paragraph in a project story. I'll put that together as a follow-up. Appreciate you pushing on it.
I like that the model can propose actions but not reinterpret its own guardrails. To me, that’s one of the biggest differences between an AI demo and a production AI system.
Exactly and I think that's the line most "agentic AI" projects blur without realizing it. It's easy to build something that feels autonomous because the model is fluent and confident. It's a different thing entirely to build something where the autonomy is bounded by code the model can't touch, negotiate with, or talk its way around. The moment a model can reinterpret its own constraints, even with good intentions, you've quietly moved the trust boundary back inside the black box, and now you're trusting the model's judgment about its own judgment. That's the demo trap.
Appreciate you sticking with this thread, it's pushed me to actually write the policy-engine follow-up rather than keep putting it off.
I think “the model must never become the interpreter of its own constraints” is a principle worth applying beyond email agents. It feels like one of those architectural rules that stays valid regardless of which model or framework we’re using.
Agreed, and I'd go further, I think it's less an "agent architecture" rule than an old systems-engineering rule wearing a new coat. We didn't let application code interpret its own security policy before LLMs existed either; that's what separate authorization layers, database constraints, and permission systems have always been for. The only thing that's new is that the component asking for trust can now argue its case fluently, in natural language, which makes it feel like a judgment call worth listening to in the moment. That's exactly why the rule matters more here, not less, a buggy function doesn't try to talk you out of the guardrail. A capable model can, even without meaning to.
If anything, I'd say the models make this discipline harder to hold onto, not easier because the failure mode isn't a crash, it's a plausible-sounding exception that quietly erodes the boundary one reasonable-seeming case at a time.
That’s a great way to put it. The more persuasive a component becomes, the less authority it should have over the rules that constrain it.
If the other side's mailbox is also an agent, what stops it from politely asking yours what its price ceiling is? I'm curious whether the model writing the replies ever sees the actual policy numbers, or only gets accept/reject decisions back from your code.
The per-email cost point is the one people underestimate. I run Qwen locally on a pair of 3090s for exactly this reason, once you are hitting a model on every message that lands the API bill turns into a subscription you never signed up for. For high-volume inbox work the local route paid for the cards inside a few months for me. One thing I'd watch as you scale MailOS: the intent read is easy on a clean email, but negotiation threads are were it drifts, the model starts losing track of what was already agreed three replies back. Keeping a short running summary of the thread state and feeding it back in helped me more than a bigger model did. How are you handling the long back and forth threads right now?
Excellent write-up!
I really enjoyed reading about the journey behind MailOS, especially the focus on building trustworthy AI rather than just adding AI for the sake of it. The way you separated responsibilities into specialized agents and emphasized guardrails makes the architecture much more practical for real-world use. Wishing you continued success with the project—it's exciting to see thoughtful open-source AI solutions like this.