dbmikus

But the identity part of git is not (unless you count pgp signing of each commit, which never took off at a large scale)

and the git tools don't automatically propagate repo changes by default across a network

Well, definitely makes me inclined to never use Codeberg for source hosting if they can just get together and decide to ban an entire category of source repo.

It makes Codeberg seem like an unserious project.

Really freaky seeing how many of these are bedrooms.

Is the talk going to be shared online anywhere? Would be interested in checking it out later!

exe.dev is great, but the VMs are not really "apps". They are durable computers / VMs.

An example of a "sandboxed agent app", would be: give the app all your past emails. An agent scans them and finds sales emails you need to follow up on. It shows you the suggested follow ups in a UI, and you approve/reject them. Then, it mass sends the approved emails and emits an update to your CRM with the changes.

The sandbox is deleted when the app runs. It's ephemeral for the lifecycle of the app. And you can re-run the same app repeatedly with new inputs, but it gets the same clean starting slate.

Def!

My personal belief is that the future of an "app" is a combo:

    1. micro VM
    2. agent on the VM
    3. software bundled into the VM

Firecracker has more tooling for the orchestration layer that manages many sandboxes at once. Stuff like K8S integration, an external REST API control plane, more first-class support for snapshotting, etc.

You'd have to build more of that with libkrun

The core tech of both are great though.

Why do you want to self-host vs. using one of the many providers out there?

Daytona, E2B, OpenComputer, Freestyle, Blaxel, Vercel, Modal, Cloudflare, Tensorlake, Superserve, etc. etc.

Some of them work by pre-purchasing credits, so you can control the blast radius of spend.

Also, if you want a more embedded sandbox runtime as a library instead of a daemon + REST API, you can check out libkrun (and friendly layers on top of it like https://microsandbox.dev/ and https://smolmachines.com/)

There are sooooo many sandbox providers out there.

They do spike on different features like:

    - snapshotting and forking
    - good SSH and VPN access for end-users
    - agent-friendly features, like obscuring secrets at network layer

I've been working on some open-core stuff[1] to coordinate sandboxes, and we're making changes to have a library that lets people coordinate any number of remote or local sandboxes using any provider, kinda like how the Docker CLI works for managing containers, git repos, and coding agents. Flue[2] is another player in this space, and is more of a pure framework, while we're building it as an interactive product for using sandboxed agents and workflows.

[1] https://github.com/gofixpoint/amika/blob/main/ROADMAP.md

[2] https://flueframework.com/

Yes, running locally certainly helps if you want your sandboxed AI to be able to use the internet without getting blackholed by Cloudflare

Yeah, Docker Sandbox is in the right direction. But there's a lot of parts that are still not ironed out yet.

How do you package a Docker Sandbox up into an app that can expose UI widgets, with an agent hiding behind them? What widgets is the agent allowed to modify? How do you run a workflow like "give agent all these files, modify the files, and do changeset management on the modifications?"

I'm not 100% sure which part of these will be baked into the application standard format, and which are orthogonal. But current way of packaging up and running these agents doesn't feel right.

I think about this a lot because my startup is building cloud VMs for agents to do code-gen and auto-validate changes, so we have a workflow like:

    1. git repo, skills, CLI tools, biz context goes in
    2. agent iterates against running dev environment
    3. changes go out into git PRs and CI

Understand that it is annoying to spin up a heavyweight VM whenever running Claude Desktop, but I actually think per-app + agent virtualization is the future. Next version of an app is:

    1. micro VM
    2. agent on the VM
    3. software bundled into the VM

It's self-modifying apps that are sealed off from touching parts of the computer they shouldn't.

Claude Code's dynamic workflows are AI-generated JavaScript, so unlike `/goal` they can in theory import libraries and perform I/O (not sure that they can currently).

On checkpointing: I explained myself poorly. You're right that using higher level workflows doesn't turn off checkpointing. One can simply make harnesses non-interactive, but that can make models lose coherence over long tasks (because they can't ask for feedback). A higher level coordinator (/goal, CC dynamic workflows) is designed to provide this feedback without human intervention.

On price: older models keep getting cheaper, and most tasks don't need frontier capability. (I'm ignoring the part about subscription subsidies right now, and just talking about API price for tokens)

On my startup Amika: we run programmable cloud computers for agents, plus the workflow systems to guide them. We let people run any agent (Codex, Claude, etc.), prompt it from anywhere (Slack, web, CLI + SSH, API). It's like devboxes for humans + agents, with guardrails[1] to deterministically ensure things about the changes coding agents make (ie don't let agent modify module boundaries, require every DB query carry a multi-tenant org ID filter).

Maybe our website is bad at explaining it, in which case I appreciate any feedback!

[1] https://docs.amika.dev/guides/code-annotations

To stop agents from pausing for checkpointing, you can have a deterministic outer loop that re-runs until a stop condition is met.

I think teams need to be able to write nested workflows that transition between code-led and agent-led, with either supporting human-in-the-loop checkpoints.

