AI has to earn its place

In Shield, we use a large language model to summarize individual messages in Bundler. We don’t use one to decide whether a sender should reach your inbox. Those decisions start with what each feature needs to accomplish.

Our customers ask us for safer, simpler, more reliable email at a price that works for them. Choosing the technology that delivers that is our responsibility. Adding AI only helps if it makes the product better at something they need. That’s what I mean by “intentional AI,” a term I’ve used in presentations and with our team. We should be able to explain what we’re using AI for and why it fits.

We start with what someone needs to accomplish and work backwards to the technology. AI is one of the materials we can build with. The product has to bring those materials together into an experience that gets the job done. Technology is the raw material. The product is the point.

Two decisions in Shield#

For the inbox decision, the source of the evidence matters. An attacker controls the message they send. They can now generate fresh prose for every target, then adapt each follow-up to the person’s replies. A convincing message is getting cheaper to produce.

Shield is built on a Zero Trust security model. Its Trust Network uses relationship data to decide whether a sender should reach a person. Generating a new message doesn’t generate a history of correspondence with that recipient. That makes the relationship useful evidence even when the prose changes completely.

It has limits. An attacker who compromises a real account can inherit its relationships. Knowing those limits is part of choosing the technology. We want the trust decision to depend on evidence that takes more effort to acquire than another prompt.

Bundler groups lower-priority mail so you can review it when you’re ready. A language model summarizes each message, helping you decide which ones deserve a closer read.

Here, the questions are about the summary: does it accurately represent the message, and does it save you time? You might recognize that AI wrote it. That doesn’t make the feature less useful. A useful summary saves you from opening every message just to find out what it says.

These features need different kinds of evidence and produce different kinds of output. Calling both of them “email security” doesn’t make a language model equally suitable for both.

The constraints are part of the feature#

Cost has stopped experiments we’ve wanted to pursue. A model can produce a promising result in a test and still be too expensive to run at the volume the product handles. That cost has to fit into a service our customers can afford.

We have to make that decision at the level of the individual feature. How much work does it save? How often does it need to run? What happens when its output is wrong? A summary and an inbox admission decision have different answers, even if the same model could attempt both.

The interface has a cost, too. A summary button on a three-line email asks the reader to make a decision that may take longer than reading the message. An assistant panel that covers the work adds another thing to manage. Those features need to earn the space and attention they take.

John Ternus put the underlying idea well in an interview with Wired:

“We never think about shipping a technology. We want to ship amazing products, features, and experiences, and we don’t want our customers to think about what [underlying] technology makes it possible. That’s the way we think about AI.”

I shared that quote with our team. I’d been making the same argument on HELO, mp, our internal podcast, since a 2024 episode about CloudFilter. The feature should make sense to the person using it without a pitch for the technology underneath.

Encryption taught us the same lesson#

With email encryption, the recipient’s experience decides whether the product is useful. The sender wants to get a message to someone securely. If reading it requires installing software, managing keys, or creating another account, the recipient has work to do before the conversation can continue.

Bracket addresses that problem by letting recipients read encrypted mail without installing software or creating an account. The encryption is necessary, but the steps around it determine whether people can use it comfortably.

AI brings us back to the same engineering problem. Getting a technology to perform a task is one part of building a feature. We also have to decide where it belongs in someone’s day, what they need to understand about it, and how they recover when something goes wrong.

People keep the controls#

Agents make those decisions more consequential because they can act on someone’s behalf. The admins and end users we talk to want to understand what happened and why. Delegating work should preserve their ability to inspect it and take over.

The new Security Briefing is in beta, with a release planned for later this month. It gives people a live view of what Shield kept out of their inbox and why, with actions they can take on that mail. That human workflow is the starting point for how we think about agents: a person should be able to review the evidence and make the decision themselves.

An agent could perform some of those actions, but a clear interface alone doesn’t settle how it should behave. We still have to define which actions someone has authorized, when the agent should ask, and how the person can stop further work. Someone delegating a task needs to know what they are agreeing to before the agent starts.

That’s the direction we want to take: let someone hand over a task they understand, within limits they choose. If they decide to do it themselves tomorrow, the product should still be there for them to use.