Building a Full-Context Background Coding Agent with Sandboxed Development Environments

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 needed a background coding agent that could start as fast as a local agent, run complete development environments, verify work with internal tools, support non-engineers, and scale to many concurrent coding sessions.

Constraints:

• a slower or less capable hosted agent would not be adopted
• the agent had to integrate with Ramp's internal stack and observability tools
• every builder needed access without local setup
• parallel sessions needed isolation and coordination without laptop contention
• frontend work required visual verification in a browser

Architecture

Ramp built Inspect on Modal Sandboxes. Each session starts from a filesystem snapshot rebuilt every 30 minutes, giving the agent a full-stack environment with Postgres, Redis, Temporal, RabbitMQ, OpenCode, VS Code server, terminal, VNC, Chromium, GitHub, Slack, Buildkite, Sentry, and Datadog. Modal Functions rebuild snapshots, Dicts coordinate locks and image metadata, and Queues route prompts from Slack, web, and Chrome extension clients into the right session.

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

flowchart LR
  client-surfaces[Client surfaces] --> modal-queues[Modal Queues]
  modal-queues --> inspect-session[Inspect session]
  modal-dicts[Modal Dicts] --> inspect-session
  modal-functions[Modal Functions] --> filesystem-snapshots[Filesystem snapshots]
  filesystem-snapshots --> modal-sandbox[Modal Sandbox]
  inspect-session --> modal-sandbox
  modal-sandbox --> opencode-agent[OpenCode agent]
  opencode-agent --> developer-tools[Developer tools]
  developer-tools --> modal-sandbox

Components

Data flow

A builder starts from Slack, web, or Chrome. Modal Queues route the prompt to the correct Inspect session. A Modal Sandbox starts from the latest snapshot, runs OpenCode plus development services, and verifies changes with tools such as browser screenshots and observability integrations. Modal Dicts coordinate session locks and image metadata for multiplayer state, while GitHub and Buildkite handle review and CI workflows.

Why this architecture

Ramp used Modal because cloud sandboxes solved the adoption barrier for background agents: fast startup, full internal context, unlimited parallel capacity, and zero local setup. Modal's distributed primitives let Ramp focus on the agent experience while Modal handled coordination, snapshots, and concurrent sandbox execution.

Models used: OpenCode · LLMs used by Inspect

Scale

• Inspect writes over half of all merged pull requests at Ramp according to the article.
  “an internal background coding agent that now writes over half of all merged pull requests at Ramp.”article, stated
• Over 80 percent of Inspect itself is written by Inspect.
  “Ramp didn't mandate Inspect, they let the product speak for itself. Within a couple of months, roughly half of all merged pull requests across Ramp's frontend and backend repos are started by Inspect, with over 80% of Inspect itself now being written by Inspect.”article, stated
• Snapshots are rebuilt every 30 minutes.
  “Every 30 minutes, a Modal Cron clones each of Ramp's repositories”article, stated
• Sessions start working on prompts in a few seconds.
  “When a builder starts a session, Inspect creates a new Sandbox from the latest snapshot. Since the snapshot is at most 30 minutes old, syncing with the head of the repo is nearly instant. End-to-end, sessions start working on a prompt in a few seconds.”article, stated
• The architecture scaled to hundreds of concurrent sessions.
  “Since Modal handles the distributed coordination, Ramp's team could focus entirely on the agent experience — the tools, the integrations, the UX — rather than the infrastructure underneath. That's how a prototype built in days scaled to hundreds of concurrent sessions without a rewrite.”article, stated

Alternatives considered (roads not taken)

Local coding agents

Rejected because: Local agents required environment setup and could not easily integrate with Ramp's internal tooling.

Cold sandbox startup from scratch

Rejected because: Snapshots let sessions start from a nearly current state and avoid slow clone/install work.

Building distributed coordination infrastructure in-house

Rejected because: Modal Functions, Dicts, Queues, and Sandboxes provided the primitives Ramp needed.

Patterns

batch-offline-processing (infrastructure)

Repository images and filesystem snapshots are prepared on a 30-minute cron so interactive sessions avoid setup latency.

latency-optimization (operations)

Filesystem snapshots and delta syncs make cloud sandboxes start fast enough to compete with local agents.

tool-use-orchestration (orchestration)

Inspect wires the agent into developer services, browser verification, CI, GitHub, Slack, and observability tools.

multi-agent-orchestration (orchestration)

Builders can run multiple versions of prompts and let Inspect spawn child sessions across repositories.

human-in-the-loop-gate (workflow)

The outcome is review-ready pull requests, not automatic merging; engineers and other builders review generated changes.

Tradeoffs

Use Modal Sandboxes for execution

Chose ephemeral full-stack cloud environments over local machines or lightweight tool-only execution.

Rationale: Sandboxes provided fast startup, services, isolation, and effectively unlimited parallel capacity.

Expose Inspect beyond engineers

Chose Slack, web, VS Code, desktop stream, and Chrome extension clients over an engineer-only CLI or IDE integration.

Rationale: The goal was for product managers and designers to ship changes too, without local setup.

Rely on Modal primitives for coordination

Chose Functions, Dicts, Queues, and Sandboxes over custom distributed coordination infrastructure.

Rationale: This let Ramp scale from prototype to hundreds of sessions without rewriting the infrastructure.

Gotchas (what bit them)

Hosted coding agents fail adoption if they feel slower than local workflows.

Root cause: Developers compare against local agent latency and environment availability.

Resolution: Use prebuilt snapshots and cloud sandboxes that start in seconds.

Cloud agents need the same internal context humans use to verify changes.

Root cause: Coding alone is insufficient for production; frontend and backend work needs CI, observability, browsers, and services.

Resolution: Put the full development stack and verification tools inside the sandbox.

Multiple client surfaces can conflict if they do not share session state.

Root cause: Slack, web, Chrome, and multiplayer sessions all feed prompts to the same work.

Resolution: Route prompts through queues and coordinate locks/metadata with Modal Dicts.

Evaluation

The source evaluates adoption and operational impact by pull-request share, self-hosting usage, session concurrency, startup speed, and ability to produce review-ready PRs.

Metrics: over half of merged pull requests · over 80% of Inspect written by Inspect · few-second session start · hundreds of concurrent sessions

Outcomes

• Inspect became responsible for roughly half or more of merged Ramp pull requests depending on quoted source line
• Inspect itself became largely self-built
• the system scaled from a side prototype to hundreds of concurrent sessions
• non-engineers gained code-shipping surfaces through web and Chrome clients

The article reports over-half PR share, over 80% self-authorship of Inspect, sessions starting in seconds, and hundreds of concurrent sessions.