dbmikus

Identity is more than a name. It is also proving that you own that identity (aka authentication)

il y a 3 joursdiscuss

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

dbmikus

il y a 3 joursdiscuss

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.

dbmikus

il y a 28 joursdiscuss

Really freaky seeing how many of these are bedrooms.

dbmikus

il y a 28 joursdiscuss

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

dbmikus

il y a 29 joursdiscuss

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.

dbmikus

il y a 29 joursdiscuss

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

So, it should be stupid simple to run these local sandboxed apps/agents. Right now, not too hard for technical users (esp. with things like https://smolmachines.com/ and https://microsandbox.dev/), but not as easy as clicking an app icon or typing `/path/to/binary` in the CLI

dbmikus

il y a 29 joursdiscuss

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.

dbmikus

il y a 29 joursdiscuss

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/)

dbmikus

il y a 29 joursdiscuss

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

Then there's also the option to use libkrun to run local sandboxes on your own computer. That doesn't scratch the itch for hosted services, but works if your goal is to run agents inside isolated environments for your own work.

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/

dbmikus

le mois dernierdiscuss

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

dbmikus

le mois dernierdiscuss

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

I think this type of app/agent workflow will expand outside coding use-cases.

dbmikus

le mois dernierdiscuss

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

Then the agent is totally sandboxed at the hardware virtualization level. It can use the software tools on the VM or write its own. VM can control which software is "frozen" and which is open to agent modification. And VM can also control which services are exposed outside the VM through sockets, HTTP server, X window system, whatever

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

dbmikus

il y a 2 moisdiscuss

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

dbmikus

il y a 2 moisdiscuss

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

dbmikus

il y a 3 moisdiscuss

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.

dbmikus

il y a 3 moisdiscuss

A couple other major open source harnesses:

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

dbmikus

il y a 3 moisdiscuss

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.

dbmikus

il y a 3 moisdiscuss

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

dbmikus

il y a 3 moisdiscuss

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)

Submissions

Instagram will test hiding likes in the US as soon as next week

comments