Ramp and Stripe ship 1,000s of agent PRs a week.
You can too.
They built the infrastructure from scratch. You don't have to. Ona gives you the same foundation out of the box: optimized environments, agent orchestration, and everything wired together so you ship product instead of plumbing.
Coding agents made individuals faster. Background agents make codebases self-driving.
A coding agent helps one developer write code. A background agent runs autonomously - triggered by events, working across repos, while your team focuses on review.
| Coding agent |  | |
|---|---|---|
| Where they run | Your laptop or local machine | Cloud infrastructure, triggered remotely |
| How they’re triggered | You invoke them manually | Events, schedules, Slack messages, API calls - any signal |
| Scope | Single task in one repo | Across repos, teams, and the full SDLC |
| Developer’s role | In the loop - watching, steering, iterating | On the loop - prompt, walk away, review the output |
Ona runs background agents out of the box - event-driven, parallel, autonomous. Read the full guide →
Your agent needs a real computer, not an API call
There are two ways to sandbox an agent. One gives it a full development environment. The other gives it a remote function call. The difference decides what your agents can actually do.
Agent has dev environment
The agent gets a full development environment - a VM running a dev container with your codebase, test suite, databases, and network access. This is how Stripe and Ramp run their agents. It's the closest to how a human developer works.
Sandbox as tool
The agent runs on a server. When it needs to execute code, it calls a remote sandbox via API. The sandbox runs the code and returns the result. Secrets and execution are somewhat isolated, but the agent can only execute code - not fully develop.
Agent has dev environment
The agent gets a full development environment - a VM running a dev container with your codebase, test suite, databases, and network access. This is how Stripe and Ramp run their agents.
Sandbox as tool
The agent runs on a server. When it needs to execute code, it calls a remote sandbox via API. Secrets and execution are somewhat isolated, but the agent can only execute code - not fully develop.
Ona uses Pattern 1. Every agent gets a full VM with your dev container, prebuilds, and services. Read: Don't build your own sandbox →
Agent sandboxes look simple. They're not.
“Just run Claude Code in a container” is the tip of the iceberg. Below the surface is months of infrastructure work that has nothing to do with your product.
Run Claude Code in a container
Stripe and Ramp had years and dedicated platform teams to build this. You don't have to. Read the full breakdown →
Not all background agents are the same
Building your own, using a code editor's cloud mode, and using a purpose-built platform are three very different things. Only one of them lets you focus on shipping product instead of continuously tuning agent infrastructure.
OnaDeclarative devcontainer.json with prebuilds, Docker Compose, and sidecar services. Same config, same result, every time.
You’re maintaining Dockerfiles, base images, prebuild pipelines, and sidecar orchestration per language and framework. Stripe had a dedicated team for this.
Universal images you can’t customize (Claude Code). Agent self-configures by reading your repo (Cursor). No internet or Docker (Codex). Persistent VMs that leak state (Devin).
Ephemeral, sandboxed environments are the safety system. Agents run without permission prompts — no babysitting required.
You’re building your own permission model, sandboxing, and blast-radius controls so agents can run unsupervised without risking your codebase.
Requires --dangerously-skip-permissions or prompts for every action (Claude Code). Autonomous but no Docker, no internet (Codex). Autonomous on persistent VMs without proper isolation (Devin).
Option to deploy in your VPC. Agents access internal services, databases, and APIs the same way your developers do.
You’re setting up VPCs, IAM roles, network policies, and tunneling so agents can reach internal databases, APIs, and gateways.
Agents run on vendor infrastructure outside your network. Can’t reach internal services, staging databases, or private APIs without tunneling workarounds.
See real-time changes in VS Code Web or jump into any IDE of your choice in a running agent’s environment. Make a tweak, hand back, keep going.
You need SSH access, log streaming, and a way to attach an IDE mid-session. Most teams skip this and debug by reading agent output.
See only the diff and test output (Codex). No user-facing environment spec (Cursor). Proprietary IDE only (Devin). No mid-session IDE access (Claude Code).
Hundreds of agents across repos, each in its own isolated VM. Runs while your laptop is closed.
Each agent needs its own isolated VM, scheduler, queue, concurrency controls, and cleanup logic. This is Kubernetes-level complexity for a problem that isn’t your product.
Git worktrees on one machine, no real isolation (Claude Code). One task per repo (Cursor). One cloud task at a time (Codex). Single-agent setup per server (Devin).
PR triggers, schedules, webhooks, and event-driven workflows — each running in a full, ephemeral dev environment.
You need webhook ingestion, event routing, cron scheduling, retry logic, and rate limiting per repo. Then you need to map triggers to agent configs.
GitHub Actions runners with no dev containers (Claude Code). Scheduled sessions on drifting VMs (Devin). PR-only auto-fix (Cursor). Local-only scheduled runs (Codex).
Every agent action logged. Cost per session, token usage, credentials accessed. Queryable audit trail built for compliance and productivity reporting.
You need structured logging, cost tracking, token attribution, and retention policies. Most teams skip this until an incident or a leadership ask forces the conversation.
CI-level logs only (Claude Code). Post-hoc session insights, no structured audit log (Devin). SOC 2 certified but no admin-level audit trail (Cursor). No audit logging (Codex).
Zero. Self-hosted, not self-managed. Continuously updated so you focus on product, not plumbing.
This is now a product you own. Security patches, kernel updates, storage driver upgrades — every sprint here is a sprint not spent on your product.
Zero — but you get what you get, and what you get is limited.
Real dev environments
Declarative devcontainer.json with prebuilds, Docker Compose, and sidecar services. Same config, same result, every time.
You’re maintaining Dockerfiles, base images, prebuild pipelines, and sidecar orchestration per language and framework. Stripe had a dedicated team for this.
Universal images you can’t customize (Claude Code). Agent self-configures by reading your repo (Cursor). No internet or Docker (Codex). Persistent VMs that leak state (Devin).
Full autonomy
Ephemeral, sandboxed environments are the safety system. Agents run without permission prompts — no babysitting required.
You’re building your own permission model, sandboxing, and blast-radius controls so agents can run unsupervised without risking your codebase.
Requires --dangerously-skip-permissions or prompts for every action (Claude Code). Autonomous but no Docker, no internet (Codex). Autonomous on persistent VMs without proper isolation (Devin).
Internal network access
Option to deploy in your VPC. Agents access internal services, databases, and APIs the same way your developers do.
You’re setting up VPCs, IAM roles, network policies, and tunneling so agents can reach internal databases, APIs, and gateways.
Agents run on vendor infrastructure outside your network. Can’t reach internal services, staging databases, or private APIs without tunneling workarounds.
Human handoff
See real-time changes in VS Code Web or jump into any IDE of your choice in a running agent’s environment. Make a tweak, hand back, keep going.
You need SSH access, log streaming, and a way to attach an IDE mid-session. Most teams skip this and debug by reading agent output.
See only the diff and test output (Codex). No user-facing environment spec (Cursor). Proprietary IDE only (Devin). No mid-session IDE access (Claude Code).
Parallel execution
Hundreds of agents across repos, each in its own isolated VM. Runs while your laptop is closed.
Each agent needs its own isolated VM, scheduler, queue, concurrency controls, and cleanup logic. This is Kubernetes-level complexity for a problem that isn’t your product.
Git worktrees on one machine, no real isolation (Claude Code). One task per repo (Cursor). One cloud task at a time (Codex). Single-agent setup per server (Devin).
Automations
PR triggers, schedules, webhooks, and event-driven workflows — each running in a full, ephemeral dev environment.
You need webhook ingestion, event routing, cron scheduling, retry logic, and rate limiting per repo. Then you need to map triggers to agent configs.
GitHub Actions runners with no dev containers (Claude Code). Scheduled sessions on drifting VMs (Devin). PR-only auto-fix (Cursor). Local-only scheduled runs (Codex).
Governance & observability
Every agent action logged. Cost per session, token usage, credentials accessed. Queryable audit trail built for compliance and productivity reporting.
You need structured logging, cost tracking, token attribution, and retention policies. Most teams skip this until an incident or a leadership ask forces the conversation.
CI-level logs only (Claude Code). Post-hoc session insights, no structured audit log (Devin). SOC 2 certified but no admin-level audit trail (Cursor). No audit logging (Codex).
Maintenance
Zero. Self-hosted, not self-managed. Continuously updated so you focus on product, not plumbing.
This is now a product you own. Security patches, kernel updates, storage driver upgrades — every sprint here is a sprint not spent on your product.
Zero — but you get what you get, and what you get is limited.
What changes when agents run in the cloud
Ship features from your phone
Parallelize your backlog
Automate the boring stuff
Onboard in minutes, not days
With Ona you can build your own software factory
The factory floor is running. Code is being written, reviewed, tested, deployed - continuously, autonomously. Your engineers are observing. Setting constraints. Verifying outcomes.
Most teams are stuck running coding agents on localhost. Ona gets you to the factory. Read the full guide →
Common questions
Stop tuning agent infrastructure. Start shipping product.
Environments, orchestration, parallelism, and model selection - already optimized and wired together. You focus on what to build. Ona handles how it gets built.