Building a Custom Background Coding Agent with Cloud-Based Sandboxes

ramp · Finance · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Background coding agent infrastructure

Ramp wanted an internal background coding agent that could write code and verify its work with the same context, tools, local environment, collaboration channels, and pull-request workflow a Ramp engineer would use.

Constraints:

coding sessions need a full development environment but must start quickly
agents need access to tests, telemetry, feature flags, screenshots, previews, and company-specific shipping knowledge
users work across Slack, web, Chrome, pull requests, and editor workflows
multiple builders and follow-up prompts must share session state
the system must avoid unreviewed code being merged through app-owned pull requests

Architecture

Ramp built Inspect as a hosted coding-agent platform. Each session runs an OpenCode-based agent inside a Modal sandbox restored from a repository snapshot that is rebuilt every 30 minutes. A Cloudflare Durable Object owns session state and streaming across Slack, web, Chrome extension, pull-request, and VS Code clients. The sandbox has Ramp's development tools and observability integrations, pushes changes, and the API opens pull requests with the user's GitHub token.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  user-clients[User clients] --> session-api[Session API]
  session-api --> durable-object-session[Durable Object session]
  durable-object-session --> user-clients
  repository-image-registry[Repository image registry] --> snapshot-store[Snapshot store]
  session-api --> modal-sandbox[Modal sandbox]
  snapshot-store --> modal-sandbox
  modal-sandbox --> opencode-agent[OpenCode agent]
  modal-sandbox --> ramp-tools[Ramp tools]
  opencode-agent --> ramp-tools
  opencode-agent --> child-sessions[Child sessions]
  child-sessions --> session-api
  session-api --> github-integration[GitHub integration]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`User clients`	Slack, web, Chrome extension, pull request discussion, and web VS Code surfaces where builders interact with Inspect.	`Session API`
`Session API`	Coordinates client input, session state, sandbox lifecycle, and pull-request creation.	`User clients`, `Durable Object session`, `Modal sandbox`, `GitHub integration`
`Durable Object session`	Per-session SQLite-backed state and streaming coordination layer.	`Session API`, `User clients`
`Repository image registry`	Defines and rebuilds repository-specific development images every 30 minutes.	`Snapshot store`
`Snapshot store`	Stores completed repository images and follow-up session snapshots.	`Repository image registry`, `Modal sandbox`
`Modal sandbox`	Isolated VM running a full Ramp development environment for one coding-agent session.	`Session API`, `Snapshot store`, `OpenCode agent`, `Ramp tools`
`OpenCode agent`	Server-first coding agent that reads, edits, verifies, and coordinates sub-sessions.	`Modal sandbox`, `Ramp tools`, `Child sessions`
`Ramp tools`	Tests, telemetry, feature flags, observability, MCPs, custom tools, skills, and visual verification tools.	`Modal sandbox`, `OpenCode agent`
`Child sessions`	Additional coding-agent sessions spawned by Inspect for research or parallel pull requests.	`OpenCode agent`, `Session API`
`GitHub integration`	Uses user tokens and webhooks to create and track branches and pull requests.	`Session API`

Data flow

A builder starts a session from Slack, web, Chrome, or a pull request. The API creates or resumes a per-session Durable Object, starts a Modal sandbox from the latest repository snapshot, and runs the OpenCode agent with Ramp tools. The agent edits and verifies code, the sandbox pushes a branch, the API opens a pull request with the user's GitHub token, and clients receive streamed updates.

3 supporting quotes

“Every session gets its own SQLite database. This ensures high performance, even when you have hundreds of sessions running in parallel, as no one session can impact another.”article, stated

“* When we later start the session, we spin up a new sandbox that starts from this stored snapshot * This ensures that at most, the repository is 30 minutes out of date”article, stated

“Our setup is to have the sandbox push the changes (updating the git user as previously mentioned), and then send an event to the API with the branch name and session ID.”article, stated

Why this architecture

