Does this provide gitflow to handle conflicts from multiple agents touching the same file system or is it purely for single-branch sequential iterations on the filesystem?
I have a use case that could use this if it supports handling branching and merging file systems.
Just my two cents: less is more and the first impression matters a lot. I'm saying this because we see a new agent sandbox tool on the front-page almost every day. Most of them have an AI-made landing page design, lots of animations, lots of words. This has become a bad sign for me. I can tell that you put time into it, made a video, and everything, but I guess I'm suffering from some kind of fatigue of having to go through all these tools. So, the less I have to process to get to the meat of exactly what I'm looking at, what sets this apart from others, why and when I would need to use it, then the more likely I am to actually engage with the product.
That's fair. What makes this unique is the versioned, composable filesystem. It's built on top of lakeFS (https://github.com/treeverse/lakeFS) so it scales really well, unlike other solutions that try and do this with Git directly.
Before I invest my time into something like this I'll need to know what it'll end up costing in the end. Perhaps it's just that "private previews" aren't for me. Good luck!
I was trying to build an agent. None of the sandboxes out there had solved the filesystem problem. I want my agent to have a persistent storage, and that stays forever. Like a human with a computer. When the agent spins up again, it has access to the computer with the same files.
I had to create my own setup using aws s3 filesystem and docker for this.
Hey, this is exactly what we do at https://instavm.io Agents get persistent storage that outlive the sandbox and when the agent spins up again you get access to the computer with same files.
Snapshotting a filesystem is trivial with e.g. btrfs. You can hook snapshot creation in your agent.
That is a single one liner of btrfs subvolume snapshot, in a single hook configuration file, ready to be valued at $10B as quantum agentic versioned sandbox startup.
Nice, I think that's pretty neat. Do you have an idea where to take this further? I.e. for the filesystem it's great but what if you need to touch external systems that keep their own state?
In a perfect world, every system and external API would expose a standardized interface for versioning its own immutable state, so you'd be able to rollback and time travel across multiple such systems.
Not sure what else we can do in this world other than tightly control outbound requests and provide enough visibility into those requests for a human|agent to try and undo changes.
Happy to hear your thoughts - what would you like to see us take this?
more tools I will never use or need theres just an endless supply of new open source projects now I stopped paying attention
I increasingly feel the impact of landing on the frontpage of HN is not as pronounced as it used to be. The demographic shift of HN is also noted, it has a lot more "reddit" vibe than I remember.
Interesting project. I am building an IDE for my phone and browser (www.propelcode.app) and have evaluated a few container architectures and providers. It was quite painful to get a prototype working. I will try your platform and would be happy to give feedback.
How does the scale? For example if I were to have hundreds or thousands of concurrent agents running with some parts of their data pulled out of shared state and other parts custom to that particular agent run and I wanted all of this to be preserved for future collective or individual agent use later, is this a reasonable primitive for that problem space? Or is this more for a situation what you have one or a small number of productivity assistance agents that need a sandbox but low data mutation throughput and low amount of concurrent access across different agents?
I don't get it, it looks like they are copying data to the sandbox filesystem why would that impact production data? Because the agent can re-upload the file to s3?
That's exactly how I tried to address that problem with https://github.com/afshinm/zerobox -- you control what network access (e.g. `--deny-net *.amazonaws.com`) your agent has and you also get snapshotting out of the box.
That said, using LakeFS is probably a better long term solution and I like this approach.
Good question - the filesystem is Fuse-mounted into the sandbox, not copied into it. This way agents can modify data directly simply by interacting with the "local" files.
Sure! and it's not either/or - you can either import code from GitHub (or any other git remote) into a Tilde repository, or simply clone a repository directly inside the sandbox if you want full control over the git commit/branch semantics.
the repo acts as a source of truth for agents. think memory, data & code. If an agent decides to change any of those, version control allows:
1. to have a human in the loop to approve certain changes
2. rollback changes that end up being incorrect
3. allow reviewing the timeline and history to figure out what changed and how
2. is false. You can't roll back everything an agent does. If you told it to place a trade in the stock market, for example, you can not undo that. That is what I mean by external state. Everything else is covered by existing version control, is it not? What does this buy over that?
indeed - this only applies to the filesystem managed by tilde. Existing version control is fine if you're only managing code. For data (Think large parquet files, millions json files, images and videos, etc), git doesn't scale well for that.
Interesting. Literally saw a tweet talking about exactly this last night.
Not sure how I feel about it using on your hosted service, while your home page is asking me for analytics data and only the cli and sdk are open source.
Fair enough - the underlying technology is indeed open source (https://github.com/treeverse/lakeFS) - the service provides the hosting and tooling to make it easy for consumption by agents.
Thats a cool project. I didn't scroll down far enough to see that. Thanks for the correction
I get providing a hosted service, but I don't understand how it makes it easier for agents to consume unless you're hosting an MCP? My understanding is an agent skill and a cli tool is all an agent needs?
The repository itself get fuse-mounted into the running sandbox - no skill or MCP required to interact with data: an agent can simply `cat <file>` and use whatever tools they are already good at using.
I know everyones trying to figure out how to make money in this grift economy, but if you're a rational person, you know that it's all a bunch of gambling and tailoring your scope to b2b and ignoring local & open source models and tools, you're more likely going to be part of that permanent undeclass they keep talking about in a self-fullfilling prophecy.
I have a use case that could use this if it supports handling branching and merging file systems.
If I understand correctly what Tilde is doing is extending the concept of the sandbox in an operating system - filesystem, to data too.
So this is a sandbox environment someone would use for data heavy agentic workloads, is this correct?
Before I invest my time into something like this I'll need to know what it'll end up costing in the end. Perhaps it's just that "private previews" aren't for me. Good luck!
I had to create my own setup using aws s3 filesystem and docker for this.
Does Tilde solve for this?
That is a single one liner of btrfs subvolume snapshot, in a single hook configuration file, ready to be valued at $10B as quantum agentic versioned sandbox startup.
Not sure what else we can do in this world other than tightly control outbound requests and provide enough visibility into those requests for a human|agent to try and undo changes.
Happy to hear your thoughts - what would you like to see us take this?
I increasingly feel the impact of landing on the frontpage of HN is not as pronounced as it used to be. The demographic shift of HN is also noted, it has a lot more "reddit" vibe than I remember.
That said, using LakeFS is probably a better long term solution and I like this approach.
What I would use it for and why?
It reminds me of a blockchain - where it was a solution desperately looking for a problem. What problem does it solve?
1. to have a human in the loop to approve certain changes 2. rollback changes that end up being incorrect 3. allow reviewing the timeline and history to figure out what changed and how
Not sure how I feel about it using on your hosted service, while your home page is asking me for analytics data and only the cli and sdk are open source.
I get providing a hosted service, but I don't understand how it makes it easier for agents to consume unless you're hosting an MCP? My understanding is an agent skill and a cli tool is all an agent needs?