00:00:00So, Cloudflow are working on something called Artifacts, a distributed file system that's
00:00:05Git compatible and is built for agents first, and lets you programmatically create, fork
00:00:10or delete thousands of repos, no matter how small or big they are, for things like parallel
00:00:15PR reviews, automated refactoring of large code bases and per session agent workspaces.
00:00:20But with this being built on top of durable objects, does that mean you have to use JavaScript
00:00:25and you can't have access to a shell command to run Git?
00:00:28Hit subscribe and let's find out!
00:00:33GitHub was built for humans, not for agents, meaning they don't need any of the social
00:00:37aspects, so followers start discussions, but agents are very good at Git, it's in their
00:00:42training data.
00:00:43So, Cloudflare have built a basic Git implementation in Zig, compiled it to Wasm and put it on a
00:00:49durable object to act as a Git server.
00:00:52Meanwhile the client itself can be anything you want, so a worker using isomorphic Git
00:00:57inside a worker or using the Git protocol and even the HTTP client so that you can connect
00:01:03to it for things that don't use JavaScript.
00:01:05Now unfortunately at the time of recording, I don't have access to Artifacts since it's
00:01:10in private beta, but there is a lot of documentation on it, which means I can create a demo with
00:01:15a code from that documentation and maybe when it's released in public beta you can check
00:01:19if my code actually works.
00:01:20So what we're going to do is build a tool that takes a list of tasks for a specific
00:01:24repo and runs all of these tasks in parallel by forking the repo multiple times and running
00:01:29each task on its own artifact in a Cloud repo on a durable object.
00:01:34Let's see how this works.
00:01:35Now I've started off by following the documentation for Artifacts in getting started for workers,
00:01:39so I use this command and this text here after this command is just the name of the project
00:01:44and can be anything.
00:01:45So I followed all of these steps, which ends up giving me this basic worker code.
00:01:49And workers for Artifacts are slightly more performant than using the REST API since they
00:01:53make less round trips.
00:01:55Then after that you'll need to add the Artifacts bindings to your wrangle.jsonc or toml file,
00:02:00then rerun the types.
00:02:02Now the documentation here focuses on creating a new repo, so it uses the Artifacts binding
00:02:07with the create method and a repo name.
00:02:09It creates the name, which gives it the token and the remote.
00:02:13So the remote is the location of the artifact and the token or auth token as well as needed
00:02:17to give you access to it.
00:02:18And of course you can use the git protocol using the remote and the token to interact
00:02:22with your artifact.
00:02:23But we're going to do something different.
00:02:25Instead of creating a brand new repo in an Artifacts durable object, we're first going
00:02:29to check if one exists called baseline.
00:02:31Then if it doesn't exist, what we're going to do is import a git repo and then I've
00:02:35given it the name of baseline and then returned that value here.
00:02:39And of course, if you check out the API documentation for the workers binding, you'll see more
00:02:43params that can be added to the import method.
00:02:45But then after we've returned the existing repo, then we can do some very cool things
00:02:49with it.
00:02:50So here are the tasks that I'd like to do to the repo, and of course I've hard coded
00:02:53them, but these can be added in an input or some kind of UI.
00:02:56And here inside the worker default export, I've got the anthropic SDK as well as my
00:03:00baseline repo.
00:03:02And I'm going to loop through all the tasks and over here, I'm forking the repo with
00:03:06this name.
00:03:07Then we have this function, which I'll go through later, but this runs the task inside
00:03:10the forked repo and gets the agent to make the change while returning the agent's summary.
00:03:15So the last thing the agent said, and then after each for loop, I'm returning this
00:03:19information.
00:03:20I'm going to do the name of the task, the name of the fork, the remote and the token
00:03:23so that we can access it whenever we want to see if the change is good and the summary
00:03:27of what was done.
00:03:28So right now the workers bindings doesn't give you the ability to pull, commit and push.
00:03:33So in my code, I've had to do that with isomorphic FET and then use an in-memory storage system
00:03:38to store the changes temporarily.
00:03:39So back in the agent code, we're creating our file system in memory, and then we have
00:03:43a system prompt that tells the agent to make the relevant changes and then commit their
00:03:47code.
00:03:48So we're going to clone the forked repo using the remote that has been provided as well as
00:03:51the token.
00:03:52And then we define some tools, so read, write and commit.
00:03:55Here we select the model and give our model a system prompt, and then we pass the task
00:03:59as a user message.
00:04:00And the rest of the code is your standard agentic loop.
00:04:02So if there's a tool call, stop reasoning and run the tool call, in our case, read, write
00:04:07or commit, which also happens to push the code after committing.
00:04:10And the benefit of having an artifact is that all this code will exist in the durable object,
00:04:14stored in the SQLite database of the object, and if the durable object goes down, the information
00:04:20can be retrieved from the SQLite database at any point if it comes back up.
00:04:23And then below here, we continue the model's reasoning after the tool call before returning
00:04:27the latest message from the model.
00:04:29Now I know it's very difficult to visualise all of this happening without me being able
00:04:32to run the code, but hopefully you can kind of see what can be done with artefacts and
00:04:37their full potential.
00:04:38Imagine if you could have a UI to see all of the changes that are happening in these artefacts
00:04:42and you can communicate with individual agents or a single orchestrator agent to make changes
00:04:46to the different repos.
00:04:48Speaking of an orchestrator agent, we could have a single worker that could orchestrate
00:04:52all of these changes happening and merge them to the main repo after a reviewer agent has
00:04:56been through the code.
00:04:57We can even combine artefacts with dynamic workers so that agents can run the code they've
00:05:02changed to see if it works.
00:05:03And if it's not JavaScript code, then we can use Cloudflare sandboxes to run any language
00:05:07we want and even run shell commands.
00:05:09Not to mention there's the Cloudflare browser option that runs a puppeteer browser for the
00:05:13model to look at and see if the code it implemented is correct if it's a front-end change.
00:05:18I've honestly had a lot of fun thinking about the possibilities of artefacts, even though
00:05:21I can't yet run them.
00:05:22But one thing I have noticed is that there's no git diff command.
00:05:25It's not exposed in the worker bindings API or in isomorphic git.
00:05:30So maybe the only way to do a git diff is through the git protocol, or they might add it in the
00:05:35future.
00:05:36Anyway, right now, if you want to do it without using the git protocol, I guess you could use
00:05:40isomorphic git using git log to find the git tree to go through and walk down the tree to
00:05:45compare the differences.
00:05:46Regardless, I think this is a very cool release from Cloudflare.
00:05:50And even though there are other file system tools like S3 files, ZeroFS and JuiceFS that
00:05:55already exists, I don't think these options are git compatible, which is a very cool feature
00:05:59and more agent friendly.
00:06:01Speaking of S3, if you've ever wanted to run it locally on your machine, then check
00:06:05out this video by Josh that tells you exactly how to do that.