Ramp argues that a background agent is only useful if it closes the verification loop with company context and tools. Sandboxed cloud sessions give agents a full dev environment without tying up laptops, prebuilt snapshots remove cloning/install latency, Durable Objects isolate session state at high concurrency, and user-token pull requests preserve the review boundary.

3 supporting quotes

“Inspect writes the code like any other coding agent, but closes the loop on verifying its work by having all the context and tools needed to prove it”article, stated

“When background agents are fast, they’re strictly better than local: same intelligence, more power, and unlimited concurrency.”article, stated

“This is strongly preferred over having it open pull requests as the app itself. In the latter scenario, this would allow for any user to approve their own changes.”article, stated

Models used: frontier models · GPT 5.2 · OpenCode

Scale

Inspect wrote about 30 percent of merged pull requests to Ramp's frontend and backend repositories.
“Internal adoption charts have been vertical: ~30% of all pull requests merged to our frontend and backend repos are written by Inspect. It only took a couple months for us to reach this level of usage, and it continues to grow.”article, stated
Repository images are rebuilt every 30 minutes.
“We build these images every 30 minutes, meaning that we clone the repository, install any runtime dependencies, and do any initial setup and build commands”article, stated
Each session's repository snapshot is at most 30 minutes out of date.
“* This ensures that at most, the repository is 30 minutes out of date * This makes the synchronization with the latest code in the repository much faster, as there’s only up to 30 minutes of changes to sync”article, stated
Durable Objects are used so hundreds of parallel sessions do not affect each other.
“This ensures high performance, even when you have hundreds of sessions running in parallel, as no one session can impact another.”article, stated

Alternatives considered (roads not taken)

Local checkouts and worktrees

Rejected because: Fast hosted sandboxes avoid rationing local environments and allow unlimited concurrent sessions.

“Because Inspect sessions are fast to start and effectively free to run, you can use them without rationing local checkouts or worktrees.”article, stated

Cold clone and install at session start

Rejected because: Ramp moves cloning, dependency install, setup, and build work into prebuilt images so the user does not wait for it.

“Everything else, like cloning and installing, is done before you start your session. When background agents are fast, they’re strictly better than local: same intelligence, more power, and unlimited concurrency.”article, stated

Open pull requests as the app itself

Rejected because: That would let users approve their own changes and create an unreviewed-code path.

“In the latter scenario, this would allow for any user to approve their own changes. You do not want to knowingly create a vector for unreviewed code”article, stated

Interrupt running prompts with follow-ups

Rejected because: Ramp found queued follow-ups easier to manage and useful for sending next-step thoughts during execution.

“We chose to queue them, as we found it not only easier to manage, but also helpful for sending over thoughts on next steps while the AI is still working.”article, stated

Patterns

`durable-execution` (runtime)

Inspect stores each coding session in a per-session Durable Object with SQLite state and streaming coordination.

“Every session gets its own SQLite database. This ensures high performance, even when you have hundreds of sessions running in parallel”article, stated

`batch-offline-processing` (operations)

Ramp prebuilds repository images and snapshots every 30 minutes so user sessions start from a warm base.

“We build these images every 30 minutes, meaning that we clone the repository, install any runtime dependencies, and do any initial setup and build commands”article, stated

`tool-use-orchestration` (agent-design)

Inspect is wired into engineering systems, observability, MCPs, custom tools, skills, and visual verification tools.

“It’s wired into Sentry, Datadog, LaunchDarkly, Braintrust, GitHub, Slack, and Buildkite.”article, stated

`multi-agent-orchestration` (agent-design)

Inspect can spawn additional sessions for research or multiple smaller pull requests.

“Create a tool that starts a new session, and a tool that lets it read the status of any session, so it can check in periodically”article, stated

`human-in-the-loop-gate` (operations)

Inspect pushes branches and opens pull requests through user GitHub tokens so normal code-review controls remain in place.

“The API will then use the user’s GitHub token to call GitHub’s pull request API.”article, stated

