Gavin Grant

In my last blog post, I explained how to build a 

 that runs on weekdays, searches job boards, ranks the best frontend roles, and emails me a digest. The first time it worked where 

 delivered, my inbox had ten listings with titles, companies, salaries, and apply links. I did it!

Then I clicked the "Apply Here" link and nothing happened. Well, maybe I didn't.

 tool was deliberately simple. The agent compiles a string. Resend sends it. Done.

This was the right first step. It proved the job search loop to search, rank, and email. What the agent wrote was exactly what showed up in my inbox.

But, it wasn't something I'd want to read every morning. Markdown syntax sat there in plain sight: 

. Links were clickable, but led to nowhere. It felt like a data dump, not a digest.

v1 validated the agent. v2 needed to fix the delivery layer.

The obvious upgrade was a regex: scan the string for URLs, wrap them in 

Except it wasn't. Here's what my agent was actually sending:

That last line is Markdown link syntax wrapped in bold markers. The URL regex doesn't know about 

. It sees a URL and keeps going until it hits whitespace — so it happily captures the closing parenthesis and the bold asterisks:

Click that and you're not applying anywhere.

The bug wasn't that email is hard. Resend makes it pretty easy. It was that I was treating the agent's output as plain text when it was actually a lightweight markup dialect. I then ran a URL regex on top of syntax it didn't understand.

This tripped me up at first. Where was I telling the agent to format things this way?

Nowhere, it turns out. My instructions say to "combine results from all sources into a single clean digest." The 

 tool accepts a string described as "the formatted job listings to send." Neither mentions Markdown or HTML.

 framework defines scheduled task messages. It's input to the agent, not instructions for what the agent should output.

The model chose Markdown on its own. LLMs default to Markdown to make output scannable. The mistake was assuming I'd get plain text.

Once I understood that, two paths were obvious.

Ask the agent for HTML. Put it in the instructions: "format the digest as email-friendly HTML." I didn't go this route. Models can produce HTML, but it's inconsistent. It may generate mismatched tags, bad escaping, and output that's harder to read in logs when something breaks. You'd still want sanitization in your tool before sending.

. Keep the agent focused on content. Let the tool own presentation.

I landed on option 2. The agent finds roles, ranks them, writes a readable digest. 

 turns that digest into HTML an email client can render. The tool isn't just a mailer. It's a renderer.

The specific fix for the broken links: parse Markdown link syntax before you try to find URLs in the raw string. A 

 pattern with a non-greedy match stops at the closing 

The pipeline runs in a specific order, and that order is the fix.

1. Parse Markdown links first, before any naive URL matching.

This is the step that actually solves the 

The standard pattern uses a non-greedy URL capture — 

. The parentheses and asterisks after the link are left alone. They get handled later when we parse bold.

If the agent drops a raw URL without Markdown wrapping, it still gets converted. This pass also strips trailing punctuation (

, etc.) that might be left over from nearby Markdown. Crucially, it runs on text where 

 constructs are already gone — replaced by placeholders — so it can't corrupt link syntax it doesn't understand.

User-facing content gets HTML-escaped, including 

 tags we already built are stashed as opaque placeholders (

, etc.) so they don't get double-escaped.

This handles nesting. When the agent writes 

, the link gets stashed first, then the bold wrapper stashes around the link's placeholder. Restoring from highest index to lowest puts the pieces back together in the right order.

One listing line goes from this in the agent's output:

I didn't reach for a Markdown library. For a digest with bold, links, and numbered lists, a small purpose-built converter at the tool boundary was enough.

The final send call wraps it in a styled container:

 keeps the agent's line breaks and indentation. The digest still looks like a list, not a wall of text.

This isn't really an email problem. It's an output-boundary problem.

Any time agent output hits a system with its own format expectations, the same rule applies:

The agent shouldn't need to know Resend exists. 

 shouldn't need to re-prompt the model for better formatting. The boundary between them is where conversion belongs.

When output looks fine in the console but wrong in the inbox, check the delivery layer before you rewrite the prompt.

My agent did its job. It found roles, ranked them, and wrote a digest I could scan in thirty seconds. The bug was one layer down, in a tool that treated Markdown as plain text and then made things worse by linkifying it naively.

The fix wasn't smarter prompting. It was recognizing Markdown link syntax first and only then handling bare URLs, bold, and escaping.

Agents are good at writing; your tools should be good at rendering.

That's the lesson. The agent writes. The tool renders. Put the conversion where it belongs, and your first working email might actually be your first 

Building for the web, with AI