Click. Ship. Done. AI Agents on Cloudflare

♪♪♪ Hey, everyone. It's really nice to be here to talk about how you deploy AI agents on Cloudflare with just one click. So let me tell you that AI is changing at a rapid speed right now. I mean, you might know this because every week something new is happening or a new model is popping up here and there. So it's really fast-paced right now.

To actually understand why this is happening, let's go back in time. AI was actually coined as a term in 1956, which was a very long time ago. It was more than 70 years ago. So after the first chatbot was actually developed, which took more than... which took actually two years to develop. There was also KismetBuild, which also took two years, which is, by the way, a robot, which had emotions basically on what the robot saw. And this was done by having cameras inside the robot and doing facial or basically object recognition in it.

And then AlexNet in 2012 was happening, which was basically a neural network. And then there was AlphaGo, which is basically the very first program who defeated a human in the game Go. And this was insane by the time. Looking at the timeline, you see that this was basically done in 60 years. A lot of other things were happening by this time, but it took quite a long time. I call this era basically pre-generative AI era.

The issue here was that not a lot of people basically had access to this kind of technology. Only people who knew how to program or basically were in this field for science or basically research. And it was basically just for this group of people. But still a lot of amazing things happened back in the days. And a lot of things happened now with the generative AI era, with the launch of GPG-3 in June 2020. In this case, it was still in a private beta and not a lot of people had access to it, only the people who were on the waitlist already had access to it. Soon after, like in November 2021, GPG-3 went GA. But still in this case, you need to know how to program because it was basically only an API which you have access to. In November 2022, this changed with ChatGPD, where nearly everybody had access basically to ChatGPD. In this case, everybody know basically how to code. You just prompt everything in it and ChatGPD tells you how to program. It was not the best by this time, but it already established a lot of, you know, the first steps on how you do programming.

So, the entry step was basically way easier than before. And then it went rapid speed. Entropiq launched the first model in March 2023, Google with Gemini soon after in December 2023. And then Sora was announced in February 2024 by OpenAI, which is basically a program that produces videos based on the user's prompts. And then something interesting happened. There was a thing called agentic loop or iterative loop, which makes the thing for a single pass. I will tell you later what I mean with that. It all started with the launch of MCP in November 2024, maybe a little bit earlier, but around this time.

By then, the agentic skills got announced by Entropiq in October 2025. And then one and a half years later, people say that the MCP was dead. I mean, it's not really dead, it's still there. It's still driving a lot of companies and a lot of programs, actually, but people were actually saying it's dead. And then ever since 2026, everything is about agentic coding or basically agentic with everything, you know. So, looking at the timeline, it's only six years where a lot of things were evolving and a lot of people actually had access now to how to code or how to do certain things. The thing is, me or a lot of other people have no idea how the future might look like, but what we do know is that just one repository in one program can change the future basically forever, right?

Looking at single pass and iterative or agentic loop, what is now the difference between these two? Going by single pass, this is what the name already suggests, single pass. So, you have a user input, most of the time, for example, in the chatbot, it's a user's prompt. This one goes to the LLM. The LLM basically has everything now then inside and then responds with a natural language kind of thing. In an example, let's assume I write into a chatbot, implement and open a pull request for the first issue I have assigned to me. Now, it goes back to the LLM, it processes, it says, sure thing, I can guide you through implementing the issue and opening a pull request. And then there are a couple of follow up questions.

So, you need to basically guide the LLM to go through it. So, again, I'm using a self-hosted Git instance and the implementation should be in JavaScript. Again, LLM digests everything, prompts it back, got it and has a couple of follow up questions. So, this can take quite a while until you have your pull request basically done.

In the Agentic loop, however, this looks a little bit different. So, in this case, it's just more steps in between. You still have to use input. This could be a prompt, an API or whatever. Well, now in this loop, you perceive basically what it was. So, it could be, again, a prompt, API, whatever. The LLM now reasons about what it got and how it could evolve in the future.

Then in the planning step, it actually plans, okay, what could it actually be and what are the best steps to process it through. In the Act step, it's kind of getting interesting because at this step, you can basically manipulate the entire prompt by having tool calls from MTP like a model context protocol. You can also have API requests, database requests, whatever you just manipulate how you want to have it. At the fifth step, at the Observe step, the LLM basically reasons about is it already done, is it not done and just gets the bigger picture.

