alt Hacker NewsI hate to speak negatively about someone's hard work but I am genuinely confused as to why this needs to be a separate product/service. Could I not spin up a container or a VM and run my agents in it? What is this sandbox letting the agent do safely that neither the current container or VM solutions are able to offer?
Replies
Co-builder of proj here:
You absolutely can spin up a container or a vm and run your agents in it - but you make trade offs. Containers are easy and fast. Vm's use more resources but are more secure. Most people in production run containers in vm's to get benefits of both!
This is a product that tries to get the best parts of both containers (devX + speed) and vm's (security). The innovation here is using micro-vm's which are really really lightweight and fast to start compared to traditional vm's. Props to libkrun team for creating that: https://github.com/containers/libkrun
Just poked through the code, and I’ll add to the other answers given from an outsiders perspective.
What I find interesting: I’m running all kinds of agents (for good or bad, make fun of me if you like): not just coding agent products, but “hand rolled” as well, and they all have features which require some filesystem or environment state (tools, skills, instructions etc). They are each subtly different in those requirements, but some patterns are emerging and it seems to me that OP is seeing this as well - and noting that this aligns with the Agent Sandbox domain which is not “solved” yet. Consider that a Dockerfile sets up an environment for the code you want to deploy, which is better than the shell script you use on your local - it’s becoming more apparent to me that there’s a similar need here, which isn’t satisfied by the abstractions we already have, and lots of folks are poking around these domains to find something that fits.