How Resend designs API and documentation for AI agents to choose on their own

Why does an AI agent recommend Resend for sending email instead of the option already integrated into the rest of the developer's stack, like Cloudflare Email? That question kicked off an 86-minute conversation between the host of the Latent Space podcast and Zeno Rocha, co-founder and CEO of Resend, published on November 10, 2026. The throughline is what the two call the frontier between AEO (answer engine optimization) and agent experience: optimizing for the agent to answer correctly is one thing, designing the tool for the agent to use it correctly is another.

The trigger for the topic was an AEO study cited in the conversation: among 102 email API recommendations the researchers were able to extract, Claude Code chose Resend first in 64 of them. SendGrid came up first seven times, but appeared as an alternative in 55 of the recommendations. A more recent and more comprehensive study, also mentioned in the conversation, showed a more contested picture, with Postmark ahead for most models. The point that remains: if a developer asks the agent to implement email sending and accepts the patch on the first try, hardly anyone is going to try the second option afterward.

The wedge began before agents existed

Resend's advantage with agents wasn't born from an AEO effort. It was born from a documentation problem solved years earlier. While building the sending API, the team kept getting the same complaint from developers: putting together the email template and getting it to render correctly was painful. The answer was React Email, a library for building templates with React components.

Resend documented how to send these templates even through other providers, including SendGrid. In practice, when a developer decided to switch providers, part of their code already came from a Resend project. That's distribution in the most literal sense: the product enters the repository before it becomes a purchase decision. An agent that scans repositories and documentation finds that trail naturally.

The pricing page is also an agent interface

Resend's pricing page has a slider: the person drags it to the sending volume they need and reads the price. An agent doesn't drag sliders. Rocha says that simply adding .md to the page's URL makes the agent receive a text table it can read in a single request, instead of trying to interpret an interactive component rendered in JavaScript.

It's a simple test any product team can run on its own page: open the pricing table and ask a model whether it can answer a customer's question using only that content. If the answer depends on visual interaction, the agent will likely guess or make up a number.

80 tools or two?

Resend's MCP server grew from about 20 tools at launch to more than 80 at the time of recording. Rocha's logic is to replicate in chat what the user does in the dashboard: sending an email makes for a good demo, but inviting a teammate, checking usage, and managing billing are also tasks that happen in the dashboard and, in his view, should be available through an agent.

This design contrasts with Code Mode, Cloudflare's server that exposes the entire API through just two tools, search() and execute(): the agent looks up what it needs and executes code against the API instead of choosing among dozens of pre-defined functions. These are two different bets on how a model navigates API surface, and the conversation doesn't settle which one wins; it only makes clear that there's no single right way to design an MCP server today.

Rocha describes a habit worth copying: opening the tool calls collected from their own sessions to see what the agent actually did. In one of these inspections, the result of a call was too large to fit in the context, and reducing the number of tools wouldn't have fixed anything, because the problem was the size of the response, not the number of options. It's a cheap experiment: take a call the team runs every day, expand the full result, and measure how much of it the model actually uses before deciding to cut a tool or cut the payload.

What happens after "send"

Getting the agent to choose the right API solves only the first half of the problem; the other half is delivering the email to the inbox. Rocha uses click tracking as an example: when the provider rewrites links through a tracking domain shared across customers, it only takes one customer using that domain for phishing to get it blocked, tanking deliverability for everyone who shares that same domain.

That's why Resend introduced custom tracking domains, isolating reputation risk per customer. The company also keeps a free plan even knowing it attracts spammers, a decision Rocha ties to what the conversation calls the company's $3 million security commitment: moderating abuse is expensive, but closing the free entry door also has a cost, in adoption and in reach among new developers.

What remains open

Resend had 4.3 million users and 120,000 paying customers at the time of recording, according to Rocha, who says he discovered Warner Bros. Discovery as a customer by combing through short .com domains in the customer base on a Saturday. It's an anecdote that shows the size of the base, but it doesn't substitute for agent-specific adoption data: the conversation doesn't say, for example, how much of the 120,000 paying accounts came from a flow started by an AI agent rather than a traditional search.

For anyone designing their own API or MCP server, the practical takeaway left by the conversation is less about AEO and more about ergonomics: documentation in a format the machine reads on the first try (.md instead of rendered HTML), tools that mirror real tasks instead of mirroring endpoints, and the habit of inspecting what the agent actually did in a session before redesigning the API surface. None of these decisions depend on showing up in a ranking study; they depend on opening the log and looking.