Break the ceiling of internal productivity with a fast, global filesystem

Hello, 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 for about myself to everyone. So my name is Jacky. 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 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. And what I'm going to talk about today is essentially this journey of building a completely new product, which we call ARG as the code name. 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 fast system 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. And the reason for this is because work is changing. We are drowning in tool 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. It's essentially a small team of five people where we have 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. And when we kind of 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. So 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. 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. So with all that in mind, something actually came into mind. And it's actually really funny, because 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, you know, security. So 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. So 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, how 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 used 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 a lovable experience of building internal apps that also make use of those same files which you've created using the productivity suites. And 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 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 accelerate and build as much as possible. And one of the things that we really found as well while 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, 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. So 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 found. And when you do that, that equates to about $1,200 of extra costs per year per agent, so not even per person. So if you're running 5 or 20 agents, that times that by 20. And then on top of that, there's another format, forms as well, so things like surveys, etc. 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. And you can actually see this in terms of some 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 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, etc., 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, etc., and 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, etc. 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. So using Cloudflare, we actually built a custom mounting that meant we could have up to like 130x faster LLS lookups, etc., which meant your agents ran faster as well. So that was essentially 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, can you build me an internal app on top of that? Can you create me like a custom dashboard? Instead of just always sharing with people like 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 on top of that same file system. It's off-world as well. So you can make sure that people who can access these apps have to be signed in or even like trust. So it's behind a firewall. And yeah, this was all built on top of two kind of core technologies. One was Cloudflare Sandbox. We realized we did something kind of like really probably not by standard, 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. But Cloudflare also has a more kind of like specific approach that they recommend, which is workers for platform, where you can essentially deploy any app such as like Vite, 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 service 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 US as well. So regions like Asia, Australia, et cetera, it was much quicker because services like modal, et cetera, they are mainly based in the US rather than all around the world, whereas Cloudflare Sandbox, Cloudflare, the region is really the whole earth. So yeah. And work is very much changing. So we built this internal productivity platform, one where we have the productivity apps, one where we have the internal app builder. The third part was essentially one really important trend for us, which is essentially loop engineering. 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. So for those who don't know much about loop engineering, here is 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. Good stuff 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 six plus days and just have your computer on, it actually will start to 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. And an important part of actually making sure that you can have loop engineering deployed and done 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 frontend bugs. So automatically whenever we log any frontend bugs, there's a loop for that. We have loops for customer feedback. So 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's a good example of that. So here this is our most cracked engineer. He often jokes to me that, hey, when he retires, he wants to go, you know, buy a farm and just, you know, herd some cattle. So he actually 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 GitHub or VS code, I just see this custom farm that he looks at. And this is where he improves 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. But you know what's cooler than 2D farms is 3D farms. So he ended up taking the same factory where he's, you know, maintaining code 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's a, you know, SEV 0, SEV 1 alert. When you have PRs that are in progress, it shows these crops as well. So 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 is just hyper personalized for you that will make you as productive as possible. And this is what we've seen in our most cracked teammates, most cracked engineers, they're building these custom essentially factories. So 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 off the sound. 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 hyper frames, a lot of different open source frameworks. And he just goes into this factory, he essentially approves, likes and dislike different content, and the factory automatically learns from that, automatically gets better through it. And all of the different kind of like likes and dislike 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 surfaces. So even to find videos of like launches, etc. 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? Especially, 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, etc. are now deciding 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 at 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 hyper scalable as well. Like every time we hit a new traffic, a new milestone, the platform still is super stable. Now, 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, you know, 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.