Tradeoffs

Execution model

Chose cloud-hosted sandboxed sessions over local checkouts and worktrees.

Rationale: Hosted sessions provide the same tools as local development while enabling unlimited concurrency and no laptop dependency.

“same intelligence, more power, and unlimited concurrency. You can go home and let Inspect cook”article, stated

Session startup strategy

Chose prebuilt repository snapshots over cloning and installing at request time.

Rationale: Moving setup into image builds makes the user-facing session start much faster.

“Move as much as you can to the build step for your repository images * Thoroughly investigate what you need to do to have a complete development environment”article, stated

Follow-up prompt behavior

Chose queue follow-up prompts over insert follow-ups into the current execution immediately.

Rationale: Queueing was easier to manage and helped users send next-step thoughts while the agent was still working.

“We chose to queue them, as we found it not only easier to manage, but also helpful for sending over thoughts on next steps while the AI is still working.”article, stated

Pull-request identity

Chose open pull requests with user GitHub tokens over opening pull requests as the app.

Rationale: User-owned PRs avoid knowingly creating a vector for unreviewed code to enter the codebase.

“This is strongly preferred over having it open pull requests as the app itself.”article, stated

Gotchas (what bit them)

Hosted coding agents lose value when environment startup dominates time-to-first-token.

Root cause: Full dev environments require repository cloning, dependency installation, and build setup.

Resolution: Prebuild repository images, store snapshots, warm sandboxes while the user types, and let read-only research begin before sync completes.

“The key challenge is spinning up full dev environments quickly. Modal solves this: it's a cloud platform for AI infrastructure we use across Ramp.”article, stated

Letting a sandbox edit before repository synchronization can create conflicts.

Root cause: A snapshot can be up to 30 minutes behind the latest base branch.

Resolution: Allow early reading and research, but block write/edit tools until synchronization completes.

“you can let it start researching immediately, and avoid any latency from git here * However, ensure that you block file edits until synchronization is complete”article, stated

App-owned pull requests can bypass the intended review boundary.

Root cause: If the app opens PRs, a user may be able to approve their own changes.

Resolution: Use GitHub authentication and user tokens to open pull requests on behalf of the user.

“Consider using GitHub authentication if your code lives in GitHub, as this will give you a user token that you can then use to open a pull request on behalf of the user.”article, stated

A Slack coding bot can fail adoption if users must learn bot syntax.

Root cause: The interaction surface is where casual users discover the tool.

Resolution: Classify the repository from message, thread context, and channel name, then ask if unsure.

“Do not force the user to learn syntax to use a chat bot. They should just be able to chat with it, and it should figure it out.”article, stated

Evaluation

Ramp evaluates Inspect through merged-pull-request adoption, session startup speed, ability to verify changes with tests/telemetry/screenshots/previews, and organizational usage metrics in a statistics page.

Metrics: approximately 30% of merged frontend/backend PRs written by Inspect · session speed limited mainly by model-provider time-to-first-token · merged pull requests · humans prompting in the last 5 minutes

“Internal adoption charts have been vertical: ~30% of all pull requests merged to our frontend and backend repos are written by Inspect.”article, stated

“Include your entire organization’s usage, particularly surfacing how many sessions result in a merged pull request. This is the most important metric to track”article, stated

Outcomes

Inspect writes about 30 percent of merged pull requests to Ramp frontend and backend repositories.
Ramp reports vertical adoption within a couple months without forcing users to adopt Inspect.
The platform lets builders use multiple clients, multiplayer sessions, and cloud sandboxes without local setup.

The article reports ~30% of merged frontend/backend PRs written by Inspect, repository image rebuilds every 30 minutes, and support for hundreds of parallel sessions.

“It only took a couple months for us to reach this level of usage, and it continues to grow. We didn’t force anyone to use Inspect over their own tools.”article, stated

“The interface understands that people rely on a rich variety of workflows. You can chat with Inspect in Slack and send it screenshots”article, stated