这段对话记录了两位创始人之间关于开发者体验 (DX) 和“代理体验” (AX) 的深入探讨，尤其是在电子邮件服务领域。他们讨论了从以人为中心的应用程序开发到未来以代理（AI 实体）为主要参与者的转变，这需要从根本上重新思考产品设计和可访问性。 对话开始于这样一个观察：现有的基础设施、数据库和通信工具大多是为人类构建和使用的。然而，人工智能代理的日益普及标志着一种范式转变，要求开发者创建专门为代理交互量身定制的体验。讨论强调，开发者不仅需要为人类构建服务，还需要为代理构建服务。 开发者最初的反应是这非常困难，因为他们不仅需要为人类构建服务，现在还需要为代理构建体验。创始人指出，AX 不是要取代 DX，而是要增强它。就像 DX 是所有小细节的总和一样，AX 也是这些细节的总和。创始人在此讨论中提到的一个最重要的例子就是启用发送电子邮件工具的入门过程。在代理开始发送电子邮件之前，它必须先加入平台或系统。 讨论转向了电子邮件领域内的具体挑战和机遇。它提出了这样的问题：代理是否会有自己的电子邮件地址，代表人类处理电子邮件，或者需要不同的编程服务使用说明。他们用自动驾驶汽车在现有道路基础设施上行驶进行类比，暗示代理最初将利用现有的 API、SDK 和协议，而不是要求彻底改革。 演讲者深入研究了电子邮件格式的细微差别，强调了纯文本相对于 HTML 对于代理处理的意外价值。纯文本电子邮件有更多有用的标记，更容易解析，而且成本更低，因为它是一种不太复杂的格式。他们还讨论了代理环境中 API 密钥和权限授予的演变，思考是将它们视为个人用户还是服务帐户。 对话强调了在正确的时间向正确的人发送正确消息的必要性。他们提到了 AI 驱动的 SDR 工具的作用，指出基于 LinkedIn 消息的简单定制是不够的。不同电子邮件客户端之间存在的渲染挑战也得到了认可，强调了保持一致显示的重要性。 讨论进入了准专业级应用程序领域，以及人工智能驱动的内容创建的日益普及。发言人指出，LLM 能够执行各种任务，重要的是要考虑的不仅仅是生成代码。使用代码只是“顿悟时刻”，现在开发者可以利用一个新的行动号召。这种事情很重要，因为它能够定制任何给定环境中正在发生的事情。创始人讨论了如何从电子邮件的想法开始，并在几秒钟内获得电子邮件模板。 他们探讨了如何授权消费者和开发者创建集成电子邮件体验的潜在用例，并提到了“文本到应用程序”工具的趋势及其对重新定义开发者角色的影响。创始人提到他们构建了一个名为 new email 的工具，它可以帮助人们在几秒钟内从一个想法变为电子邮件模板。这不仅可以帮助需要学习编码的开发者，还可以帮助营销人员、设计师、产品经理等。 然后，他们开始讨论 React email 作为一个开源项目，以及他们对电子邮件构建方式进行现代化的目标。关键是将 TypeScript、React 和 Teyawen 集成到这个行业中，以帮助它向前发展并不断创新。借助 LLM，这可以缩短非技术用户的创造性循环，并使他们能够构建更好的东西。 作为 Uber 的一名设计师，他们提到他们已经使用 Cursor 或 V0 或任何工具构建了所有原型，并且他们甚至不再打开 Figma。他们所需要做的就是专注于文案，并思考角度。总的来说，他们强调缩短了创意循环，因为它让那些最有创造力的人能够专注于创意方面，并更快地完成它们。 讨论探讨了生成式体验的本质，质疑它们是否符合代理工作流程。他们将代理定义为执行以完成特定任务的一组工具，可能涉及多个步骤。 最后，他们探讨了 MCP（元聊天协议）作为人工智能代理通信的新兴标准。他们讨论了 MCP 有望简化与各种 API 的交互，使代理能够跨不同平台访问和操作数据。 他们设想的未来是人工智能代理执行大部分在线操作，因此需要转变产品设计，优先考虑代理的可访问性、快速入门和安全权限授予。记录代理活动对于理解和减轻潜在问题至关重要。对话强调了开发者需要调整他们的工具集和工作流程，以适应这种新的现实。

