About this talk
In this talk, the speaker, a developer advocate at Cloudflare, argues that email is the best protocol for building agents. He discusses how many current agent interfaces are based on chat, which assumes synchronous interaction, while real work often requires asynchronous processing. The speaker emphasizes that email has features essential for agents, such as identity, context, and the ability to handle multiple data formats. He presents the concept of the email agent runtime and showcases a live demo of building and deploying an email agent using an agent SDK that facilitates the integration of these features. The session highlights the flexibility of the email protocol in creating effective and scalable agents.
Full transcript
[music] >> Testing 1 2 3. Can you all hear me? Good. Awesome. My name is Confidence. I I'm a developer advocate at Cloudflare. And I'd like to make a strange argument today. I'd like to argue that I don't think the best protocol for email is new. I'm sure you've heard of agents to agents or chat or other web interfaces for building agents. I think the best protocol
for email for agents is email. Totally not new. And that's what this talk is going to be about. It's titled The Inbox is the Agent Runtime. And I'm going to be making a case for why I think email is the best protocol for agents. So, we'll look at that. Um we'll look at a really cool agent that's the gear that makes this all possible. And then there's
going to be a live demo here on stage to show you how to build an agent and get it deployed and test it with emails. So, we'll do the whole loop and you'll see that in this talk. But, I'd like us to start by having a conversation of why the interface of an agent matters because really in reality it shapes the runtime of the agent. So, let's
start with that. A quick fire check. Who in the audience have used an agent in the last week or last 3 weeks? If you've used an agent, let me see your hands. Okay, that's quite a number of us. How about those who have built an agent? If you've built an agent like in the last 3 months? Okay, quite a number of hands. That's good. And um this
gives me an idea that you're all familiar with agents, right? I don't have to explain what an agent is or what it does. But, something you know if you've used an agent is that there's a common thread with agents. Agents are usually um guilty of being represented as chat interfaces. There's a UI. There's an empty input box. There's a blinking cursor. And there is the assumption that
a user is there sitting in front of their computer waiting to type to the agent getting the agent to do what he wants to do and waiting for the agent to return with a response. There's always just that assumption. Um it's fine for the most part because it somewhat remem- resembles um interactions we have as humans. Humans, we like to converse. Like when we have these conversations,
it's in form of a chat. You have two people talking to each other. One person saying something. The other person's waiting to hear and respond to what is being said while the first person is waiting to hear what the second person is saying and waiting to respond. So, there's that back and forth being synchronous in the same conversation uh waiting to understand each other. And that's where
the idea of building agents around chat comes from. But, there's a problem with that. Um that's because real work is not usually synchronous. Actually, it follows a workflow model that is asynchronous. So, if you're going to build agents that are actually useful that plug into like useful workflows we do every day, it has to match this model of being So, here are some of the things that
you do on a day-to-day basis. You review proposals. That takes a while. Uh sometimes your manager might ask you to recap a conversation you had with a customer. That takes minutes to hours. You tell your friends to remind you to go watch a movie together in a week's time. That takes a while. You chase people when they don't reply. That takes some time, too. You send a
request, it needs to be um reviewed and approved. That also takes a while. And sometimes you have conversations with customers and you get feedback, you discuss them with a team, you create issues from the conversation. That also take a while. And that goes to show that the nature of work is not naturally synchronous. It's fully async. But something you notice with all of these things we do
every day in our day-to-day jobs is that there's a common trait. They all have identities. There's a way to identify what it is we're currently doing. They also all have context, the information surrounding that task. They have state or variables that change over time. They usually involve people and sometimes more than one person. And sometimes you also have to like do some follow-up to track the progress
of the job being done. If you look at it closely, we actually have a protocol that has all of these built in. And do you want to guess what it is? It's emails. Okay, so let me prove it to you. An agent needs identity. Right? Because you need to be able to talk to an agent and instance of an agent and address it. Emails already have it
built in. Each person or entity in an email system has an email ID and you can talk to that entity directly. An agent needs a way to kick off its event or life cycle. It needs a wake-up event to kick it off. Emails already have that built in. You have an incoming email, you can write a handler for the on email event and start your agent workflow
from that. Agents need durable context, a place to store information, some sort of a memory system. Emails already have this. You have threads. And interesting thing with with threads is that it's a memory chain where you can have forks and it keeps the memory together. It's searchable. Agents need this. Emails already have a built-in. Um agents also need a way to talk back to the outside world
because they're designed to get stuff done and also return some results or some response at the end of it. Emails have a reply channel, a way to talk back to the outside world. Agents need to process multiple data formats uh like audio, text, video. Emails have support for this because not only can you type text in emails, you can also add attachments that are multimedia formats, text,
PDFs, video, images, um that all fits into the agent And another cool feature that agents have is the ability to talk to other agents or to delegate work to sub And guess what? Email has this built-in, too. You can copy someone. You can forward an email to a colleague and that's what agents need. And the last thing here on the slide is agents need human approval, especially
when they're doing something that's potentially dangerous or that can modify sensitive data. They need a human to approve that operation before they move on to the next step. Guess what? Email has this. You can easily reply LGTM or yes and that's your human in the loop approval. So all of this is already built into the email system and what makes it powerful is that it has two
properties every agent needs. The first is email is everywhere. Everyone uses email. Is anyone here who doesn't have an email ID? Anyone? No, we all have an email ID. So email is everywhere. It's used by every company. It's a really solid infrastructure that is already there that we have tons and tons of workflows built on top that agents could leverage without having to write a new protocol.
The second advantage that email has is that it does not require both the sender or the receiver to be online at the same time. So, it's fully async and meets the requirements for building useful agents. And really, this is what an agent runtime needs. An agent runtime that actually scales and solves useful problems needs to have identity. Each agent needs to be individually addressable. It needs to
have memory to remember the context of the conversation. That memory needs to be searchable. You need to be able to pull context when you need it. It needs events to kick off its life cycle, which could be HTTP, email, whatever kind of event you want to build for that system. It needs tools, more importantly, for it to do the work it needs to do. These tools could
be a terminal, a CLI. It could be MCP, some other services. Could be a database or some other REST API. It needs to be able to talk to these services or systems to carry out its action. It also needs to be able to schedule work for the future because not everything needs to happen right now. And sometimes you want things to happen on a reoccurring basis and
you want to set like a crunch schedule for that. Agents need that, too. And lastly, agents need to be durable such that if it's trying to talk to an external system and there's a network failure, it's going to be able to retry that in the future or roll back to a safe state if things go bad. So, these are all the things you need for an agent.
And that is why the agent SDK exists. It's a JavaScript class that has all of these features built in or a TypeScript class if you like TypeScript, that has all of these features built in. And it makes it really easy for you to build agents. So, it gives you see gives you durable state, it gives you event handlers, gives you two calling for you to define what
tools is available to your agent, gives you email replies, and also gives you scheduling. look at some of the features of the agent SDK and more importantly you see it in action because we'll build something live here on stage, we'll get it deployed, and we'll check it out to see how it works in a real application. Another feature the agent SDK has is memory. You have a
memory primitive store arbitrary data and query it in plain English. Or if you prefer, you can actually go low-level and use the very basic um memory primitives like a built-in KB cache or an SQL database or data stored in schedule or cron format to pull data when needed. Um you can also do interesting things like address-based routing. Uh so, for instance, if you have an agent that's
meant to be used in a team setting where that one agent um should have context of its interaction with every team member, you can route all conversations to that one agent if you want. Or you could shard your agent by email ID. So, for example, an email to support@ talks to the support instance. An email to the sales@ talks to the sales instance, and these are two
separate instances with different memory histories, uh different schedules or jobs that to be done. Or you could also um have a complex system where you have um you're able to route to a specific class and an instance of it. Uh this is cool. Uh we will not be talking about that today, but I think it's cool. It's worth taking a look at. Okay, now, so time for
live demo. Let's see how all of this actually works in practice. So, I'm going to uh I'm um switch to my terminal and show you how to build an email agent in I have 16 minutes left. Let's see how quickly we're able to get it done. let's see if I'm able to get my terminal on to be on the screen. Okay, I think you can see my
terminal. Probably make this a lot bigger. So, the first thing we're going to do is start by bootstrapping the app with a template. Um the agent class has a template. But, if you're interested in any of this, uh feel free to just going to go open up my browser. agent.cloud.com View docs. I'll be starting with the template here. So, this is the starter template that has most
of it built in. You have an example of what an agent class looks like, how tools are defined. Um there's also the connection with the UI if you're building um an agent that has a chat interface. But, we'll be taking this and customizing it. So, you go ahead, follow the prompt. Uh you give it you you tell it what you want to name this agent and customize
installation. I already have most of this done. So, I'm just going to CD into the folder agent inbox. So this is where I have my agent. I'm going to open this up in the editor and I'll walk you through what we have here. So the first thing I'm going to show you is where we describe what capabilities this agent has. And because it's an email agent, we
are going to set it up so it's able to send an email and then we'll be able to customize it from there. But because this is an email agent, I need to have a domain set up so I can talk to this agent through the domain. What I want to do right now is quickly go up by a domain so we can set this up with the
agent. So I can go to domains. localoffer.com. Anybody has an idea for a cool domain to buy? Anybody? So let's see agents for the win. Let's see if this is available. Uh, it just went available now. Gone. Or let's do agents Okay. Uh, let's see. Okay, I'll take this one. Okay, so I'm just going to stop sharing my screen here briefly because I will need to provide
my credit card details to to complete this purchase and I don't want you guys seeing my credit card details. I love you all, but I don't want you seeing my Turn this off. End. Ah, it's still on screen. >> So, I'm just uh purchasing the domain agentsinbox.org. I'm almost done. Okay, cool. Now, I can start sharing my screen again. Okay, so I just got the domain and
we'll set this up later. So, let's head back to the code so I can show you how the code actually works to get this up and running. So, I can head back to the source code. First thing here is giving the agent access to the email capability and we do this through bindings. You can see we already also have one online 14 here which is the AI
capability. We're We're telling it, "Hey, you're able to use a large language model for text generation and understanding users input." We're doing the same thing here. We're giving it an email capability so it's able to receive emails and send out emails. Then, the next thing I'm going to do here is show you what we have in the actual server file of this agent. So, I can go
to the SRC and server file. And this is the wake up event of the agent. So, what you're seeing online 418 here is what actually routes emails to the agent when it fires. It's going to receive all all conversations that we're having will route into the same agent. We can chat by email but I'm just going to keep this as is. And right here on line um
248, this is the on email hook. If you take a look at this, what we're simply doing is we're getting the data from the email such as uh the subject and the body of the email. And what we're taking is doing some LLM generation, and giving it access to the tools we have defined in this we are returning the response back in text. So, this is the
This is where we're doing the generation. And then we construct a reply that's in HTML and send that back as a reply to the thread that created that email. Which is going to make sure that the email comes back into the conversation that created it. So, that's a summary of this. I am going to quit my editor now. And I'm going to deploy it. So, I'll do
a quick NPM run deploy. And it's going to take this agent that has the capability of email and get it packaged to be deployed to my account. I'm going to select employee account for And the deploy should be very fast. All right. So, we have this agent deployed. One cool thing with the agent starter is it gives you a UI to work with, so you can test
to see if this agent works. Okay, that's coming up nicely on the screen. And this is the conversation screen that represents what this agent is. So, by default, it has a chat interface, but the whole idea of this is that your agent doesn't have to be chained to a chat interface. It can be multi-modal such that that one agent instance has a child chat output, has an
email output, a video output, or an audio output if that's what you want to build into it. So, I have this I have this agent. I am going to open up my email and send an uh a message to this agent that we have running. Before that, I need to set this up such that my agent is able to receive email events. So, what I'm going to
do is I have this domain with bot. I am going to go to my account, go to email services, email sending. And I'm going to connect the new domain to set it up for email sending. Okay, so that's all I need to do. And the last thing I'm going to do here email routing. I'm also going to add that domain such that I can send email to
it. The first thing we did was set it up such that that domain is able to send emails out, uh which means the agent running on that domain is able to talk to the outside world. Now, I'm setting it up such that we can route emails to that domain. So, let's click on done. I think we have almost everything we need. I'm going to set this to
Okay, so let's create an address. So, the address is going to be agent and the domain is agent inbox. And I'm going to route this to that agent, which is a Cloudflare worker, essentially. And I think this is it. Agent inbox, that's the name of the worker. Okay, there we go. So now let me go open my Gmail. I just have to stop sharing my screen one
more Change. Okay, 1 second while I go open up my Okay, that's um So let's change this. And in task screen Let's go in there. Okay, so this is my inbox. Now let's compose a new email. So this is going to be agent at agents inbox. dot com All right, that's the domain. Let me say Hello. Hi. So let's send an email to the agent. I just
sent an email to the agent. We can view this message. this is the agent we have set up for it. both the actual agent runtime and UI should receive that email I just sent. I'm just going to wait a minute for it to get delivered and show up on the UI. Sorry? The wrong domain. >> Yes. >> Oh, okay. Oh, yeah, you're right. You're right. So, let's
let's try this again. I'm just going to double-check this. Let's see. Okay. So, this is the right Let's copy this. Head back here. So, let's see. Hopefully, I got it right this time. It takes a few seconds for the email to be delivered to the agent. see if that gets delivered in time. Anyway, this is also still failing. I'm just going to show you I have a
uh a backup I have for this. So, I have another agent. This is it. Um email agent. It's a different domain. And I'm just going to have a conversation with this instead. So, this is uh So, hello. How are you? Send this. View message. And this is the agent. This one got the first message we sent earlier. We just sent a new message, so it should receive
it any moment now. Uh it did it did get the message. And it's going to generate a response and also reply to that same email thread. So, it's generated response. And it should send a reply back to this Okay, we have a new message. I can show it. So, this is the exact same message it sent on the thread. And the cool thing about this is all
of the tools and MCP servers and all what not connected to the chat agent. Because this is the exact same agent runtime but decoupled from the UI, it has access to it. So, I can go back and forth. Uh I can tell it, "Hey, uh let's send a Uh remind me to drink water in 30 seconds." Okay. So, I just sent him a message saying, "Remind me
to drink water in in I honestly do not know why that got disconnected. But anyway, the email should come through, which it has. The agent is going to see the response, uh see my input. It's going to call it tool to schedule this task for the future, which is 30 seconds from now. And that should run the tool. Uh but in the meantime, it's going to reply
back to the email thread saying that, "Hey, I got your message. I'm going to set a reminder in 30 seconds." And then, when that tool fires, um we get a pop-up in UI to indicate that that tool has fired. But more importantly, the agent is going to be able to reply to the email thread to let us know that the scheduled reminder actually works and it's able
to call the tool we wanted it to call. It did that through execution. So, we see the pop-up And we have a message here. And that's reminder drink water in 30 seconds. So, I should probably do that Okay, let's go back to the presentation. Okay, let's set this back up. this is the QR code to the full demo. If you'd like to see the source code of
the agent and see how it works like in real life, uh that's the QR code to what the actual agent code is. Um I'll just quickly like to talk through why the agent SDK um is a really good fit for building agents because the reality is that most time when you build agents, your agent is waiting for something to happen, waiting to get some events so that
it can start doing its work. And most of the time it spends waiting, um if you're building in in a container system using sandboxes, most agent sandboxes are actually running containers and they're always on. Um it means you spend time even when your agent isn't doing any useful work. But using the agents um SDK, which is built on workers, yeah, which is built on workers, uh your
only gets built when it has active CPU time. So, when waiting for network or IO, you don't get billed. Your Eden only gets billed when it's running. It's fast, 0 ms startup. It's globally distributed and the developer experience is really good. It's just a JavaScript class. You write your logic. You pull in capabilities when you need to and one command to get it deployed. I hope this
gives you an idea that agent doesn't always have to be a chat It could be headless. It could be connected to the email workflows. And I hope this inspires you to go build really cool email email agents. My name is Confidence. I'm at megaconfident online. And if you'd like to see some of the stuff I'm up to, that's my social links. Thank you so much. I'll see
you all later. Thank you.
