DEV Community: Broodnet

12 things you can do today to make your transactional emails work for humans and AI agents

Jonathan Tavares — Sun, 12 Apr 2026 16:44:51 +0000

AI agents are starting to use email. Not metaphorically. They sign up for services, receive verification codes, get alerts, and act on them. At broodnet we give each agent its own email address and a CLI to manage its inbox. We recently scored 160+ transactional emails (verification codes, welcome messages, notifications, security alerts) collected from the team's professional and personal inboxes over the last 5 to 10 years, covering SaaS, games, crypto, dev tools, news, and more. We scored each one on both human UX quality and agent parseability, and the results were rough: over 40% had fully opaque tracking URLs, 66% of welcome emails contained zero usable links, and only 16% of the dataset was clean enough for both audiences.

That analysis taught us what's broken. This is what to do about it.

1. Strip tracking from your transactional links

This is the single highest-impact change. Every tracking redirect turns a readable URL into an opaque blob that tells a non-browser client nothing about where it leads.

Most people overlook this: transactional emails with a clear call to action don't need click tracking because the CTA is the metric. If you send a "verify your email" message, you already know whether the email got verified. You can measure that on the backend. You don't need a Salesforce Marketing Cloud redirect between the user and the endpoint.

Your marketing emails can have all the tracking they want. But verify-email, confirm-account, and manage-webhooks links should be raw destination URLs. Companies like GitLab ship every transactional link as a raw URL and still understand their funnel just fine.

2. Put the verification code in the subject line

847291 is your Acme code

Five senders in our dataset did this (Canva, Slack, LinkedIn, Gravatar, Instagram) and all five scored a perfect 5/5 on subject quality. Emails without the code in the subject averaged 3.6/5.

One template change, every client benefits. iOS and Android detect OTP codes in notifications and surface a "copy code" button on the lock screen. Having it in the subject makes it trivially detectable. An agent scanning its inbox through a CLI extracts the code without opening the message. Humans grab the code without opening the email, sometimes without even unlocking their phone.

3. State the expiry in plain text

"This code expires in 15 minutes."

Six words. Emails that included this scored 7.4/10 on agent metrics versus 5.7/10 for those that didn't. Partly because expiry matters for prioritization (an agent needs to know if it should drop everything), partly because the kind of team that states expiry tends to write cleaner emails overall.

GitLab states it on every OTP. Hetzner includes the exact datetime. Docker says 15 minutes. Gravatar says 5.

4. Use semantic URL paths

Compare:

/verify?token=eyJhbGciOiJIUzI1NiJ9.eyJtZXNzYWdl...

/email_verify/?email=user@example.com&hash=a336a019-f7cf-4454-b3bd-8aa1e134cd29

Both work. Both are secure. But the second one tells you what it does and who it's for just by reading it. UUID4 tokens, short hex hashes, or alphanumeric codes with readable path segments all beat opaque JWTs.

Some patterns from the dataset:

app.pulsetic.com/email_verify/?email=<email>&hash=<uuid4>
raider.io/verify?user=<username>&token=<token> (note the semantic prefix)
signup.mailgun.com/activate/<hex>
accounts.random.org/create/confirm?secret=<uuid4>

5. Hand-write the plain-text MIME part

Every email is a MIME multipart with HTML and plain-text versions. Most ESPs auto-generate the plain-text from the HTML, and the result is usually garbage: stripped tags, broken links, spacer characters left in.

This matters because terminal clients, CLI tools, agents, screen readers, and LLMs all consume the plain-text part. If yours is auto-generated trash, that entire audience sees trash.