If it's not done, it goes into the next loop until it is finished and then has the final response. So, if the LLM decides it's done, it gives you the final response. In our example, what we had, if we now give the exact same prompt like implemented open-map-request for the first issue I have assigned to me, it now responds a little bit different. It says, sure thing, but now has three steps. The first step is look at the issues assigned to you, write code to implement the issue. And the third one, the last one is to open up the pull request. So, it's really going through everything based on what you wrote. So, in the loop, the first one, it says look at the issue assigned to you. Done. It has it in the context. The next one says write code to implement the issue. Once the code is written and code is done, it's actually saying, I will open the pull request. And now it's getting smart, because what you want to have as a user is you want to have a pull request opened. So, the LLM would reason about maybe it's the best to also give a button where the user can basically go to the pull request itself, which is amazing. So, in this case, the agentic loop makes everything smaller, or not smaller by meaning of context, but it's making it smaller in terms of how much you have to prompt or to get basically the last result. So, it could potentially take longer because you don't get guided through it step by step, but it reasons on its own, and this makes everything super powerful.

I talked about the model context protocol, or MCP in short, for a very short second. So, for everybody who doesn't know it, this is how an MCP looks like. So, MCP is mostly in the form of an MCP server, and it's nothing else than just a normal API server, but specifically for LLMs. Which means, in this case, if I have an LLM and LLM says, okay, I have a pull call, it will go to the MCP server call it, where you register one of those three things, two or three sorts of prompts. And then once it receives it based on the API, you can do basically whatever you want. So, you can call an API like another API, you can call a database, you can do whatever you would do in a normal API. Once this is done, you have MCP specific output and you return it to LLM. Most of the time, this is in the form of a JSON, but you can do whatever you want, basically what the MCP allows you to do.

How would it now look like if you would self-host your agent? Well, let's assume you're in a Kubernetes cluster, of course you need to host the Kubernetes, you need to maintain the Kubernetes cluster, and so on. But on top of that, you need to have a React application, which runs on Docker. You have an agent, which has basically the agent group, which runs on Docker and on Node.js. You maybe have an LLM, which you self-host, which is super hard to do, because you need a lot of cheap use, you need distributed data. So, most of the time you have this third party somewhere. But on top, you need the MCP on a Docker container and your database.

The problem now with that is that we have no idea how the future might look like. We've already seen within six years, a lot of things changed. The agentic loop is new for just a couple of months. And who knows what the future will bring? Nobody does. I mean, maybe some, but yeah. So, the thing is now, you have to do everything on your own, and there are a lot of moving parts, which might slow you down in some parts. You can do it. Of course, please do it. But it takes a little bit more than it should. So, this can be sped up with Cloudflare workers.

On their website, they actually have an example on how you could deploy your AI agent. In this case, this is inspired by Atlassian, where there's an entry point from an engineer, which has access, basically, an OAuth protocol, and then goes through the entire process until it hits, basically, the website itself. So, what is a Cloudflare worker now? So, this is the least thing you can have deployed on a Cloudflare worker. This is now accessible via a normal URL, and it's basically just an API. In this case, we return a count of 10. Hard-coded, but it's a 10.

Usually, in an API, you want to have more interactive and you have a database. In the world of Cloudflare, this is called a Durable Object. Of course, you can also have a database, but the Durable Object is the most tiny thing you can have to store things. In our Fetch call, we can actually connect to our Durable Object and then have access, basically, to the Durable Object. In our case, we only connect it and don't have, basically, access to the state itself. But we can change that by just saying, we add a function called increment on the Durable Object itself, and then on the Fetch, we just call stop.increment, which gives us access to the return value 10. Again, 10 is not really interactive, but you can make it by just going to the storage itself, say, storage.getCount.

If the storage.getCount is not there yet, we just default to zero, increment it by one, and then store it back into the Durable Object to persist it, and return it again. Which makes, in the Fetch call, we just call it with count await stop.increment, and then return it in the count, which means that every time when we reload, we basically have a new count for basically ever.

So, what has it to do now with AI Agents or Agents itself on Cloudflare? Well, Cloudflare makes it really easy to deploy agents, and they have a lot of helping tools. For example, they have an AI ChatAgent class, which basically extends from an agent, which extends from a server, which extends from a Durable Object. So, everything is built around a Durable Object because you need to have state stored somewhere.

Looking at an example of an AI ChatAgent on a Cloudflare worker, this is how it could look like, where we basically have the entry point, and there's a helper called route agent request, where it says, okay, this one goes to Durable Object or the AI ChatAgent class. And every time a new chat message is received, you will see the helper tool later. Every time when this is received, we can do basically whatever we want. In our case, we make it super minimal by just calling create workers AI, yet another helper function from Cloudflare.

This gives us basically access to every LLM model Cloudflare has access to. Then there is another helper called screen text, where you basically say, this is my model. Those are my messages. Please do something and just prompt me a result. Once this is again done, we just stream it back to the user and we are basically done.

