0:03Hello, everyone. It's great to meet you all. I realized when I kind of put this presentation together, I probably should have made the title a bit more engaging. Maybe add some words like AI or agents in there, because a lot of it is actually about that. But yeah, I forgot to change the title. But anyways, here we are. So just a quick introduction about myself to everyone. So my name is Jackie. I'm one of the co-founders. co-CEO of a company called Relevance AI. So what we do here at Relevance AI is we're building essentially agents very much designed for, you know, running massive amounts of tasks, specifically in the go-to-market space. So things like sales, marketing, we work with companies like Databricks, Uber, Canva, and help them really scale out their whole go-to-market engine.

0:53And what I'm going to talk about today is essentially... this journey of building a completely new product, which we call ARG as the codename. We're actually going to rebrand that very soon, but at the moment it's called ARG, and it's already something that you can try out as well. So why did I, you know, you'll find out soon why did I mention the word fastism so much. But to add a bit of context, though, work is very much changing. And we can see this through some of the statistics. So if you go on Cloudflare radar at the moment, I think this number is actually higher, but agentic traffic is making up more and more percentage of the internet. So your website, honestly, about 60% is probably being visited by agents.

1:40And the reason for this is because work is changing. We are drowning in tool sprawl, outdated SaaS that never scaled, retrofitted to barely work with agents. But a lot of the most productive team, they need to be building for them and their AI agents, and it's more crucial than ever because work is changing. When you're building for companies, you're not just building for the employees, the people, you're actually building for their AI agents as well. So with that in mind, we had this question internally. What does the space for humans and agents to work at scale together look like? what is it actually going to look like? So we decided to actually start what we call ARG internally.

2:27It's essentially a small team of five people where we have wanted to pretty much come up with the answer to this question. And what does ARG mean? It means art. It means agent research group. It also is kind of like function ARG for the developers in the room. And also because it's a three-letter... domain that I've owned for quite a while, so I wanted to make use of it.

2:54when we kind of, you know, dug into this deeper and deeper, we realized it really had to start with files. If we really wanted to change productivity, if we really wanted to change how work is being done, it had to start with files. Because if you think about it, a lot of things are files. You know, an app, like a website, et cetera, is actually just a collection of files. Things like HTML, TSX, et cetera. A database is actually also a collection of files. I don't know if anyone remembers the Hadoop days, HDFS. That literally meant Hadoop file system. So it was a whole bunch of files, and that was one of the best ways you can actually process large amounts of data. And even then, if you think about it, your PPT, your docs, they are also just files.

3:42So a lot of things are files. So we realized when we wanted to make people more productive, it had to start with the files. And whilst we, you know, had that in mind, we realized we wanted to build, you know, this file system, right? Something that can really change productivity. We had to define the architecture, the foundation of it. And we needed to choose something that was really proven at scale, that was incredibly easy to deploy. We, especially now... you know, because agents can deploy and create apps so quickly, we wanted to make sure that the environments that we're going to build it in, the infrastructure that we're going to build it on top of, it was very easy to stand up on standalone, and it had to be serverless, and it had to be able to withstand enterprise needs, things like zero trust, et cetera.

4:33So with all that in mind, something actually came into mind, and it's actually really funny I got introduced to Cloudflare in a very, very strange way. So before Cloudflare, before, you know, finding out about Cloudflare, I only mainly knew about Cloudflare through two things. One was DNS, and second was workers. Workers didn't really apply to me because I was more of a Python developer of machine learning background, and workers was mainly like TypeScript, et cetera. But then they invited me to this small kind of meeting, gathering thing. where they started introducing things like sandboxes, things like gateway, et cetera. And I realized, wow, Cloudflare has really expanded to something beyond just DNS, beyond just security.

