Ona is the background agent infra Ramp had to build

Background agents are no longer theoretical. Ramp published their background agent: it now writes more than half of all merged pull requests at the company. Stripe published theirs: over a thousand AI-authored PRs per week. Every engineering leader in the industry is now asking the same question: how do we do this too? Most are asking it under pressure from executives who have seen the same numbers and want results yesterday.

What neither post says out loud is how long it took to get there. Stripe's agent harness runs on top of a remote development platform they built years before GPT-3 existed. Ramp built sandboxed execution on Modal, persistent session state on Cloudflare Durable Objects, a custom image registry, and a queue system routing prompts from four different clients into the same running session. Both companies had something most engineering organisations do not: existing platform teams, years of standardisation behind them, and the talent and budget to build and maintain bespoke infrastructure indefinitely.

The most common mistake we see is reaching for the wrong primitive. Teams try to run agent harnesses like Claude Code inside Kubernetes clusters, CI platforms, or container runtimes and discover that these primitives encode assumptions that break under agent workloads. Agents are not short-lived, deterministic jobs. They are long-running, stateful, and interactive. That mismatch becomes obvious over time, usually after you are already overcommitted and it is too late to change course.

RelatedDon't build a coding agent sandbox yourselfRead the post→

This article breaks down the infrastructure Ramp and Stripe built, layer by layer, then shows what Ona provides out of the box. The goal is to give you an honest picture of what goes into this stack so you can decide whether to build it or buy it.

1. Development environments

Every agent session needs a full development environment. Same tools, dependencies, and database access a human engineer would have. Not a container. Not a CI runner.

This is the layer most teams get wrong first. The instinct is to reach for Kubernetes, a CI platform, or a container runtime. An agent that cannot install packages, run your test suite, and execute builds cannot validate its own work. You limit the autonomy of the agent by constraining the environment it runs in. We wrote about why the obvious runtimes fall short separately, but the short version is: containers share a kernel, CI runners were not built for stateful work, and Kubernetes inherits both problems.

Ramp solved this with Modal VMs and a custom image registry that rebuilds every repository every thirty minutes to keep startup fast. Stripe had already invested years in standardised remote devboxes before agents existed. Most organisations have neither Ramp's registry pipeline nor Stripe's head start.

Without a real development environment, agents guess at diffs. With a full development environment, they open merge-ready pull requests.

2. Isolation and security

Every agent session needs scoped credentials. Source control, CI, package registries, internal APIs, secrets managers: each needs its own access model. You will want ephemeral tokens per environment so nothing persists after a session ends, role-based access control per project so agents only touch the repositories and secrets they should, and network-level isolation so sessions can only reach the services they are authorised to reach. All of this needs to hold when hundreds of sessions run concurrently.

On top of that, agents are vulnerable to prompt injection and are adept at working around static denylists. We tested this: Claude Code bypassed its own denylist, then disabled its own sandbox to finish the task. No jailbreak. The agent just wanted to complete the work. Ideally you enforce restrictions at the kernel level, below anything the agent can see or reason about. But the security tooling market for agents is still nascent. There is very little you can buy off the shelf today, and what does exist is tightly coupled to the runtime. Security gets baked into whoever provides the infrastructure. If you build the runtime yourself, the security burden is yours too.

Agent security is not a layer you bolt on. It is inseparable from the runtime, and the runtime is the hardest part to get right.

Deep diveHow Claude Code escapes its own denylist and sandboxRead the technical breakdown→

3. Connectivity and context

It is widely understood at this point that the more context you give an agent, the better the work it produces. Context is not just your source code. It is your databases, internal documentation, API schemas, staging environments, and the full test suite that validates changes against real services. An agent that cannot access your databases, internal APIs, and test infrastructure will never produce production-ready code. This makes network connectivity a fundamental requirement, not a nice-to-have.

Stripe's agents run on EC2 devboxes inside their own infrastructure with native access to their monorepo, internal services, and database replicas. Ramp's agents run on Modal within their own cloud, connected to the same internal systems their engineers use daily. Neither team tried to make this work from outside their network. They understood that agent output quality depends on what the agent can reach.

Most third-party sandbox providers give you a container in someone else's cloud and leave you to figure out networking, which usually means tunnels, exported secrets, and brittle proxy setups. But the build-versus-buy framing here is not binary. Bring-your-own-cloud models now exist that deploy inside your VPC while remaining fully managed, giving you the connectivity of self-hosting without the operational burden.

Context is what makes agents effective. Context lives on your network.

RelatedThe last year of localhostRead the post→

4. Automation and parallelism

Ramp and Stripe achieved their numbers in part because they can run agents in parallel. As this extends forward, the direction is clear: fleets of agents running maintenance across thousands of repositories, responding to PR events, remediating vulnerabilities on a schedule, triaging issues overnight. If agents only run when a developer prompts them, you are limited by human capacity and will not achieve full SDLC automation.

Getting there requires two things. First, trigger infrastructure: webhooks that fire agents when PRs are opened or GitHub comments are posted, cron schedules for nightly tasks like dependency updates or test coverage sweeps, and entry points from wherever developers already work, whether that is Slack, an editor, or a CLI. Second, the ability to scale parallel environments: the underlying orchestration to spin up dozens or hundreds of agent sessions at once, and the interfaces for developers and platform teams to configure, launch, and monitor those sessions.

The organisations that will get the most from background agents are the ones that can run them proactively, in parallel, and across their entire codebase.

Ona is the platform for background agents

The market is moving fast. Ramp and Stripe built this infrastructure because nothing existed when they started. Today the landscape looks different. You do not need to start from scratch. The fastest path is to adopt the base infrastructure and focus your engineering time on the work that is specific to your organisation: the MCPs, the data restructuring, the integrations into your internal systems.

Organisations use Ona to:

• Automate code maintenance, legacy modernisation, and migrations by running fleets of agents across hundreds or thousands of repositories: dependency updates, CVE remediation, standards enforcement, framework migrations
• Automate code review by triggering agents on every PR to review changes, post feedback, and catch issues before a human reviewer looks at it
• Improve developer velocity by giving engineers parallel cloud environments with agents that write code, run tests, and open pull requests autonomously

Ona provides the full background agent infrastructure out of the box: