Future Primitive AI: Email

In my last post, I broke down a PySpark scenario to show how agents work better when you strip away the UI and go straight to the data. Headless agents, deterministic validation, metadata as interface. Good stuff, but admittedly niche — not everyone's running Databricks clusters.

So let's take the same lens to something everyone uses every day: email.

In SemOps, there's a process I call primitive decomposition — you take any platform or service and break it down to its atomic, vendor-agnostic capabilities. What does it actually do, not what's it called or what the UI says. The result is a neutral understanding of the system — one that works for both the human evaluating it and the AI agent that has to operate it. That's a good thing.

So, I thought it would be telling to explain this process and its implications for something extremely common — email. A while back while I was setting up agents to do all sorts of things including manage my "back office", I thought Gmail would be a great partner for agentic flows, but, alas, headaches. So I found a much simpler solution in Fastmail, and there are others that share its stripped and agent-friendly properties. So why is this?

What Is Primitive Decomposition and why do I care?

Well, before we enter the exciting world of email, a bit of background. Primitive Decomposition is a term I made up, just like Explicit Enterprise and Explicit Architecture. In SemOps, these concepts all boil down to a fundamental pillar which is that its architecture first, and architecture describes the entities and rules of the business, not tech things or brandnames. So, "send a message" or "snooze an alert" are good architecture descriptions and good for humans and agents to understand without a lot of additional context. I'll be getting deeper into this in a four-part series on "what is architecture" — and no, I'm not kidding, but for now, let's just say/agree: agents don't use UIs - they make API calls, read data structures, and manage credentials. Agents are good at "sending messages" when that path is clear. Ok - so Gmail vs. Fastmail.

The Primitives of Email

So what is email at the primitive level? Well, it's kind of what you would expect:

• Send a message (SMTP).
• Receive and store it (IMAP, or whatever the backing store is).
• Organize it — folders, labels, flags, whatever the system calls them.
• Search across the mailbox.
• Authenticate — prove to the server that you're allowed to do these things. And if you want to go beyond email proper: contacts (CardDAV) and calendar (CalDAV), which almost always travel with an email account.

That's it. Every email service in existence implements these same primitives. The differences aren't what they do — it's how they expose them.

Gmail: Application First, Email Second

Gmail was built as a web application first — its own product with its own data model and threading logic. The standard email primitives (IMAP, SMTP) are supported, but they're a translation layer on top of Gmail's internal model, not the foundation¹. Labels, for example, don't actually Organize like primitive-based email systems do — a message isn't moved into a folder, it's tagged with one or more labels. That's what made Gmail a great product — conversation view, powerful search, multi-category organization. But when you decompose it to primitives, you're looking at a Gmail-shaped abstraction of email, and your agent has to work through that abstraction.

The Authenticate primitive is where it gets complicated. Gmail's REST API uses OAuth2² — client IDs, client secrets, GCP Console projects, consent screens, scope approvals, and access tokens that expire every hour. If you don't know what all that means, hopefully you never have to, because enterprise auth is hell, but do take away that auth is the one primitive agents can't set up for themselves, and it is the one thing that will definitely break at some point (token expires) and you will have to fix it. I consider myself fairly technical, and I actually worked on an enterprise product at Azure, but let me tell you that configuring the right tenant level, resources, scopes, permissions, etc. in large-scale enterprise systems can and has made grown people cry.

Gmail's data model centers on the Thread, not the Message. The threading algorithm uses Subject line heuristics and References headers, and its logic is internal. Labels aren't folders — a message can have multiple labels, and removing a message from the inbox means removing its INBOX label, not moving it somewhere. There's no explicit delete primitive — messages go to Trash and are purged after 30 days. These are design choices that work well for Gmail's human UI, but they mean an agent's mental model of "folders and messages" doesn't map directly.

Real-time notifications use Google Cloud Pub/Sub, which adds a GCP infrastructure dependency. Between the REST API, IMAP translation layer, and Pub/Sub, an agent integrating with Gmail is working across three different interfaces with three different mental models.

Fastmail: Infrastructure With a UI on Top

Now let's run the same decomposition on Fastmail.

As you've probably predicted, Fastmail is built from primitives: IMAP, SMTP, CalDAV, CardDAV — all first-class, all RFC-standard, no translation layer. Its primary API is JMAP (JSON Meta Application Protocol)³⁴, which is also an open standard, designed from the ground up for programmatic access. Your agent can hit the session endpoint and discover every available capability without documentation. It's very handy infrastructure.

