Git Wasn't Built for Agents, So Mesa Rebuilt the File System | Agents Hour

The model of Git is that you basically

download the entire repository onto your

machine before you can start doing work.

But that's not really how agents work.

The agent might just be looking at parts

of a repository, and it might want to do

minutes or [music] even seconds of work

at a time. And so, if you've got to pay

like a 30-second or 1-minute penalty to

download a Git repository to do like a

Git clone before your agent can start

working, you're wasting a whole bunch of

cycles.

>> Ben's co-founder and CTO of Mesa. Mesa's

a versioned file system built for AI

agents. They integrate with major AI

frameworks and sandbox infra. It works

with Mostra today, kind of working on a

first-class Mostra workspace integration

as well. And I'm originally Ben, I saw

your co-founder launch tweet, and it

just went pretty viral. It did It did

really well. And so, that's how I first

heard about Mesa. So, love to learn a

little bit more, but maybe if Did I miss

anything from the intro? What else can

you tell us about Mesa?

>> No, that was perfect. Well, I'm stoked

to be honest. Good to see you guys.

Yeah, we're I'm a co-founder of a

company called Mesa. We build a

versioned file system for AI agents. We

play really nicely with a lot of AI

frameworks, including Mostra. And so,

yeah, I'm stoked to talk more about it.

>> For those of you that have been

watching, you've probably seen a lot of

different types of commentary and and

really like thought pieces around how

agents should be using file systems, why

a specific file system for agents is

important. We've seen a few others

reimagine how how this works. But can

you tell me a little bit about how does

Mesa work? Why is, you know, having a

specific file system for agents

important? How does it, you know, under

the hood? Tell us a little bit how how

it all functions.

>> I think the first observation that we

started with is that file systems have

been a really important primitive of

computing for at least 50 years now. And

basically every operating system that

you use is built around the idea that

you've got this file system, which has

got folders and files. And it's a It's a

very kind of a simple notion that lets

you represent like a lot of different

data types. And most programs today are

built around the idea that they've got

access to some kind of a file system.

And so, I think that's one of the

reasons why most of the harnesses that

you see today work really well with bash

and with the file system. And uh more

and more the AI model providers, whether

that's Anthropic or OpenAI, have been

RL'ing their models to work really well

with bash and with the file system. So,

I think that's kind of like the first

observation that we started with. It

turns out like file systems are just a

really good primitive and they work

really well with AI agents. But some of

the limitations that we noticed were

that more and more people were running

their AI agents in environments where

you didn't necessarily have access to

the kind of persistent file system that

you would expect. So, on your laptop

you've got basically a hard drive and

that hard drive is what um you kind of

persist all of your data. But when

you're running an agent in the cloud,

often times you're running that in like

a multi-tenant back end or you might be

running that in a sandbox. And so, you

don't have access to the same kind of

persistent disk every time your agent

spins up. And suddenly if you've got a

bunch of infinite agents running, you've

got to worry about kind of like

permissioning. So, which agent has got

access to which data? And if you've got

multiple parallel agents running on the

same data, then you might have to think

about versioning. So, how do you make

sure that it's I've got two agents that

are both working on the same project

that they don't override one another and

they're not constantly kind of

conflicting. These are some of the

problems that we set out to solve when

we built Mesa. And uh and so,

essentially what we've built is

something that we think of as being a

little bit like GitHub for all of

knowledge work. We basically got like a

version control system that allows you

to branch so you can do drafts and

approvals, but it feels just like a

folder that you can connect to any

application.

>> Which is dope.

>> Nice. So, so you're saying it's like

completely version controlled

essentially, but it's like a file

system. All the agents can write to it,

read from it with a permissioning model

of course, and that way you can just

basically build a base of knowledge and

it it all lives in a accessible place.

>> Exactly.

>> I've seen other people try to use Git

and other types of version control

systems for this. Is there reasons why

traditional Git doesn't you know, fit

the bill? Like what are the reasons why

it's not as good? And what are some of

the benefits of this approach versus

trying to use trying trying your agents

just to read and write from Git?

>> Yeah, there're a few problems with Git.

I mean, I think first and foremost, Git

was just not designed for agents. And

so, the kind of like API surface is

complex. But, I think there are a number

of other limitations that Git's got. So,

one of them is that Git doesn't work

very well with large files. You know,

you may have experienced this if you'd

ever tried to check in like an image or

something like that to a Git repository.

Git will tell you, "I actually can't

accept large files." Um because it

wasn't built to to work with those. And

so, there are kind of like happy side

band solutions that people use for this.

One of the other problems with Git is

