15 posts tagged with "Engineering"

You have a CI pipeline that runs in under four minutes. Unit tests, integration tests, linting, type checks. Everything passes. Deploys go out multiple times a day.

Except for the email tests. Those were disabled three months ago because they kept timing out.

Nobody remembers who disabled them. Nobody has turned them back on. And nobody has noticed the two email bugs that shipped since then.

Your CI pipeline is green. Every email test passes. Coverage looks solid.

Then a user reports they never got their password reset. Another says the welcome email landed in spam. A third says the magic link expired before it arrived.

Your tests said everything was fine. Your tests were wrong.

Most developers think of an inbox as a place where email collects. A container. Something you open, scroll through, and close. That mental model works for humans. It breaks completely for software.

When you're building automated systems that send and receive email, an inbox isn't a container. It's a boundary. A unit of isolation. A primitive that defines who can send, who can receive, what domain the messages come from, and how many messages can go out per day.

The moment you start thinking of inboxes this way, your architecture changes.

Your agent sent a welcome email to a new user. The user says they never got it. Now what?

You open your email provider's dashboard. You see "sent" next to the message. That's it. Sent. No delivery confirmation. No bounce reason. No timestamp for when the receiving server accepted or rejected it. Just "sent."

So you start digging. Server logs. Queue dashboards. Maybe you grep through raw SMTP output looking for a 550 code or a timeout. Thirty minutes later, you find out the email bounced because the recipient's mailbox was full. The information was there the whole time. It was just buried under layers of infrastructure you were never meant to read.

Your agent replied to a customer. The customer sees two separate threads. Nobody knows which one to respond to.

You've built the hard part. The agent reads incoming email, understands intent, generates a reply. Impressive work. Then it sends that reply, and the customer's inbox shows it as a brand new conversation instead of a continuation of the existing one.

The customer is confused. They reply to the wrong thread. Now your agent has two conversations about the same issue with the same person. One has context. The other doesn't.