Authentication is managed through app-specific passwords⁵ — same pattern as many API-friendly systems, stored as an environment variable ready to hand it to your agent, stable until you explicitly revoke it. Is it less secure? Not really — OAuth2 and the complext multi-tenant enterprise auth systems are designed to protect users from untrusted third-party apps, which is a different problem than an agent accessing an authorized mailbox. Security for agent credentials lives in your secret management — vaults, CI/CD, scoped access, revocability, and that's true regardless of what flavor of auth you are using.

The data model is dead-simple: Mailbox, Email, Thread, Identity, Submission -- all words that people understand and say. The content of the email is also simple, containing MIME-standard textBody, htmlBody, and attachments as first-class fields, not "base64url-encoded RFC 2822 blobs wrapped in JSON". That's in quotes because that's LLM help and I honestly don't even know what that is, but it sounds unpleasant. Threads are simple references and In-Reply-To headers, easy to read, and easy for agents to follow. Folders are folders, flags are flags, and what's stored is queryable.

Well, and if you don't already know, here at SemOps we are simply obsessed with lineage, and every object type carries a server state string, which is a jargon-y way of saying you can ask "give me everything that changed since state X" and get just the delta, which may sound unimpressive and it should be, but so many systems don't do that.

So who cares - its just email right? Ah, well yes, but it turns out that email is an incredibly robust and simple messaging system that can do all kinds of interesting tasks with the aid of agents, many of them not even related to email as you might think of it. In addition to being a very simple and flexible messaging system, well understood by humans and training data (a great Semantic Pattern), is also has the awesome property of being YOURS. You own the domain, you control the addresses (pretty much as many aliases as you like on Fastmail), and your ownership is well-governed by DNS-based authentication, the same one that runs the rest of the internet. SMTP and MIME standards mean that any address can send to any other address on any server, and the message format is a standard. Oh, and I think I pay $10 a month for four domains.

I actually use email (and CalDAV calendar) for a lot of "not really email" related agent features becausee often it is much faster, easier, and more sustainable than a lot of the tools that have been designed for this kind of stuff, such as Slack APIs, GitHub Actions, n8n, Zapier/Make, etc. Why? Well, email is by design asynchronous, which means that the message send and the message receive times don't really matter from a protocol perspective - fire and forget. Most modern messaging tools are fundamentally designed to be synchronouos, which means they want an open connection. Almost all are webhook triggered (or equivalent), which means something has to be running and listening to receive. If you don't need immediacy, its extra complexity, risk, and often cost for no benefit. In a future post, I'll share some of my email and calendar uses and post on GitHub.

Decomposition in Action

In SemOps, I've been developing a tool/process that will derive primitives from a commercial system. When it's presentable, I'll open source it on SemOps-ai Let's walk through it:

Recently, I needed to break down "CRM" (Customer Relationship Management) so that I could integrate some agentic processes related to this type of system. The analysis looked at four vendors accross a wide range in cost and complexity: Salesforce, Zoho CRM, Pipedrive, Attio, and here's what I found:

Tier 1: Universal — "This IS CRM"

These 7 primitives appear in every product analyzed. A product without these would not be recognizable as a CRM.

Tier 2: Common (2-3/4) — Scale-Dependent

These primitives appear in most but not all products. Their presence correlates with the size of the target customer and the complexity of their sales process.

Tier 3: Differentiator (1/4) — Philosophy-Dependent

These primitives appear in only one product. They reflect the vendor's unique positioning, not universal CRM needs.

What This Means for You

This is how I think about technology decisions now — and it's a core part of the SemOps framework. Not "which one has more features" but "what are the primitives, and how are they exposed?" When you decompose to that level, vendor comparisons become capability comparisons. Neutral, concrete, and directly relevant to whether your agents can actually use the system, and everything fits into an architecture that solves a domain problem, not a "fit this system" problem.

If you're building with agents — or even just evaluating tools — try the decomposition yourself. Pick any platform you use. Strip the UI. Ask: what are the atomic operations? What protocols does it speak? What does auth look like for a machine, not a human? It doesn't mean you won't choose a feature-rich SaaS solution, but it will mean that you and your agents understand what is it you are paying for.

Footnotes

1. Gmail API Reference ↩

2. Google OAuth2 Token Expiration Behavior ↩

3. JMAP: The JSON Meta Application Protocol — RFC 8620 ↩

4. JMAP for Mail — RFC 8621 ↩

5. Fastmail Developer Documentation ↩