that conflicts are not first class. So,

if you ever um have had to deal with a

conflict in Git, one thing that you

realize is that it can be a real pain in

the butt if you've got to like, let's

say, do a rebase through a whole bunch

of commits. You as a human have got to

look at every one of those commits.

You've got to resolve all of those

locally. And only then can you make

progress in your branch. And then maybe

the most important thing that we've seen

lately is that the kind of model of Git

is that you basically download the

entire repository onto your machine

before you can start doing work. But,

that's not really how agents work. So,

if, for example, you're running an agent

in a multi-tenant back end or in a

sandbox, the agent might just be looking

at parts of a repository. And it might

want to do like, you know, minutes or

even seconds of work at a time. And so,

if you've got to pay like a 30-second or

1-minute penalty to download a Git

repository to do like a Git clone before

your agent can start working, you're

wasting a whole bunch of cycles.

>> But, y'all y'all sync back to those

version control systems, right? Like, do

you handle the workload on your end and

then you sync to the GitHubs, GitLabs,

or whatever? Is that how Cuz everyone's

using these other products like How how

does that work?

>> Yeah, so that's one of the choices that

you've got. So, Mesa kind of uh

kind of owns the storage layer for you.

So, if you've got a product that doesn't

need to be synced back to GitHub, you

can just use Mesa as your storage layer.

So, in other words, you can create

repositories which are, you know,

basically the same as repositories in

GitHub in the sense that they're just

version directories. You can create

those in Mesa. You can use Mesa on its

own. But, let's say you've got a coding

agent use case. And your customers, you

know, want your branches synced back to

GitHub so that they can they can see PRs

on GitHub. Um we've got kind of a

background sync engine that'll sync to

GitHub.

>> That's awesome, dude. You've evolved

into this idea. I would love to

understand the story of like before

Mesa, there was something else and like

how did that pivot happen?

>> Yeah, there there is a little bit of a

backstory here. The backstory is that

when we started Mesa, my co-founder and

I started the company with the idea that

GitHub was not built for the kind of

coming age of agents. And there were a

bunch of different respects in which we

thought this was true. You know, the

first thing that I think a lot of people

have come to believe recently is that

GitHub wasn't engineered for scale and

so you can see GitHub's having all sorts

of trouble with with uptime these days.

But I think like also we could see the

GitHub UI was not really designed for

the kind of super high volume agent

driven workflows that people are dealing

with now. So, you know, it's not very

good at rendering really large pull

requests. It's got more AI features

built in now, but they're not very good.

Like GitHub's code reviewer has got a

bunch of problems. It doesn't help you

to to like really understand a large

diff quickly. And so, we tried a couple

of different angles of attack on this

problem where we said, "Well, if you

were going to rethink GitHub from the

ground up, like what would be the best

place to start?" And so, actually like

early on in the company we built a

replacement UI that used GitHub's back

end. And then we went and built a whole

bunch of agents that sat on top of

GitHub. So, we built a code review agent

for example. Um it had a decent amount

of of traction building that, but like

in the process of building those

products, one of the things that we

discovered is that actually like the

GitHub back end was thing that was

holding us back the most. And even when

we tried to go and build code review

agents, the fact that we were forced to

use the Git model before the fact that

we were forced to sit on top of Git as

the kind of version control primitive

created a bunch of difficulties for us.

And so, we realized like maybe there was

even a bigger opportunity in rethinking

what that storage layer looked like and,

you know, even going down to the level

of like rethinking whether we should be

using Git as the underlying kind of

version control mechanism.

>> Yeah, dude. I remember, you know, we've

had many beers talking about this. Yeah,

it's so cool to see the evolution uh cuz

I think this is the right problem to

solve in the grand scheme of destroying

Git, like I think this is the one that

both resonates with agents, but also

resonates with a bunch of people who are

now experiencing where GitHub is failing

us. And I don't think people will truly

realize it until their agents realize

it, cuz we're in that era where agents

are kind of leading humans in these

technological things. So, I mean, super

sick, and I'm I'm really glad that we

have integration.

Um I heard you have a demo.

>> I have got a demo. Hopefully, this gives

you a sense of why we think Mesa is an

important primitive and what kinds of

things you can do with Mesa that you

can't typically do. So, I built a little

demo app here the other day, and what I

want to show you is kind of like an AI

financial analyst, what I call the CFO

command center. So, maybe you're

building an agent for your finance team

or for your CFO, and your CFO's got some

big data room with a whole bunch of

documents. And those documents might be

a combination of like PDFs, so these

could be like contracts, they could be

customer case studies, a whole bunch of