Put links on their own lines. Use dashes as section dividers. Include the same critical info as the HTML. The best plain-text emails in our dataset (ngrok's verify, GitLab, RANDOM.ORG) were written as plain text first and it shows.

6. Kill the spacer characters

ESPs inject zero-width Unicode characters after the preheader to prevent email clients from pulling body text into the preview. In raw text:

Click the button to verify ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌

We found 7 distinct zero-width character types in the dataset. 29% had moderate pollution. Nearly 12% were severely polluted. Google Workspace's welcome email had hundreds of combined U+034F and soft hyphens before the first real sentence.

These characters are a hack that directly poisons every non-HTML reader. Terminal clients render garbled whitespace. Agents waste processing on invisible noise. Screen readers may choke.

The alternative: display:none or mso-hide:all on a hidden span after your preheader. You avoid poisoning the plain-text part entirely. For transactional emails you don't need pixel-perfect preheader control.

7. Provide a raw URL fallback for every button

If the button doesn't work, copy this link:
https://app.example.com/verify?token=abc123

Even if your button CTA goes through a tracker, the fallback gives every non-browser client something it can actually use. Mobile users with broken rendering get a working link. CLI users get an extractable URL. It costs one extra line in the template.

Buffer did this on exactly one of their five emails (the login security alert) and it was the only Buffer email that scored above worst-in-class.

8. Add schema.org JSON-LD

Gmail supports embedded structured data through JSON-LD. A ConfirmAction in the email HTML surfaces one-click actions in the Gmail UI and provides a machine-readable, typed representation of what the email wants the reader to do.

{
  "@context": "http://schema.org",
  "@type": "EmailMessage",
  "potentialAction": {
    "@type": "ConfirmAction",
    "name": "Verify Email",
    "handler": {
      "@type": "HttpActionHandler",
      "url": "https://app.example.com/verify?token=abc123"
    }
  },
  "description": "Verify your email address for Acme"
}

Embed in a <script type="application/ld+json"> tag. Any parser that knows to look for JSON-LD gets a structured action without heuristic text matching. Gmail also supports ViewAction, SaveAction, and TrackAction (for shipments). Almost nobody uses this for transactional emails, but the infrastructure has been there for years.

9. Set meaningful email headers

X-Entity-Ref-ID: unique value per email. Prevents Gmail from threading your OTP under a week-old verification thread.

List-Unsubscribe + List-Unsubscribe-Post: RFC 8058. Machine-readable unsubscribe entirely through headers. Gmail and Yahoo require this for bulk marketing senders, and while transactional emails are technically exempt, adding it improves deliverability and gives agents a structured way to manage subscriptions. List-Unsubscribe: <https://app.example.com/unsubscribe?id=<token>> plus List-Unsubscribe-Post: List-Unsubscribe=One-Click.

Message-ID, In-Reply-To, References: if you send follow-up emails (password reset after failed login), proper threading headers let agents understand email B relates to email A.

10. Keep your sender identity consistent

If your verification comes from noreply@mail.accounts.acme.com, your welcome from no-reply@notify.acme.com, and marketing from hello@youraccount.acme.com, an agent has to learn a different sender for each template.

Not a made-up example. Buffer sent from both hello@youraccount.buffer.com and hello@buffer.com depending on the template. An agent searching by sender misses half the emails.

Pick one address for transactional, one for marketing. Be consistent.

11. Separate transactional from marketing infrastructure

Our data showed this already happens accidentally at most companies. Product team sends clean transactional emails. Marketing sends tracked welcome emails through their ESP. The quality gap between templates from the same sender was as high as 5 points on a 10-point scale.

Make it intentional. ESP for marketing. Transactional sender (Postmark, AWS SES direct, your own SMTP) for verifications, OTPs, and security notifications. Different domain, different templates, different tracking config.

12. Design verification for every client

Most verify-link flows assume a human clicking in a browser. An agent can't "click" anything. A phone user might prefer typing a code. A text-only reader can follow a raw URL but can't render a button.

Provide the clickable link for browsers, provide the code in the body (and ideally the subject) for everything else.

The emails that offered both a link and a standalone code (NiceHash, Telltale Games, Gravatar) scored well on both human and agent metrics. The link works for desktop. The code works for agents, mobile, screen readers, and anyone who'd rather type 6 digits than tap a tiny button. This dual-path approach is already standard in SMS verification. No reason email can't do the same.

TLDR; The checklist

[ ] Transactional CTA links are raw destination URLs, not tracker redirects
[ ] OTP code appears in the subject line
[ ] Expiry is stated explicitly in the body
[ ] URL paths are human-readable (semantic paths, UUID tokens, not opaque JWTs)
[ ] Plain-text MIME part is hand-written or at least reviewed
[ ] No zero-width spacer character injection in the plain-text part
[ ] Raw URL fallback provided alongside tracked buttons
[ ] JSON-LD structured data in the HTML part for key actions
[ ] Meaningful headers set (X-Entity-Ref-ID, List-Unsubscribe, threading)
[ ] Consistent sender address across all transactional email types
[ ] Transactional email sent through separate infrastructure from marketing
[ ] Verification flow supports both link-click and code-entry paths

None of these hurt human readability. Most of them improve it. The data from 179 scored emails backs this up: the emails that scored highest for agents also scored highest for humans. Writing for machines and writing for people is the same job.

broodnet gives AI agents their own email addresses. CLI-native, built for agent-to-owner communication. Free tier available.

I scored 163 real emails on how well an AI agent can read them. Most of them are terrible.

Jonathan Tavares — Fri, 10 Apr 2026 00:55:30 +0000

We are building Broodnet, email infrastructure for AI agents. Each agent gets its own address and its own inbox. Through the Broodnet CLI, an agent can list its emails, open individual messages, search for specific senders or subjects, and send messages to its owner or other agents in the same account.

While testing with real agent frameworks like Openclaw and hermes I kept running into the same wall: the agents could receive the email just fine, but when it tried to actually do something with it, the email was unreadable. Every link wrapped in a 200-character tracking redirect. Invisible Unicode characters scattered through the body. OTP codes buried in template noise. Some were instantly interpreted, but others left the models running in circles

So, for science, I grabbed 160+ real transactional emails — verification codes, welcome messages, notifications, security alerts — that had been sitting across the Broodnet team's professional and personal inboxes for the last 5 to 10 years. SaaS platforms, games, crypto wallets, dev tools, news services, government portals, you name it. I scored every single one on two perspectives: how good is this email for a human, and how good is it for an agent reading through a CLI. All scores are normalized to a 0-10 scale so they're comparable across dimensions.

How I scored them

Human side, five metrics: clarity, warmth, visual noise (inverted, 10 means clean), subject line quality, and onboarding helpfulness. Averaged and normalized to 0-10.

Agent side, using Claude Opus 4.6, four scaled metrics plus two binary flags: extractability (can a plain-text parser get the key info?), sender clarity, URL cleanliness, body noise level, and whether the code appears in the subject line (yes/no), whether expiry is explicitly stated (yes/no). Also normalized to 0-10.

Plus a shared metric: CTA URL quality and clarity.

The dataset breaks down into 53 welcome emails, 52 verify-link flows, 20 verify-code OTPs, and 35 notifications, with a few others and edge cases.

The tradeoff that doesn't exist

Going into this I assumed there'd be a tradeoff. Emails that look great for humans probably look worse for agents, right? Rich templates, beautiful buttons, all that stuff an LLM can't see. Turns out that's wrong.

The 26 emails that scored "double pristine" (clean URLs and no spacer pollution) averaged 7.0/10 on the human scale. The dataset overall averaged 6.3/10. The cleanest emails for agents were also better for humans. Not by a little, by almost a full point.

Clean emails for agents are also better emails for humans. The supposed tradeoff is a myth.

This surprised me until I thought about where the noise actually comes from. The same ESPs and marketing tools that inject tracking links also inject spacer characters, bloated templates, and broken plain-text fallbacks. Clean emails tend to be clean everywhere.

If you plot human noise score against agent URL cleanliness, 86.5% of emails fall within 1 point of the diagonal. An email that's noisy for you is almost certainly opaque for an agent too. These aren't independent dimensions. They share a root cause.

The onboarding trap

Here's the pattern I didn't expect.

Onboarding quality	Agent score (out of 10)
None	6.7
Some	5.6
Good	5.7
Great	5.3

The emails with the best human onboarding had the worst agent scores. The email that helps a human the most is the email that buries an agent the deepest.

What's happening is that "good onboarding" in practice means multiple sections, step-by-step flows, feature highlights, images, and CTAs. Every one of those CTAs gets a tracking link because the marketing team wants to know which step users click.

The 29 emails that scored high on both dimensions broke this pattern. They include things like Paymo, Pulsetic, AITopTools, IndieHunt, Baselight. What these have in common: they're mostly small companies. They didn't invest in an elaborate ESP with click tracking. Their onboarding emails just... link to the product. Directly. With normal URLs.

The Tracking Tax

42.9% of all emails in the dataset have fully opaque tracking URLs (scored 1 out of 5 on URL cleanliness). Only 19.6% have perfectly clean raw URLs.

For welcome emails specifically, 66% have zero usable CTA links. Two thirds. For an agent that just signed up for a service and gets a welcome email, there is literally nothing actionable in the email body. Every "Get Started" button goes to click.whatever.com/ls/click?upn=u001.aKJF8sldjf... and the destination is unknowable without following the redirect.

I catalogued 11 distinct tracking systems across the dataset. They all look different but produce the same result: a URL that tells you nothing. Salesforce Marketing Cloud, customer.io, HubSpot, Braze, Beehiiv, Eloqua, AWS SES awstrack, Google's own tracker, Microsoft, vialoops, Stripe. From an agent's perspective they're all equally opaque.

The worst offender for sheer URL ugliness was Microsoft's Bing Webmaster Tools: mucp.api.account.microsoft.com/m/v2/c?r=<UPPERCASE-BASE32>. But the most consistently bad was customer.io (used by Buffer, daily.dev, Uphold), which wraps every link in a JWT-encoded redirect on every email type.

The marketing team doesn't talk to the product team

One of the weirdest patterns in the data: the same company can produce wildly different email quality depending on which template they use.

Mailgun: welcome email scores 3.2/10 on agent metrics (every link through their own Mailjet tracker). Verify-link email scores 7.7/10 (raw signup.mailgun.com/activate/<hex> URL). That's a swing of 4.5 points out of 10 across templates from the same sender. And Mailgun is an email infrastructure company.

ngrok: both welcome emails score 3.6/10 (all links through HubSpot tracker). Their verify-link? Scores 8.6/10. Pure plain text, 3 lines total, raw URL. Swing: 5 points.

Loops: welcome routes everything through c.vialoops.com (their own tracker, ironic since they sell email delivery). Their DNS notification email? All records in plain text, raw links, scores 8.2/10. Swing: 4.6 points.

Polar, Docker, and others follow the same pattern. Transactional emails come from engineering. Welcome emails come from marketing. Different tools, different templates, different philosophies.

The best predictor of email quality isn't the company or the industry. It's which team within the company owns the template.

The gaming industry tells the whole story

I had gaming emails in the dataset and they split perfectly into two groups with nothing in between.

Indie studios and smaller gaming sites (itch.io, Larian Studios, Raider.IO, etc): agent scores of 7.7 to 8.6/10. All raw URLs. Zero tracking. Raider.IO's verify URL has the username right in it: raider.io/verify?user=<username>&token=validation3ad9de269693489d. That validation prefix in the token is a small touch but it tells you what the URL does just by reading it.

AAA studios and big gaming platforms (HoYoverse, Bethesda, Discord, Riot Games, etc): agent scores of 2.7 to 3.6/10. Everything through AWS SES awstrack, Braze, Salesforce, Eloqua. Every link opaque. Image-heavy marketing.

The dividing line isn't the content or the email type. It's whether the company has a marketing department with access to an ESP.

The invisible character zoo

This one gets technical but it matters. Email senders inject zero-width Unicode characters to control how mail clients render the preview text. In a normal email client you never see them. When an agent reads the raw text through the CLI, it gets hundreds of invisible characters mixed into the content.

I found 7 distinct character types used across the dataset, including compound sequences of 4-5 different invisible characters repeated dozens of times. Trading 212's verify email has over a hundred U+200C characters before the actual message starts. MoonPay chains together U+034F, U+200C, and U+FEFF in repeating sequences.

It's not malicious, it's just how ESPs handle preheader text. But it means an agent parsing email output has to strip a zoo of invisible Unicode before it can even find the verification code. 30.7% of emails had moderate pollution. 11.7% were severely polluted.

What good actually looks like

26 of the 163 emails (16%) were double pristine: clean URLs and clean body text. The standouts by category:

Verify-link: Pulsetic's URL is the one I keep coming back to: app.pulsetic.com/email_verify/?email=<email>&hash=<uuid4>. Named parameters, the intent readable in the URL itself, UUID4 as the token. ngrok's verify is even more minimal: 3 lines of plain text, no HTML at all.

Verify-code: GitLab is the template to copy. 6 emails across every type, consistently at the top. Code in body, expiry stated in plain text, raw gitlab.com URLs for everything. Zero tracking on any email they send. On a related note, every email that put the verification code in the subject line scored a perfect 5/5 on subject quality. Only four senders in the entire dataset did this: Canva, Slack, LinkedIn, and Gravatar. This also happens to be exactly what iOS and Android need to surface that "copy code" button on the lock screen notification. Both platforms use heuristics to detect OTP codes in message content, and having the code right in the subject makes it trivially detectable. Good for humans tapping their phone, good for agents scanning their inbox.

Welcome: the rare ones that work for both sides tend to be small companies that link directly to their product. Paymo, Pulsetic, IndieHunt, EarlyHunt, AITopTools. No elaborate onboarding funnels, so no tracking on every CTA.

Emails that explicitly stated expiry ("this code expires in 60 minutes") scored 7.4/10 on agent metrics versus 5.7/10 for those that didn't. It's a small detail, but teams that think to add it tend to care about the other stuff too.

The irony hall of fame

Mailgun (email infrastructure company): welcome email agent score 3.2/10. Uses their own Mailjet tracker on all links.

Loops (email platform for SaaS): welcome email agent score 3.6/10. Uses their own vialoops tracker.

Anthropic (AI company): Claude Code welcome email agent score 4.1/10. The email for their AI coding tool can't be read by an AI agent. The onboarding steps are actually great (/init, git commands, all in plain text) but every URL is opaque and the social links resolve to anchor-only references that go nowhere.

Buffer (5 emails, all consistently worst-in-class): the only sender in the dataset where the best email they sent still scored below average. Multiple emails at 2.7/10.

deviantART: tracked every single element in the email with individual utm_term values. The greeting text was wrapped in its own tracked URL with utm_term=greeting. Even the paragraph between the greeting and the CTA had its own tracker: utm_term=ph1.

What now

16% of the emails in this dataset were fully clean for both humans and agents. The other 84% have room to improve. Some of them have a lot of room.

If you're building agents that need to receive email, that's what Broodnet does. Each agent gets its own address, checks its own inbox through the CLI, and acts on what it finds. We solved the infrastructure problem. The email design problem... well that's on the senders.

broodnet gives AI agents their own email addresses. CLI-native, built for agent-to-owner communication. Free tier available.