This transcript features a conversation between two founders deeply invested in developer experience (DX) and exploring the evolving landscape of "agent experience" (AX), particularly in the context of email services. They discuss the shift from human-centric application development to a future where agents (AI entities) are the primary actors, requiring a fundamental rethink of product design and accessibility. The conversation begins with the observation that much of the existing infrastructure, databases, and communication tools are built for and used by humans. However, the increasing prevalence of AI agents signals a paradigm shift, demanding that developers create experiences tailored to agent interaction. The discussion emphasizes that developers need to build not only services for humans, but also for agents. The initial reaction from developers is that it is very difficult because not only do they need to build services for humans, they now need to build experiences for agents. The founders note that AX is not about replacing DX but augmenting it. Just like DX is the sum of all the little details, AX is also the sum of those same details. One of the biggest examples the founders mention in this discussion is the ability to onboard onto the tool to enable the sending of email. Before an agent can begin to send email, it has to onboard onto the platform or system. The discussion shifts to the specific challenges and opportunities within the email domain. It questions whether agents will have their own email addresses, processing emails on behalf of humans, or require different instructions for programmatic service utilization. They use the analogy of autonomous cars navigating existing road infrastructure, suggesting that agents will initially leverage existing APIs, SDKs, and protocols rather than demanding a complete overhaul. The speakers delve into the nuances of email formats, highlighting the unexpected value of plain text over HTML for agent processing. Plain text email has more useful tokens, is easier to parse, and costs less because it is a less complex format. Also they discuss the evolution of API keys and permissioning in the context of agents, pondering whether to treat them as individual users or service accounts. The conversation highlights the need to send the right message to the right person at the right time. They touch on the role of AI-powered SDR tools, noting that simple customization based on LinkedIn messages is insufficient. Rendering challenges across different email clients are also acknowledged, emphasizing the importance of consistent display. The discussion moves to the realm of prosumer applications and the growing accessibility of AI-driven content creation. The speaker notes that LLMs are able to perform a variety of tasks and it is important to think about it more than just generating code. Using code is just the aha moment and now there is a new call to action that developers can utilize. This type of thing is important because it enables the ability to customize what is happening in any given setting. The founders discussed how you can start with an idea for an email and in second, you can have the email template. They explore potential use cases for empowering both consumers and developers to create email-integrated experiences, referencing the trend of "text-to-app" tools and their impact on redefining what a developer is. The founder mentioned they built this tool called new email that really helps like to go from zero from like an idea to an email template in seconds. This can enable not only developers that needed how to code, but marketers, designers, product managers, etc. They then get into a discussion surrounding React email as an open source project, and their goal on modernizing the way emails are built. It's all about integrating TypeScript, React, and Teyawen into this industry to help it go forward and continue to innovate. With LLMs, this can shorten the creative loop for those non-technical users and enable them to build better things. As a designer at Uber, they mentioned that they've built all of the prototypes using cursor or V0 or whatever the tools are, and they don't even open Figma anymore. All they need to do is focus on the copy and thinking about the angle. In general, they emphasize that it shortens the creative loop because it enables those who are the most creative to focus on creative aspects and do it faster. The discussion explores the nature of generative experiences, questioning whether they qualify as agentic workflows. They define an agent as a set of tools executing to accomplish a specific task, potentially involving multiple steps. Finally, they explore MCP (Meta Chat Protocol) as an emerging standard for AI agent communication. They discuss the potential of MCP to streamline interactions with various APIs, enabling agents to access and manipulate data across different platforms. The future they envision is one where AI agents conduct the majority of online actions, necessitating a shift in product design to prioritize agent accessibility, rapid onboarding, and secure permissioning. Recording agent activities becomes crucial for understanding and mitigating potential issues. The conversation underscores the need for developers to adapt their toolsets and workflows to embrace this new reality.