I Let My AI Assistant Read and Reply to My Emails for a Week. Here’s What Actually Happened.

Twinkal — Thu, 23 Jul 2026 09:15:51 +0000

An AI can write a perfect email in seconds. Having a real back-and-forth conversation is much harder.

Sarah runs a salon. She has an AI assistant that emails her customers when a slot opens up.

Last Friday, a customer canceled his booking. The assistant sent an email: "We have an opening tomorrow at 2 PM. Want it?"

The customer replied in a minute: "Yes, book it!"

The assistant never saw that reply. The slot stayed open. The customer never got a confirmation.

This happens more than people realise — not because it's hard to receive email, but because most setups were never wired to close the loop.

Sending is easy. Wiring the whole loop isn't.

To be fair, receiving and parsing email isn't some unsolved problem — providers like SendGrid, Mailgun, and Postmark have offered inbound email parsing for years. Point your domain at them, and they'll hand you the clean message.

But those webhooks only push the message once. There's no inbox to check back later, and no built-in way to link a reply to the right conversation. You have to build that part yourself — and you still can't run any of it on your own servers.

There's a second issue too. AI assistants sometimes send a slightly odd reply — nothing harmful, just a little off. Many managed email providers watch for exactly that pattern, and can suspend an account fast. One strange sentence, and Sarah's whole booking system could go dark with no warning.

What a real AI assistant needs

For an assistant like Sarah's to actually hold a conversation, a few things need to work together:

Replies need to land somewhere the AI can read them
They need to arrive clean, not messy
They need to stay linked to the right conversation
The AI needs to reply back from the same email address
All of it needs to run on infrastructure you control, not three different vendors

This is what we built Reloop for

Reloop puts that whole loop in one place, self-hosted.

When Sarah's customer replied "Yes, book it!", Reloop caught the reply, cleaned it up, and kept it linked to the right conversation. Sarah's assistant read it, checked the calendar, and sent back a confirmation — from the same salon email, so it felt like one normal conversation.

Reloop doesn't write anything itself. It just makes sure a reply doesn't disappear, and that a response can go out without a compliance system flagging it by mistake.

One honest note: right now, Sarah's assistant checks in for new replies rather than getting notified the instant one arrives — established providers like SendGrid already push replies via webhook. A push-based version for Reloop is coming next.

Owning it means watching it

None of this makes an AI assistant automatically safe.

If it ever sends something odd at scale, big providers like Gmail can still block the domain — that risk doesn't go away just because you self-host. What changes is who's responsible for catching it. You decide which addresses it can email, how many it can send per hour, and when a human needs to approve something before it goes out.

That's the real trade. Not "nothing can go wrong" — just "you're the one deciding what's allowed."

The takeaway

The AI writing a good reply was never the hard part. Holding a real, two-way conversation is.

If you're building something like Sarah's assistant, that's the part to get right first.

Check out Reloop on GitHub — it's open source and free to try.

The Hidden Cost of Saving $1000/Month: Our AWS SES Migration Story

Twinkal — Sat, 18 Jul 2026 06:02:03 +0000

4:00 PM on a Friday, a ticket came in from our highest-paying customer:

"None of our staff are receiving your system alerts."

I opened the AWS SES console expecting a quick answer.

Instead: no dashboard, no way to search admin@enterprise-client.com, just a line graph showing 14,000 emails sent, 200 bounced.

No idea which 200, or why.

The cause turned out to be an SPF record that no longer matched our sending setup after a domain migration weeks earlier. Nothing alerted us—we found it by opening bounces one at a time and reading raw headers in the console.

That afternoon is when it clicked:

SES is a sending engine, not a platform.

The cheap price tag doesn't include visibility.

You have to build that yourself.

What SES actually gave us

SES did exactly what it's designed to do.

It accepted mail, attempted delivery, and charged roughly $1 per 10,000 emails.

Against providers like SendGrid or Resend, that can easily look like hundreds of dollars per month saved.

What it didn't give us out of the box:

A way to look up one recipient and see what happened to their message.
Bounce reasons in a form support could use without reading SMTP headers.
Events we could act on without wiring AWS plumbing first.

Bounce and complaint data exists in SES—but it shows up as notifications you route through SNS, often into SQS, then into a Lambda (or similar) before you have anything resembling a searchable delivery log.

Want support to answer:

"Did this email bounce?"

You'll need to build an internal UI on top of that pipeline.

That's real engineering time spent recreating a feature most email products ship by default.

None of this makes SES a bad product.

It makes it a different product than the one we thought we were buying when we optimized for the invoice line.

The middle option isn't free either

Managed providers like SendGrid, Postmark, Loops, or Resend solve the Friday afternoon problem.

You can:

Search a recipient
Open a message
See a bounce reason
Subscribe to webhooks

...without standing up an event bus inside your AWS account.

They also come with two trade-offs that mattered for us:

Pricing that scales with volume—fine early, painful when send volume is part of the product.
Your users' email data lives on someone else's servers—acceptable for many apps, but a real constraint in healthcare, finance, or anywhere with data-residency requirements.

We didn't want "cheaper SES."

We wanted the investigation experience of a managed provider on infrastructure we controlled.

That's what Reloop is built to be.

What that Friday actually taught us

It's tempting to rewrite this story as:

"If only we'd had better monitoring, the SPF drift would never have hurt a customer."

That's not quite true.

And it's not a claim we'll make about Reloop either.

DNS changes are an operations problem.

After a migration, someone has to re-check that:

SPF
DKIM
DMARC

still match.

No platform pages you the week that drifts on its own.

The honest lesson from that Friday was narrower—and more useful.

When delivery fails, you should find out why in a few clicks—not spend an hour digging through AWS consoles.

We needed to:

Search a recipient
Open the message
Read a clear bounce reason
Move on to the DNS fix

SES made the first half of that afternoon expensive.

The SPF mismatch was the root cause.

The missing platform layer is what turned it into a fire drill.

What we built

That gap is why we built Reloop—open-source email infrastructure you can self-host with Docker or Kubernetes, or run with us.

For the SES pain specifically, Reloop gives you:

Delivery logs you can actually use—open a message, see status, bounce classification, and headers without digging through AWS consoles.
Recipient and contact activity—answer "What happened for this address?" without writing a custom lookup service.
HTTP webhooks for sent, delivered, bounced, delayed, and complained—one endpoint instead of SNS → SQS → Lambda.
Domain DNS setup and verification for SPF, DKIM, and DMARC, so after a migration you can quickly re-check the records that broke us.
Your data on your servers when you self-host—the same product shape, without a third-party mailbox for transactional content.

We're not claiming Reloop would have magically prevented that customer's outage.

We're claiming the investigation shouldn't have required raw header archaeology.

Owning the stack shouldn't mean rebuilding a dashboard from scratch.

The trade-off

SES is cheap and opaque until you build the missing pieces.

Managed providers are visible and convenient until volume pricing or data residency gets in the way.

Self-hosting trades the per-email bill for operational ownership.

You're on call for your own email infrastructure.

Queues
DNS
Deliverability
Upgrades

Those become yours.

If that trade fits your team, check out the Reloop GitHub repository setup docs.

If it doesn't, use a managed provider.

The Friday ticket is still a useful warning either way.

Optimize for the invoice, and you may end up paying in engineering hours and customer trust instead.

Go on, send that email.

→ Try Reloop

DEV Community: Twinkal