different things. And you probably also

got some like Word docs, you got some

Excel docs, and you've got some CSVs.

And so, these are the kinds of

workspaces or data rooms that like

non-technical people on your team are

dealing with every day.

And so, you might want to give them an

agent to help them do their job. And so,

like the first thing that I want to show

you is just the way that you can connect

a typical agent to a repository, or in

other words, like just a version folder

in Mesa.

So, we've all, you know, probably seen

these kind of chat UIs, and so, I've got

a CSV in here that's like a list of

kind of imaginary vendor contracts.

And so, you know, I might want to ask my

agent where we can

optimize our vendor spend. And you can

see as my agent works through this

problem, it's just going to be using

Bash. And it's, you know, simply making

calls like ls to list the results of a

of a directory, like a like cat to see

the contents of a file. It can use all

of the kind of standard Bash commands.

And what's cool is when you're using

Mesa, you could either mount Mesa as

like a POSIX file system in a sandbox.

And so, in other words, it's like a

fully native directory, or you can run

Mesa in process. And in this case, I'm

running Mesa in process, and so you've

kind of got a choice depending on

whether or not you need a full sandbox

environment. But I I think we've all

seen flows like this. This is relatively

straightforward, and you can do this

with a lot of different backing file

systems. I think where Mesa gets really

interesting is with some of our version

control primitives. Uh you know, one

thing that we've heard from a lot of

people is that more and more people want

to run agents in parallel. And so, there

are different reasons you might want to

do this. One reason is that you've got

agents working on different tasks, and

you want them but those tasks might

involve the same documents. Another

reason is that you might want to explore

a bunch of different paths and then

accept one and discard some of the

others. And so, I'll just show you a

really simple version of this. So, you

might have noticed that in these mock

vendor contracts, we had our SOC 2

compliance done with Delve. Uh and so,

we realized uh we actually need to

replace Delve with Vanta. And so, I'm

going to ask my agent to go ahead and do

that replacement. But in this case,

instead of just launching one agent, I'm

going to launch three parallel agents to

all work on the same problem. And we'll

see which one gives us the best result.

And so, under the hood, what's going on

is Mesa has got Git-like branching

primitives. And so, in essence, we're

going to kind of fork our file system

three different ways. Each agent's going

to get its own isolated copy of the file

system, and it's going to, you know, be

free to like modify documents, look at

whatever documents it wants to, and of

course, it can use standard bash

commands. And again, in this case, this

is running all in process, but if you

wanted to, you could mount Mesa in a

sandbox. Um

I think my three different agents here

are just different Claude models. So,

I've got Haiku, Sonnet, and Opus. And

when these guys finish working, I'll be

able to see the kind of before and

after. So, I'll see the diff.

And you can imagine rendering this in in

a richer way. In this case, I just went

for kind of a simple line level diff,

but it would be pretty easy to render

kind of like, you know, a rich table if

I wanted to and show the differences.

And we can see like the cheaper, faster

agent, it gave me a diff. It did replace

Delve with Vanta, but it looks like it

it made some kind of formatting changes

that maybe I didn't want.

And then

I Sonnet agent got a pretty good diff,

and so did my office agent. And so it

looks like these two guys ended up with

about the same thing. And when I'm done

and I'm happy with with the changes that

my agents made, I can now basically go

from draft mode into kind of like an

approved final state and do a merge much

the same way that I would do in Git. And

if I go ahead and refresh my vendor

contracts, you can see that we've

replaced Dell with Vanta. And so this is

kind of an example of of some of the

flows that you can get into with Mesa

that you wouldn't be able to do with a

traditional file system.

>> That's really cool. Now for like a

coding agent example, let's say I'm not

using Git anymore. I'm not using GitHub,

I'm not using Git, I'm just using Mesa.

I have my code base in Mesa and let's

say me, my and my co-workers are all

tackling maybe the same file but

different parts of it in our own work

and stuff. And our agents are writing

but they're branching before they write.

How does this like merge process work in

this world where like we do want to

merge all of our changes but like is

there this whole rebase concept or like,

you know, how does how's that going on?

>> Yeah, so I I think you can you can think

of Mesa's versioning model as being like

very similar to Git's in the sense that

you've got like kind of chain. So in

other words, you've got like snapshots

of your of your folder that we build up

over time and we're storing it in an

efficient way. But at any time, you

know, you don't have to have just a

linear history. You can do these kind of

like forks. Every one of those forks is

like a kind of a valid candidate but

probably you know, you've got kind of

like one main line set of changes that

represents the canonical state of of

your documents. And so you know, the

workflow is very similar to what you