5:20So that's why when we decided to kind of build this new product, build this new project, we decided to actually see that there was one platform that met all five, and it was Cloudflare. So we got to building, and about in three months, with five people, we actually managed to build the full stack. So we managed to build a mobile app, a desktop app, a CLI, an SDK, and along with that, a whole bunch of different features on this product, this platform. And this was all just with five people. And in fact, to be honest, it was actually more closer to three and a half engineers because I was a half engineer and also someone else was actually more of a go-to-market engineer, so they didn't actually work on the... core code that much, but with just five people, we were able to ship so much and I would love to show you guys what we were able to ship and why did we choose Cloudflare for some of the choices.

6:17So we ended up building essentially a workspace, a file system for teams and agents at scale. One where both your teams and agents can use simultaneously. And this will go through how each, you know, we built each part, but it's essentially three different parts. So one, it's the productivity suite. So if you think about your Google Docs, your Loom, your Notion, your Figma, your Asana, Dropbox, et cetera, we essentially use AI to essentially rebuild as much of this with as much quality and taste as possible, all within the one application. And then on top of that, you can also build internal apps. So you can just have like a lovable experience of building internal apps that also make use of those same files which you've created using the productivity suites.

7:09And then finally, loops, which is really similar to workflow automation, you can build that all within the same platform as well. And this is all powered by one single file system. So it's the same version, attributed file system on every single surface. We were able to take this file system and build internal... apps, build the productivity suite, build the loops, and plus way, way more as well that's on our roadmap. And this was really, really good. By deciding to build this all in top of one file system, it made every single feature much easier to build, because when we made sure that the file system was durable, secure, and, you know, audited, every single surface on top got it for free. So that was a really important architectural choice for us that allowed us to really excel accelerate and build as much as possible.

7:59And this, one of the things that we really found as well whilst building the file system for both humans and agents was that you really wanted to make sure that it was built as good for agents as possible. And when we were able to do that, it meant that agents could remember more, similar to memory. It meant that it could actually know deeper because more and more people were storing files into this same file system. them almost acting like a brain. And it meant you could find anything, you could create things better, you could distribute them faster, and everything could also be looped as well. And one of the really interesting findings as we built this, we realized, hey, not only did we need to make sure that we need to build a scalable file system, we actually could look at some of the formats of these files and it could actually make agents more efficient.

8:51So one really fun example is, did you know that if you're still using Google Docs and using the Google Docs MCP, you are spending about 21x more tokens than if you just use MDX? So that's one of the findings we've found. And when you do that, that equates to about $1,200 of costs, extra costs, per year, per agent. So not even per person. So if you're running five or 20 agents, that is, you know, times that by 20. And then on top of that, there's another format, forms as well, so things like surveys, et cetera. If you're using something like Qualtrics or even SurveyMonkey, you're looking at at least 9x. So just by making your agents use a much better, much more well -designed file format to actually do a lot of this work, you essentially get better output for the agents because they use less context, but also save you more money, which is really, really interesting.

9:49And you can actually see this in terms of some of the examples from our evals where we see that the leaner formats also meant better results. So these were testing essentially on some of the smallest models possible. We really wanted to make sure that, hey, if you wanted to create, you know, creative assets, you wanted to create really interesting documents, what can we do with pretty much the smallest models as possible? So we were trying on things like DeepSeek, Luna, et cetera. And we saw that by using a leaner file format, you could get pretty much way better performance and for cheaper as well. And on top of that, when we kind of built this good file system, we realized, hey, we could get things like collaboration for free, version history for free, fine-grained sharing, comments, et cetera.

10:39And this was all thanks to building on top of Cloudflare. So we chose two key... technology when we were building this out. One was Cloudflare R2, and the other one was Cloudflare Durable Objects. So Durable Objects gave us a lot of that real-time collaboration, gave us a lot of that essentially durability so that you can have multiple people editing the same files without it essentially breaking or without having version conflicts, et cetera. On top of that, we also chose Cloudflare R2 because there's free egress, but also... it was actually the right thing for us when it came to flexibility. We realized when using file systems for agents, there was a lot of kind of latency issues with the standard S3FS.

