Hey folks, 

June in Florida means the kind of heat that makes you question your life choices, so I've been spending a lot of it indoors reading. This week I fell down a rabbit hole about Tony Krueger, the Microsoft engineer who invented the red and green squiggles under misspelled words. It got me thinking about a pattern that comes up a lot in this work: the features users love most are built on engineering choices they'll never think twice about.

If you built anything on the OpenAI Assistants API, you have fewer than 60 days before every call to /v1/assistants, /v1/threads, and /v1/runs  stops working entirely. Not degrades, fails.

The migration target is the Responses API plus the Conversations API, and it's worth knowing upfront that this isn't a simple endpoint swap. The architecture is fundamentally different — Assistants become Prompts, Threads become Conversations, Runs become Responses — and OpenAI is not providing an automated migration tool for existing Thread history. For a simple integration, you're looking at one to four engineering weeks. For a multi-tenant system with stored conversation history and complex tool orchestration, plan for more.

The good news is the Responses API is genuinely better: synchronous by default, native MCP tool calling, and significantly improved cache utilization. If you've been putting this off, we really suggest you start blocking some calendar time, yesterday.

Everyone's racing to build AI agents that generate and send emails. While the demos look compelling, there's a layer most of that conversation skips over entirely: if the HTML output is bad, none of the work matters.

Email rendering is genuinely hard in a way that AI can't account for. Outlook's Windows client still renders through Word's engine rather than a browser, media queries only work in about 40% of clients, and dark mode varies wildly with no signs of converging. Agents don't inherently know how to navigate any of that well. They can generate valid HTML that looks great in a Chrome preview, but they don't know that it'll break in the clients your users actually open.

If you're building with Beefree SDK, this is work we're already handling. Our rendering team tracks client changes continuously, runs cross-client testing, and keeps HTML output current as the ecosystem shifts. When Outlook quietly changes something, we catch it and push an update before it becomes your problem.

If you're looking to build a design agent that creates emails that *actually* look great everywhere, our MCP Server is how you connect your agent to the Beefree SDK — and our rendering knowledge.

Check it out →

While we're on the topic of what lives below the surface, our Content Services API does a lot more than most realize.

The template-export-pdf-example sample code showcases one of the most useful outputs: exporting a user's email design directly to PDF, with control over page size, orientation, and quality settings. It includes real-time progress tracking, export history with success/failure status, and a hook that keeps export state management clean and reusable.

For extra credit: the same API that powers PDF export also handles image export, plain text conversion, and automatic landing page generation from an email design, so if your users have ever asked for a way to download, archive, or repurpose their designs across channels, you can easily make this possible.

That is it for this month. If you take anything from this email, hopefully it's one quiet-yet-impactful win for your roadmap.

Until next month.

Samantha Troilo

Beefree SDK Team

P.S. I couldn't leave you without this link: Raymond Chen at The Old New Thing published a tribute to Tony Krueger, the engineer behind Word's red and green squiggles. He made spell check non-blocking and immediate before that was a standard UX pattern, and most people who've benefited from it have never heard his name. Worth three minutes.