Just created a PR from a github issue via a serverless background agent, and it's entirely open-source at humanlayer we have been thinking a lot about what good open-source software factory building blocks look like to push on this I built something I've wanted for a long time: a hands-outside-the-box approach of running a lightweight agent in a runtime with a virtual fs, and only using a container when necessary - faster, cheaper, etc combined with really good webhook / event bindings for GitHub, slack, and linear we built two components for it: 1. - effect-native webhook subscriptions for slack/linear/github; like the @vercel chat SDK but effect + more opinionated about software factories; handles threading & debouncing event deliveries and stuff like that 2. mentions & other events spin up our Fold harness ( think kinda like @pidotdev in effect; fully isomorphic, runs anywhere) infra is built on @cloudflare workers and durable objects via @alchemy_run - each thread/channel/issue/pr gets its own mailbox, subject to delivery policies (queue, debounce, batch) mailbox messages wake a fold agent session running in a Durable object, without a sandbox to start it uses cloudflare/computer for a virtual DO-backed filesystem for each issue/PR's git branch the agent can run most commands it wants against the DO's virtual filesystem and the agent can boot a container with the FS mounted into it via FUSE only when it decides it needs one to run heavier commands tools are generated from the webhook event so the agent gets tightly-scoped tools to e.g. create a pr from the issue it's on, or to list failing checks only from the PR it's bound to; plus it's easy to interleave deterministic code it has live progress updates, can react to issues in its thread, etc (linear + slack modules support their respective streaming agent activity & agent plan APIs; for github we fudge it a bit by editing issues in live time) it even has an API so agent work can be handed off to another system (e.g. a k8s cluster that has super thick sandboxes if you need > standard-4 sized-containers from cloudfalre) and that system can post back streaming updates & update the status of the agent run, so it's pretty de-coupled it's wired to automatically investigate CI failures and some other neat stuff open-source at a good example of it in action:

Should you /grill-with-docs, /wayfinder, or just one shot the code? 1. If the diff is tiny, DON'T grill /grill-with-docs saves you from situations where the agent built the wrong thing. But if the thing it's building is tiny, that cost drops to nothing. So one-shotting is absolutely fine when you're only making small changes. 2. Never start with /wayfinder A failure mode of /wayfinder is that you start grilling and the solution turns out to be way simpler than you thought. Why is this bad? Because you've created the map and tickets, and you realise you don't need them. So if the expected diff is medium-large, always start with a /grill-with-docs session. Then, if planning starts to get out of hand, just say "/wayfinder let's turn this into a map".