11:25So using Cloudflare, we actually built a custom mounting that meant we could have up to like 130X faster LS lookups, et cetera, which meant your agents ran faster as well. So that was essentially the... kind of the file system and building of the internal productivity. But then on top of that, it's really interesting. There's this whole trend in our customers where they wanted to use those same files to essentially build internal apps. So just to give you an example, one of our financial services company plus our own internal finance, they love using CSVs, right? They love using spreadsheets. So they would actually create a spreadsheet in that same file system. and then say to the agent, hey, can you build me an internal app on top of that?

12:14Can you create me like a custom dashboard? Instead of just always sharing with people like, you know, the spreadsheet, now you can share these custom internal dashboards. So this is what we were able to build was essentially an internal app builder. It's really powerful. It's already, you know, on top of that same file system. It's auth-walled as well. So you can make sure that people who can access these apps have to... signed in or even, like, zero trust, so it's behind a firewall. And, yeah, this was all built on top of two kind of, you know, core technologies. One was Cloudflare Sandbox. We realized, we did something kind of, like, you know, really probably not bystanded, but we realized when you kind of get the agents to build the apps in the sandbox that you give it, you can also just persist the sandbox for as long as possible, open up a tunnel, and now it's an application.

13:10But they also have, Cloudflare also has a more kind of like, you know, specific approach that they recommend, which is workers for platform, where you can essentially deploy any apps, such as like Veech, React, et cetera, just in one click. That was actually really, really nice. It meant that for companies like us, who are selling to other customers, we can actually just white label this whole deployment. as well. So these were two really, really powerful technologies that we really leveraged. And one thing I really wanted to call out about Cloudflare Sandbox, we did a lot of benchmarks against things like modal, et cetera. Cloudflare Sandbox was way quicker. And one of the reasons why it was way quicker wasn't just that the cold boot, et cetera, was quicker, but the latency was quicker in regions outside of the U .S. as well.

13:55So regions like Asia, Australia. et cetera, it was much quicker because services like Moto, et cetera, they are mainly based in the U.S. rather than, like, you know, all around the world, whereas Cloudflare Sandbox, Cloudflare, the region is really, you know, the whole earth. So, yeah. And work is very much changing. So, you know, we built this internal productivity platform, one where we, you know, have the productivity apps, one where we have the internal app builder. So, the third part is the third part is the third part. was essentially one really important trend for us, which is essentially loop engineering. So I'm trying to update my code. And our most cracked teams are essentially using these same two things to essentially build custom productivity tools, custom loops, to essentially hyper-personalize their setup so that they can ship as much as possible.

14:56So for those who don't know, much about loop engineering. Here is like a quick deep dive into it. Essentially, instead of you having to manually prompt the agent over and over again, loop engineering is pretty much where you're actually designing the system that actually prompts the agent. A good start to this, by the way, what I found that really helps people understand this is if you just design a prompt that says work on this for, you know, six plus days and just have your computer on, it actually will start to loop. be more loop engineering-like as well. But this is a really, really important concept because when you have loop engineering set up properly, you pretty much go from manually having to create features or manually having to come up with ideas to now the agents automatically surfacing you ideas and surfacing you bug fixes, et cetera, automatically.

15:49And an important part of actually making sure that you can have loop engineering... deployed and done, you know, effectively is actually making sure that you're building the factory. So thinking of how you actually can build the factory and building the line that does the work rather than, you know, you being the operator all the time. So instead of you having to maintain it all the time, you are making sure that, hey, every now once in a while, you're maintaining essentially the context, the code base, so that it's outputting as good as possible. But one of the important things about this is that it compounds. So the more loops you have, the better your code base gets, the better your output gets. A good example of this is we have loops for things like front -end bugs. So automatically, whenever we log any front -end bugs, there's a loop for that. We have loops for customer feedback.