might do with Git and GitHub. I think

what's really interesting and different

here is that, you know, first of all,

Mesa's optimized for programmatic use.

And so if you want to like not just use

your own coding agents but build an

agentic application, Mesa's really well

set up to do that. The second thing

that's really interesting is that you

don't have to do a full clone before you

mount a Mesa repository. So in other

words, we kind of have this lazy

materialization. So, you could imagine

you might have like a really large

workspace or a massive mono repo that

could take a really long time to clone.

I was working on the master repo today

and I mean like the master repo is

pretty significant. So, even that takes

maybe 30 seconds or a minute to clone.

>> Yeah.

>> And so, if you imagine an agent like

your Code Rabbit agent reviewing pull

requests in Mastra, you know, probably

it's got to spend before it reviews a

pull request, if it's looking at the

entire repository, it's got to spend the

first minute before reviewing any of

your code just cloning the repository.

And so, that's one of the problems that

we solve. There are a few other

interesting things that we can do. So, I

can talk about some of these things, but

we've got kind of like real-time

features. So, in other words, you know,

sometimes you want to be able to observe

an agent session real time. But, I think

broadly like the focus here is just on

solving the problem of how you can run

massively parallel agents.

>> Okay. So, for example, everyone's using

work trees now, right? But, work trees

are just like honestly, they're like

clones and if you're working in a big

repo, that work tree is expensive and

now you have 10 work trees and now

you're running out of disk space because

you're just work treeing everything. And

so, in Mesa, this is not a work tree.

This is a snapshot of something you

touch. Walk me through like what that

would look like in Mesa instead of using

like a Git work tree.

>> Well, I think the first thing to say is

that today Mesa's really optimized for

uses like infrastructure. So, we're not

we're not even necessarily telling

people like to go and replace GitHub

with Mesa. Like if you're using GitHub

for, you know, your own software

development, I think maybe eventually

we'll go there, but but today the real

focus is on like the kind of

infrastructure use case. But, yeah, like

the Mesa model of the world would be

that instead of having to think about

work trees, you would just say like I

want to create a copy of this directory.

You could give it some other kind of

like a name much the way that you would

have a work tree, but it's a lot lighter

weight because work trees, while they

don't store a full copy of your version

history, they do still store like a full

copy of your documents and so, they can

be pretty expensive. And the Mesa model

here is that we want to be really smart

about what data you fetch. And so, like

in the same way that when you iCloud or

you use Dropbox, you might have like a

massive amount of data in that kind of

drive. So like your iCloud, your

Dropbox, your Google Drive could have

like a terabyte of data in it. And not

all of that data is going to be pulled

onto your laptop, but it feels like it's

just a regular folder on your laptop.

You can do the same thing in Mesa. So

we're doing this kind of like smart

partial materialization that's mostly

transparent to you as a user.

>> And agents can materialize as they

discover. Like if they decide they need

a folder, they can materialize it and

then keep going.

>> Exactly. And the agent doesn't even have

to tell you that like it wants that

folder. It can just say it can just say

list the folder. And I mean and this is

kind of the beauty of an actual virtual

file system, not just a CLI. Like if we

were a CLI just like Git, your agent

would have to, you know, check to see if

the folder exists, then maybe like query

an API and say I want to pull this down.

But because we're sitting at the like

file system layer, because we're, you

know, we're talking directly with the

kernel, all you have to do is ask for a

file like list a repository. We've

already fetched all the metadata and

then kind of like just in time if we

haven't already cached the data for that

file or folder, we can pull that down

from the cloud.

>> That's awesome. All right, we are

talking with Ben Warren so from

mesa.dev. Go check it out if you are

curious about file systems for AI

agents. Is the best place to follow you

at

I think that's right. You go to

mesa.dev.

>> That works.

>> All right. Any final words before we

wrap up?

>> I'm super excited for the for the kind

of like first-class integration that

we're about to launch with Modtra. You

can use Mesa with Modtra today. I think

it's a really awesome pairing, but I

think it's going to be even better when

we've got like a really tight

integration with Modtra workspace. So I

think there's a lot of cool stuff coming

down the pipe and yeah, obviously sign

up for the waitlist if you want to get

early access. Follow me on X.

Yeah, had a great time chatting.

>> Yeah. Awesome, dude. This is awesome.

We're going to play with it, too.

>> Yeah, thanks for coming on the show.

>> Sick. Have fun, guys.

>> Would you like to be a guest on the

show? Visit modtra.ai/guest.

Do you have a hot take, a problem you

cracked, a cool product for a demo worth

watching? Share them right here on Agent

Saur.