Ramp’s agent is called Inspect. It drafts pull requests end to end, an engineer reviews every one, and it reached that share of their merged frontend and backend work within a couple of months of launch. Their write-up is one of the few public accounts that shows the machinery honestly.
One pull request, start to finish
An engineer highlights a broken piece of their app’s UI with Inspect’s Chrome extension, or types a prompt into Slack. A sandbox VM comes up on Modal, restored from a snapshot image so the full dev stack an engineer has locally is already running; the images are rebuilt every 30 minutes to stay current. One detail shows how much they sweat the startup path: the repo syncs in the background, and the agent can read files immediately but can’t write until the sync completes.
Inside the sandbox, OpenCode drafts the change. Every session keeps its state in its own small database, which is how hundreds run in parallel without touching each other. The agent then verifies its own work the way an engineer would: it runs the app, takes before-and-after screenshots of the UI it changed, and runs the checks wired into Buildkite, Sentry, Datadog and LaunchDarkly. When it’s done, the session freezes into a snapshot and the PR goes up. An engineer reviews it, and often picks between several attempts they fired at the same prompt, because sessions are cheap enough to run in parallel and keep the best. If a review comment comes back later, the frozen session restores and continues.
Each piece buys something specific. The snapshots buy startup speed. The screenshots and real checks give the reviewing engineer evidence instead of promises. And all of it exists to clear one bar Ramp names explicitly: an agent that’s slower or less trustworthy than working locally never gets adopted.
What it takes to keep running
The same walkthrough is also the operations bill. Somebody at Ramp runs five systems: the sandbox fleet, the snapshot rebuilds, the session state, the agent loop, and the code that ties them to six external services. When a check fails, tracing it back to the right session only works if the run’s identity made it through every one of those systems intact. When snapshot rebuilds stall, sessions start stale. Ramp covers this with a platform team, which is the part of the write-up that doesn’t fit in a diagram.
The write-up also leaves one question open: what happens when a sandbox dies mid-run. Snapshots restore a finished session when a follow-up arrives, but the post doesn’t say whether an interrupted draft resumes or starts over. Restarting a one-shot draft costs little. For scheduled runs you depend on, recovery is the first thing to ask of any harness, including one you’re thinking of building.
The same pull request on a playbook
On paper, the same run maps onto a Sumn playbook with its sequence intact: trigger, draft, verify, human approval. The drafting stage runs in a fresh isolated VM, pre-warmed and destroyed when the stage ends. Separate stages run the checks you choose and return failures to the drafting stage. You can require a person to approve every merge, the way Ramp does. For a real run with its per-call receipt, the seven-models review post shows one end to end.
The mid-run death question has an answer here: runs checkpoint at stage boundaries and resume from the last completed stage after a crash or a deploy. Work inside an interrupted stage may run again; nothing before it does.
The platform keeps environments warm, checkpoints runs, and holds the record of what happened. You define the environment, the checks, the retry and spend limits, and who approves each kind of action. Ramp built and owns that whole platform layer, and their write-up shows the engineering that comes with it. Which parts of the loop your team should own is the actual decision, and their post is the closest thing to a cost sheet anyone has published.
Watch a run like this live
→A live run on the homepage. No signup.