So in this screen text, there are multiple loops inside. You can steer it however you want, but you can also add more parameters to it. For example, tool calls from MCPs. This .MCP is basically another helper from AI ChatAgent, where you connect multiple tools to it. In this case, we just add all the tools we have, which is the reason basically why a lot of people say MCP is that, because you bloat the context with just all your tools you have, which adds descriptions and all the names from the MCP tool calls, which is not always the best case, but you can do it.

So now you have your AI ChatAgent and your normal Cloudflare worker fetch response. What to do with that now? You can basically just deploy it with wrangler deploy with one code. And once this is done, you just deploy it. I show you now how this is actually done. This was one slide too fast, but this is what I actually prepared. So we have now basically a browser application, which has basically access to the Cloudflare worker itself. This is basically deployed on Cloudflare.

And this one has now access to MCP server, which we can decide whatever we want. And we also have our self-hosted MCP server, which has access to GitHub, to the GitHub API. The Cloudflare worker itself has, as we saw before, access to a pool of LLMs from Cloudflare itself. How it looks like is we have two wrangler configs, which is basically the main entry point for Cloudflare. And this is then deployed to Cloudflare.

So the app looks like this. We have now a sign-in to our app itself. Once we are signed in, we basically have access to our AI chatbot. We can do whatever AI agent what we want to have. I showcased the AI chat agent because it's better to visualize. On the top right, we can connect to any MCP server we want, in our case to Sentry itself, which is the proofs here and inspect issue events tool course. And now we also have access to another MCP itself.

There are two predefined prompts, which just say please summarize Cloudflare agents. And you can already see that it's getting some tool calls from our GitHub MCP, which is our self-hosted one. In the MCP case, we have basically our source MCP TS, which is stored in here. The main entry point is always the export default, which is OAuth protected. And once we are actually protected, the API handler is the one which is getting card, where we create an MCP handler, which is from a normal, from basically from Cloudflare itself. And you can call whatever you want in it. In our case, we have a new MCP server.

So how it looks like now in code. Here we have now our two Rangle configs. In the MCP case, we have basically our source MCP TS, which is stored in here. The main entry point is always the export default, which is OAuth protected. And once we are actually protected, the API handler is the one which is getting card, where we create an MCP handler, which is from a normal, from basically from Cloudflare itself. And you can call whatever you want in it. In our case, we have a new MCP server and on this one, we just registered different tools.

For example, who am I? So if I type in, please tell me who I am on GitHub, it will call this tool call because it reasons about this might be the best fit. In our case, we had to get repo infocore, where our LLM decided that this might be the best fit for the prompt I gave. And once this one hit, it's again whatever you want in a normal API. So we fetch another API. In this case, it's the API from GitHub and return an MCP or a LLM suited response. And this is again a JSON format.

So once this is done, all we are going to do is deploy the MCP with this one command. We just say wrangler deploy-c wrangler.mcp.jsonc because usually you don't have to define that. But since we have multiple wrangler configs, we just define it. While this one is deploying now, we can look at our agent. We said going back to our, when we go back to our example, we just looked at this one. And now we are looking at the second Cloudflare config, which is basically the agent.

In here we just say we have EIA bindings. We have assets, which is basically our React application. And we also have, we have the main entry point of the agent itself, which is basically our backend. So we have our app and our agent. And again, Cloudflare is getting or giving you a lot of helper tools to make a chatbot or an agent possible. So you can call an agent, in our case, it's the chat agent. And we also have a use chat agent, where we just add the agent, have send messages and messages itself available from this hook. So use chat agent comes basically from at Cloudflare AI chat, slash React because we are in the React application.

Once we actually call send message, and this is what we actually have done, we send now the text message directly back to the agent. And once this one is done, we have the on chat message function, which is predefined from Cloudflare itself, from the AI chat agent helper. And here we can do whatever we want. We have the MCP tool core. We have the pool of LLM models from Cloudflare itself. And then we just tell the model itself, or in our case, this is the screen text that we have this model. We have a couple of system prompts where we just say, okay, what, how do you want to behave? We have the messages which came in automatically with send message, with our tool course, we say how many times it should iterate, and then we just return it.

Once we return it, the messages are getting updated and we are basically having everything. And there's also the status on basically what is basically the status right now, submitted streaming, reading error. This is basically now the loop in our chat agent. So once this is done and you basically have done everything, you have just 112 lines of code for the app itself. And you have 160 lines of code for the AI chat agent, where here there's the entry point. Again, this is another helper from Cloudflare itself. And we just ship it with this one command called wrangler deploy, and you're always up to date. Theoretically, you don't have to do this, so you don't have to press wrangler deploy, you can also connect your GitHub repository into it and everything is done automatically based on the branch you set.