OpenNash builds background coding agents and the agent-first API layer behind them, on your code and in your environment. See how we build it for you, or read more about OpenNash.
A background coding agent takes a task from Slack, a ticket, or an alert. It works in a cloud sandbox and returns a tested pull request for a person to review. Ramp, Stripe, Spotify, and Shopify each built one, and agents now write between half and three quarters of merged code at some of them. The model is not what makes these agents work. The API layer around them is. Each company gave its agent governed access to every system an engineer uses: code, telemetry, feature flags, tickets, and data. Most enterprises do not have that layer yet. OpenNash Software Factory builds it, and then builds the agent on top.
What a Background Coding Agent Is
An IDE assistant helps one developer, on one laptop, while the developer watches. A background agent works on its own, in the cloud, and many run at the same time.
| IDE assistant | Background coding agent | |
|---|---|---|
| Where it runs | The developer's laptop | A cloud sandbox per task |
| Who starts it | A developer in an editor | Anyone, from Slack, a ticket, a web page, or an alert |
| How many at once | One or two | As many as the work needs |
| What it returns | Suggested edits | A tested pull request with evidence |
| What it can reach | What the laptop can reach | What the company connects it to |
The last row is the important one. A background agent is only as useful as the systems it can reach.
What Leading Companies Report
Four companies have published first-hand numbers.
| Company and agent | Published result | How it runs | Source |
|---|---|---|---|
| Ramp, Inspect | 74% of merged pull requests; 99% of engineering, design, and product staff used it in the past month; 3.4x pull requests per builder vs a year earlier | Sandboxed VM per session, wired into Sentry, Datadog, LaunchDarkly, Braintrust, GitHub, Slack, and Buildkite | Ramp Builders blog, January 2026; Karim Atiyeh on X, October 27, 2026 |
| Stripe, Minions | More than 1,300 merged pull requests a week, each one reviewed by a person | Devbox ready in about 10 seconds; internal tool server with nearly 500 tools | Stripe, Minions Part 1 and Part 2, February 2026 |
| Spotify, Honk | More than 1,500 merged pull requests; 60-90% time saved on migrations | Small, fixed tool set: a verify tool, a limited git tool, and allow-listed shell commands | Spotify Engineering, November 2025 |
| Shopify, River | From 6% to 61% of merged mobile pull requests | Remote mobile dev environment; the agent attaches screenshots and recordings | Shopify Engineering, October 2026 |
Ramp's growth was fast. Inspect wrote about 30% of merged pull requests in January 2026. A Modal case study put it at about half in February. Ramp's co-founder Karim Atiyeh put it at 74% in October. He also wrote that there "wasn't a mandate to use it." People saw teammates solve problems in shared sessions and started their own.
Stripe grew from more than 1,000 merged pull requests a week in its first post to more than 1,300 ten days later. Spotify reports that its Fleet Management system, which now includes the agent, has automated about half of its pull requests since mid-2024.
All four companies keep a person in the loop. The agent writes and tests. A person reviews and merges.
The Same Six Parts at Every Company
The companies use different vendors, but the architecture is the same.
| Part | What it does | How the leaders did it |
|---|---|---|
| Sandbox | Gives each task a full, isolated dev environment that starts in seconds | Ramp rebuilds repository images every 30 minutes. Stripe keeps pools of warm devboxes in a QA environment with no production data and no internet access. |
| Session API | Keeps the state of each task, streams progress, and lets several people work in one session | Ramp gives each session its own database. Every prompt records who sent it. |
| Clients | Lets people start work where they already are | Slack is the top entry point at Ramp and Stripe. Stripe also adds a start button to its docs, feature flag, and ticket tools. |
| Tools | Lets the agent read and act on company systems | Stripe's Toolshed server hosts nearly 500 tools. Each agent gets a small default subset. |
| Verification | Proves the change works before a person looks at it | Stripe allows at most two CI rounds, then hands the branch to a person. Shopify and Ramp attach screenshots and live previews. |
| Review and audit | Makes sure no code merges without a second person | Ramp opens each pull request with the requester's own GitHub token, so nobody can approve their own change. |
Ramp names one metric above the others: the share of sessions that end in a merged pull request. It counts value delivered, not activity.
The Hard Part Is the Agent-First API Layer
The sandbox and the session API are well-known engineering. Ramp published a full spec, and hosted sandbox products exist. The tools are different. They connect the agent to your systems, and no vendor can build them without you.
Ramp states the goal plainly. It built Inspect so that the agent "is never limited by missing context or tools, but only by model intelligence itself." For backend work, Inspect can run tests, review telemetry, and query feature flags. For frontend work, it checks its changes visually. Stripe's rule is shorter: "if it's good for humans, it's good for LLMs, too."
That access is the agent-first API layer. It is the set of governed interfaces that let an agent read data and take actions across your systems, as a named user, with every call logged.
Most enterprises do not have this layer
In Postman's 2025 survey of more than 5,700 developers, only 24.3% said they design APIs with AI agents in mind (Postman, State of the API 2025). Gartner predicts that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025 (Gartner, August 2025). The agents are arriving faster than the interfaces they need.
The gap is widest in old systems. An ERP on IBM i, a claims system in COBOL, or a .NET service with no logs gives an agent nothing to read and nothing to test against. We described this in why enterprise AI stalls on legacy systems. The foundation layer in that post and the agent-first API layer here are the same work. One layer serves your coding agents, your business agents, and your new services.
What the layer contains
| Part | What it gives the agent | Example |
|---|---|---|
| Read APIs over systems of record | Current data, scoped to the user's role | Orders, inventory, claims, customer records |
| Scoped action APIs | Writes with limits, a dry-run mode, and retry safety | Create a ticket, update a status, stage a refund for approval |
| Event feeds | What changed, and when | Changes to key tables, batch job results |
| Telemetry and flags | Proof that a change works in a running system | Errors, logs, traces, feature flag state |
| Test environments and golden data | Somewhere safe to run the change | A QA copy of the database, recorded real inputs |
| Tool catalog | One governed place to find and grant tools | An internal MCP server, like Stripe's Toolshed |
| Identity and audit | Who asked, which agent acted, what it touched | SSO per user, a log of every read and call |
Design rules for agent-first APIs
An agent-first API is not the old API with a new name. Anthropic's engineering team warns against "tools that merely wrap existing software functionality or API endpoints" (Anthropic, Writing effective tools for agents). These rules come from the published work:
- Build tools around tasks, not endpoints. One tool that finds a customer and their open orders is better than three calls the agent must chain.
- Return only what the agent needs. Anthropic recommends pagination, filtering, and truncation. Large responses fill the agent's context and push out the task.
- Start each agent with a small tool set. Stripe gives each agent a small default subset of its tools. Spotify goes further. It keeps its agent "very limited in terms of tools and hooks," because each extra tool is one more source of unpredictable failures.
- Make writes safe to retry. Give every action an idempotency key and a dry-run mode. An agent that retries must not charge a card twice.
- Run every call as a person. The agent acts with the permissions of the person who asked, never as a shared super-user.
- Log everything. Record each read, each call, and each result, so auditors and engineers can replay what happened.
- Keep production out of the sandbox. Stripe's devboxes run in a QA environment with no real user data. Mistakes stay inside one devbox.
For a deeper look at tool design, see MCP search and execute.
A Worked Example: One Bug, End to End
This is how one task moves through a background agent with a full API layer. The company is a distributor with a web portal over an older order system.
- The alert. Error tracking reports a spike in failed checkouts for one region. An engineer types "fix this" in the Slack thread with the alert.
- The repository. A fast model reads the thread and the channel name and picks the portal repository. Ramp uses this classifier pattern, with an "unknown" option that asks the user.
- The sandbox. A warm sandbox starts from an image built in the last 30 minutes. The agent can read files at once.
- The context. Through the API layer, the agent reads the error traces, the recent deploys, and the feature flag state. It queries the order system's read API and finds that the region's tax code is missing in one table.
- The fix. The agent adds a fallback for a missing tax code and a test that reproduces the failure with a recorded real order.
- The proof. Tests and lint pass in CI. The agent attaches a screenshot of a successful checkout in the sandbox.
- The review. The agent opens a pull request with the evidence and posts the link in the Slack thread. An engineer reviews and merges it. A second engineer joins the session and asks for a flag around the fix. The agent adds it to the same pull request.
Without step 4, the agent has only the code. It can guess at the cause. It cannot prove the fix.
Build, Buy, or Extend
Model vendors and code hosts offer hosted coding agents. Ramp is now opening Inspect to other companies. Stripe and Ramp still chose to build their own first. Stripe's reason was its codebase: an uncommon stack and many in-house libraries that are "natively unfamiliar to LLMs." Ramp's reason was ownership: "it only has to work on your code."
| Your situation | Our recommendation |
|---|---|
| Common frameworks, standard SaaS tools, small team | Use a hosted agent. Spend the effort on tests and review rules. |
| Large codebase, unusual stack, or strict data rules | Build or extend a harness that runs in your environment. |
| Many internal systems, or old systems with no API | Build the agent-first API layer first, whichever agent you choose. |
| You need the agent to reach production data | Do not do this. Give it read APIs over replicas and QA copies instead. |
The last two rows apply to every company. You can rent the agent. You cannot rent an API layer over your own systems.
What Changes When Agents Write Most of the Code
Code review becomes the limit. At QCon London 2026, Spotify engineers said Honk merged 1,000 pull requests every 10 days, and that human review was now the bottleneck (InfoQ, March 2026). Atiyeh draws the same conclusion: the bottleneck is now "our own judgment: which ideas we act on and what we decide should ship."
Plan for review from the first week:
- Make every pull request carry its own evidence. Test results, screenshots, and the data the agent used. See how Meta and Shopify verify AI-generated code.
- Scale CI with the agents. More pull requests means more CI runs. See the CI bottleneck from AI coding.
- Set a merge-rate target. Track the share of sessions that end in a merged pull request, by team and by task type.
- Write down who signs. Each repository needs a named reviewer group for agent work.
The same pattern applies to old code. AI cut the time to write migration code, and verification became the main cost. We covered the numbers in AI made code cheap; verification is now the cost of legacy modernization.
When This Is the Wrong Choice
- You have no tests. An agent with no tests has no way to prove a change. Write characterization tests for the code it will touch first.
- Nobody will review. If reviewers are already the bottleneck, more pull requests make it worse. Fix review capacity first.
- Security will not grant read access. Without governed access to telemetry and data, the agent works blind. Solve access before you choose an agent.
- The work is a one-off. A single small change is faster by hand. The return comes from many tasks and repeated migrations.
How OpenNash Builds This for You
Ramp, Stripe, and Spotify had platform teams to build their agents. Most companies do not have a spare team for this. OpenNash Software Factory gives you the same result on your code, in your environment. It runs on Codex, Claude Code, GitHub Copilot, or open-source agents, under your review rules. A forward-deployed engineer (FDE) works inside your team, on site when it matters.
A typical engagement:
- Embed an FDE with your engineering, security, and platform leads. In week one we pick one repository and one task type with a measurable result, such as dependency upgrades or error-tracker fixes.
- Build the agent-first API layer. Governed read APIs over your systems of record, telemetry and flag access, test data, and one tool catalog with per-user identity and audit logs. For old systems with no API, this is the foundation layer from our legacy modernization work.
- Set up the sandboxes. Pre-built images of your repositories, refreshed through the day, with no production access.
- Connect the clients. Slack, your ticket system, and your alerts, so anyone can start a task where they already work.
- Wire in verification. Your CI, your tests, visual proof for front-end changes, and pull requests opened as the person who asked.
- Ship the first workflow in 4-8 weeks and report the merged-PR rate and the hours saved.
- Scale to legacy code. Use the same agents and the same API layer to map, test, and modernize old systems in waves.
You own the code, the tools, and the API layer at handover. Software Factory runs on the same flat monthly fee as every OpenNash offering, month to month, with no per-seat pricing and no consulting hours.
Book a call with an OpenNash forward-deployed engineer or email us at hello@opennash.com. In the first session, we map which of your systems an agent can reach today and which it cannot. Then we pick the first workflow with the highest business value and the fastest ROI.