16:38So whenever there's a customer feedback that comes through about the product, it automatically comes up with PRs for that. And all of those things compound, because every time a loop is automatically taking care of one part of the product surface area, another part will actually get better as well. So, yeah. And this is the fun part of the presentation. Everything else was, you know, me just setting up the context, but here are some examples of how our team is actually building custom factories to essentially improve their productivity. So here is a good example of that. So here, this is our most cracked engineer. often jokes to me that, hey, when he retires, he wants to go buy a farm and just herd some cattles.

17:26So now what he's done is he just built a dashboard, essentially a factory, where all of his PRs, all of his code is actually produced by this factory, produced by agents on this farm. So he built this custom dashboard. So every time I walk past him, instead of seeing or VS Code, I just see this custom farm that he looks at. And this is where he approves all the PRs. This is where he actually tells it, hey, here are some of the ideas I have. In fact, all the bugs also surface here. And it's fun, because he also has all the different team members on this farm. So another day, he was like, you know, 2D farms are cool.

18:12But you know what's cooler than 2D farms? Is that. 3D farms. So he ended up taking the same factory where he's, you know, maintaining code in and actually turning this into 3D. So it's like a full -on farm. You can go around. You can go into the pub. When you go into the pub, it's usually when there is a, you know, SEV0, SEV1 alert. When you have PRs that are in progress, it shows these crops. as well. And this is where I really see the future of work going. Instead of always using kind of like off-the-shelf productivity tools or software to make yourself more productive or do work through, you can actually now create custom software, custom tools that will, that is just hyper-personalized for you, that will make you as productive as possible.

19:06And this is what we've seen in our most cracked teammates, our most cracked engineers. they're building these custom, essentially, factories.

19:16So, and now, it's not just for engineering. So, those two examples are engineering factories, where instead of looking at GitHub all the time, you're looking at, essentially, farms. We also see people like... I'll turn this down. But in this case, we also see go-to-market. So, this is our go-to-market engineer. Instead of working in, like, Salesforce or HubSpot, he actually just built an internal app that automatically generates content for him. It's utilizing things like hyperframes, a lot of different open-source frameworks, and he just goes into this factory, he essentially approves, likes and dislikes different content, and the factory automatically learns from that, automatically gets better through it, and all of the different kind of like...

20:07likes and dislikes, automatically determines how the core loop prompt gets improved. And it's quite funny. I've noticed, like, when you have this capability of building custom tools and you're also writing your same documentation in the same place, you end up being productive even on the smaller So even to find videos of, like, launches, et cetera, instead of, like, even typing into a search bar, I actually built an internal app that looks through all of those different files and shows me, hey, this is where all the different videos are as well. And that's where really the future is. Instead of always having to kind of like, you know, manually do these things, you can actually build these custom apps, these custom internal tools that will make you as productive as possible. And just in conclusion, I have about 40 seconds, but why did we, you know, after all this experience of building with Cloudflare, why do we continue using it?

21:03Especially, you know, we launched about a month ago. Now we have over 10 enterprises starting to use it. It was actually four and a half last week. I got notified today that now it's 10. So companies like Databricks, Uber, Canva, et cetera, now they're starting to use it. And why we continue to use Cloudflare is because it continues to be durable. It continues to be a high uptime. It continues to be serverless, so it's easy to maintain. But also, most importantly, the team... that Cloudflare just ships so quickly. The support is amazing. I jokingly tell our internal teams, I'm pretty sure just, you know, we are costing Cloudflare more than we're paying them, and it's hyperscalable as well. Like, every time we hit a new traffic, a new milestone, the platform still is super stable.

21:51Now, I do have one wish list. These are all the different services we've used, but I do wish for Cloudflare Postgres so I can, you know, have everything. in that one Cloudflare platform. But anyways, thank you so much. Now, you know, this was three months. Now we've shipped it. It is actually the most popular and stickiest product we've got. And so I strongly consider, strongly suggest, if you are building a product, a new product or a new project, consider building it on Cloudflare. It has really allowed us to ship as fast as possible. So yeah, thank you so much.