Been iterating on what this should look like at our startup (https://www.amika.dev/). Model labs are also improving capabilities here, such as Codex's `/goal` and Claude Code's dynamic workflows[1]

The points about API usage cost still stand, but model intelligence is getting cheaper every month! No need to use the frontier model for every part of the work.

[1] https://code.claude.com/docs/en/workflows

I think with a proper managed agents platform, the user should have total control over the VM, the software on it, which model to use, and which agent harness to use. Then you can just override the system prompt and you don't need to follow Anthropic's rules!

Maybe Anthropic will give more control over configuring the Claude harness and VM, but they definitely won't let you swap out to other models and harnesses.

We've been building open core infra (https://github.com/gofixpoint/amika) for running any agent on any type of VM or sandbox, with the main use case for safely automating internal code-gen, but technically could repurpose our stack for anything.

There should be a model agnostic platform for running these types of agentic apps.

A couple other major open source harnesses:

- https://github.com/badlogic/pi-mono/ - https://github.com/anomalyco/opencode

Spaces help me visually organize related apps. I have all my chat apps in one, all my dev stuff in another.

I used to run Linux with i3 tiling window manager, but switched to Mac because the battery is so much better. Although the new Framework laptop looks like it has pretty great battery life.

I really like exe.dev's pricing model where I pay a fixed monthly fee for compute and then can split it up into as many VMs as I want. I use exe.dev to run little vibe-coded apps and it's nice to just leave them running without a spend meter ticking up.

We're thinking about switching to this pricing model for our own startup[1] (we run sandboxed coding agents for dev teams). We run on Daytona right now for sandboxes. Sometimes I spin up a sandboxed agent to make changes to an app, and then I leave it running so my teammate can poke around and test the running app in the VM, but each second it's running we (and our users) incur costs.

We can either build a bunch of complicated tech to hibernate running sandboxes (there's a lot of tricky edge cases for detecting when a sandbox is active vs. should be hibernated) or we can just provision fixed blocks of compute. I think I prefer the latter.

[1] https://github.com/gofixpoint/amika

Like the detailed setup instructions in the readme!

Also agree that teams should invest in their own harness (or maybe pedantically, build a system on top of harness likes Claude Code, Codex, Pi, or OpenCode)

Yes, I hate how slow it is to swipe between desktop workspaces, for example.

Curious if Andon has gone one level higher and has the AI decide what next real-world experiment it should do.

If you don't get it working with Claude Code Routines, would love to connect and see if we can help! We're building an open core product that can spin up sandboxed coding and control them from Slack (and also web UI, TUI, and HTTP APIs + CLIs)

We work with any coding model / harness.

website: https://www.amika.dev/

OSS repo: https://github.com/gofixpoint/amika

And my email is dylan@amika.dev (I'm one of the founders)

We might be building something up your alley! I wanted an OSS platform that let me run any coding agent (or multiple agents) in a sandbox and control it either programmatically or via GUI / TUI.

Website is https://amika.dev

And part of our code is OSS (https://github.com/gofixpoint/amika) but we're working on open sourcing more of it: https://docs.google.com/document/d/1vevSJsSCWT_reuD7JwAuGCX5...

We've been signing up private beta users, and also looking for feedback on the OSS plans.

necro-posting here, but that's kinda what we're working on! We're focused on creating cloud workspaces for sandboxed coding agents and it's built to support any agent harness. https://www.amika.dev/

Under the hood, we're open sourcing a lot of the parts for provisioning these agents, their VMs/sandboxes, and managing agent messaging + sessions. Put our open source plans here: https://docs.google.com/document/d/1vevSJsSCWT_reuD7JwAuGCX5...

I'm a cofounder of Amika (https://www.amika.dev/) (OSS repo: https://github.com/gofixpoint/amika).

We let users spin up sandboxed coding agents in the cloud, and control them interactively or programmatically. Each sandbox comes loaded with your git repos, your pick of coding agents, agent skills, MCP servers, and CLI tools, plus a live preview environment so you and the AI can see changes in real time.

I like running `claude --dangerously-skip-permissions` in Amika because worst case, I just delete the sandbox. You can also spin them up via API/CLI to do things like catch Sentry issues and auto-fix them in the background.

Little demo: https://youtu.be/OZzdBNBXxSU?si=4BwPQmFNq94-5T6H

We're excited about "software factories": using code-gen automations to produce more of your code. We still review everything that lands, but the process of producing those changes is getting more hands-off.

Are there any good guides on how to write prompt files tailored to different agents?

Would also be interested in examples of a CLAUDE.md file that works well in Claude, but works poorly with Codex.

Every website needs to add the "friend or foe" system[0] so that I can mark bots to avoid their content and mark good posters so I can filter just to theirs.

[0] https://hackersmacker.org/

From the article, it looks like they integrated with Docker because someone at Docker reached out about collaborating on the integration.

Regarding security, I think you need three things:

  1. You need the agent to run inside a sandbox.
  2. You need a safe perimeter or proxy that can apply deterministic filtering rules on what makes it into the AI agent's sandbox and the HTTP requests and responses that agent sends out from the sandbox.
  3. The bot should have its own email accounts, or maybe be configured to only send/read from certain email addresses

I personally see a future where there are many different types of *Claws, coding agents, etc. and I think they need a new "operating system", so to speak.

Self-plug at the end: https://github.com/gofixpoint/amika. The OSS part of my startup, focused on sandbox coding agents right now :)

PS: I enjoyed the entropytown.com blog! bookmarking it

Cool, thanks for explaining!

Appreciate the deets!

It sounds like a big part of your use case is to safely give an agent control of your computer? Like, for things besides codegen?

We're probably not going to directly support that type of use case, since we're focused on code-gen agents and migrating their work between localhost and the cloud.

We are going to add dynamic filesystem mounting, for after sandbox creation. Haven't figured out the exact implementation yet. Might be a FUSE layer we build ourselves. Mutagen is pretty interesting as well here.