Designing Products for AI Agents: Resend's AEO and Agent Experience Practices

When AI agents start writing code, calling APIs, and completing end-to-end tasks on behalf of humans, the entity that product design must account for is expanding from "people" to "agents." In a talk, Resend's Zeno Rocha broke this problem down into two adjacent but distinct domains: answer engine optimization (AEO) and agent experience. The former is about getting answer engines to "pick" you; the latter is about whether things go smoothly when an agent actually gets to work.

The boundaries of AEO: getting answer engines to find you

AEO is usually understood as content optimization for answer engines—when users hand a question to an AI assistant rather than a traditional search box, can your docs, API descriptions, and product information be accurately retrieved and presented as the answer? The focus here remains on "content that can be discovered and understood."

Resend's approach is to treat the documentation itself as a product interface to be polished: helping coding agents like Claude Code quickly identify the correct email API from the docs when they need to send an email, rather than repeatedly trial-and-erroring among multiple similar interfaces. In other words, only when AEO is done well can an agent "get it right on the first step."

The difference between AEO and SEO

AEO (answer engine optimization) is often compared with traditional SEO (search engine optimization), but the two have different optimization goals. SEO targets the search engine results page, and its core is getting a webpage to rank highly for keyword queries, after which users click the link and read the site themselves. AEO targets AI assistants that directly generate answers, and its core is getting content retrieved, understood, and cited directly as the answer itself by the model, with users potentially never visiting the original page.

This difference shifts the optimization focus: SEO cares about ranking signals such as titles, backlinks, and keyword density; AEO cares more about semantic clarity, structure, and parseability of content—whether definitions are explicit, whether steps are executable, and whether terminology is consistent. For products that offer APIs, this means how the docs are written and how examples are organized directly affect whether the content can be accurately selected and paraphrased by answer engines.

Agent experience: from being retrieved to being invoked

The key distinction Zeno Rocha points out is this: where AEO ends is exactly where agent experience begins. Answer engines only need to "read," but agents need to "do"—they must understand parameters, complete authentication, initiate calls, and handle returned results and errors. Clear documentation is just the ticket to entry; whether the tool itself is agent-friendly is what determines success or failure.

This means product teams need to re-examine parts that were previously designed only for humans: whether error messages are sufficiently structured, whether example code can be executed directly, and whether the API's default behavior matches agent expectations. Human developers can fill these gaps with experience and searching, but agents often can only rely on the information right in front of them.

What is a coding agent

Claude Code, repeatedly mentioned in the article, belongs to the category of "coding agents": it does more than complete code—after being granted authorization, it can autonomously read files, execute commands, call external APIs, and decide its next action based on returned results. Compared with traditional code assistants, coding agents are characterized by tool-calling capability and multi-turn autonomous decision-making—they plan steps on their own to complete a task and try alternatives after failures.

This means they place higher demands on product interfaces: whether parameter names are self-explanatory, whether the authentication flow is simple, and whether error codes carry clues for fixing issues all affect whether an agent can converge on the correct approach within a limited number of turns. Human developers can search or make experience-based guesses when stuck, while agents rely heavily on the quality of information exposed by the tool itself.

Docs as interface: reducing friction for coding agents

In Resend's practice, documentation is not just a manual for humans but part of the agent's call chain. When tools like Claude Code need to complete the task of "sending an email," they look for the most direct path in the docs. Clear document structure, examples that resemble real calls, and consistent naming all significantly reduce an agent's trial-and-error costs.

This also explains why AEO and agent experience are not separate: the former determines whether an agent can find you, and the latter determines whether the agent can successfully complete the task after finding you. The quality of the connection between the two directly affects a product's adoption rate in agent workflows.

Principles for agent-friendly tool design

Being "agent-friendly" can be translated into several concrete principles in practice. The first is predictability: interface naming, parameter order, and default values should remain consistent so that agents can generalize correct usage from a few examples instead of having to figure out each interface separately. The second is actionable error messages: returning structured error codes and clear remediation hints is more valuable than a vague "request failed," because agents cannot troubleshoot by intuition the way humans do. The third is directly executable examples: code snippets in the docs should ideally be complete and runnable rather than omitting authentication and imports, otherwise agents need extra reasoning to fill in the missing parts, increasing the probability of errors.

These principles overlap with human-centered usability design but are not identical: humans tolerate a certain amount of ambiguity, while agents turn every bit of ambiguity into extra call turns and failure risk.

Implications for product teams

Zeno Rocha's talk points to a design dimension that is taking shape: products need to serve two types of "visitors" at the same time—human users and AI agents. For the former, the interface must be intuitive; for the latter, interfaces, documentation, and error feedback must be stably parseable by machines. Treating these two layers of experience separately is more actionable than talking broadly about being "AI-friendly."

For products that offer APIs or developer tools, AEO and agent experience can become a new set of evaluation metrics: whether answer engines can accurately cite you, and whether agents can complete tasks in the fewest turns. Only by answering these two questions well can a product have real competitiveness in agent-driven usage scenarios.

One-line Summary

Resend proposes that AEO and agent experience are two adjacent domains, and products must serve both humans and agents.

Paragraph Summary

Based on a talk by Resend's Zeno Rocha, the article discusses how, as AI agents begin completing tasks on behalf of humans, the object of product design expands from "people" to "agents." The author breaks the problem into two adjacent but distinct domains: AEO (answer engine optimization) focuses on how answer engines can discover and cite product content, while agent experience focuses on whether calls go smoothly when an agent actually gets to work. Resend's practice is to polish documentation as a product interface so coding agents like Claude Code can quickly identify the correct email API, and it emphasizes details such as structured error messages, executable examples, and consistent naming. The article points out that AEO determines whether an agent can find you, while agent experience determines whether the agent can successfully complete the task; the quality of the connection between the two affects a product's adoption rate in agent workflows, and it suggests treating these two questions as new product evaluation dimensions.