An engineering leader's guide to background agents

Background agents are reshaping how engineering teams work, but it's still early. Different patterns are emerging, and no two companies are approaching it the same way. Six companies, including Stripe, Ramp, Spotify, Uber, Harvey, and OpenAI, have published detailed accounts of what they built, the use cases they focused on, and the outcomes they achieved.

Their approaches differ in revealing ways. For instance, Stripe, Ramp, and Uber all built interfaces for developers to kick off multiple agents in parallel, with the engineer reviewing the output rather than writing the code. Spotify however, took a different path by slotting agents into their existing fleet automation to run large-scale code migrations across thousands of repos. Harvey, on the other hand is rethinking the engineering process itself, building toward a Figma-like model where engineers, product managers, designers, and even lawyers collaborate together in a shared agent session, not just firing off prompts but reshaping how the whole organization works together.

Below, we summarize what each team did, then look across all six to answer common questions: which use cases deliver the fastest ROI, how much engineering investment this takes, what technical building blocks matter, and what every team got right.

Your first use case can make or break your background agents initiative. Go too ambitious, and you risk losing momentum before you prove value. Pick something too small or irrelevant to the business, and you will struggle to earn the funding and confidence to keep going. The right use case meets coding agents where they are today: repetitive, well-scoped work with clear success criteria and real business value. Below are examples from organizations already using background agents, and the use cases they started with.

Technical teams often rush past business cases and buy-in. They start a proof of concept, wire up an open-source stack, and pick the closest available use case because it lets them move without waiting for procurement or leadership approval.

That can work in the short term, but it creates a real long-term risk: the initiative can be technically successful and still get shut down because budget holders do not understand what it is for, why it matters, or how success should be measured. Background agents have real costs attached to them, so success needs to be tied to an outcome leadership already cares about.

Before you can scale the work, you need to sell the organization on the vision. Below are example slides you can use to shape that story.

We've watched dozens of teams attempt this transition. The ones that stall share common patterns. Here are the traps that keep coming up.

Trap 1: Starting too big. Don't try to automate your entire SDLC on day one. Pick one use case, prove it works, and expand from there. The teams that succeed start narrow and go deep before going wide.

Trap 2: Treating agents like junior developers. Agents aren't interns. They don't need hand-holding, but they do need clear specifications. The teams that succeed invest in context engineering (structured AGENTS.md files, clear repo conventions, good test suites), not vague prompts.

Trap 3: Running agents on laptops. Running agents on a developer's laptop or a Mac Mini is a dead end. You need isolated, reproducible environments with proper network boundaries and credential scoping. This is the infrastructure problem that Ramp and Stripe solved first, before they even thought about agents.

Trap 4: No observability. If you can't see what your agents are doing, you can't trust them. And if you can't trust them, you'll babysit them, which defeats the purpose. You need audit logs, cost tracking, and usage analytics from day one.

Trap 5: Trusting agent-level security. As you increase agent autonomy, the temptation is to rely on deny lists and permission boundaries defined at the agent level. The problem: agents can reason around their own constraints. Prompt-level guardrails don't work. If the guardrail lives inside the same context window as the agent, it's a suggestion, not a boundary. Security enforcement needs to happen at the infrastructure layer (network policies, kernel-level controls, scoped credentials) where the agent has no ability to override it.

Trap 6: Waiting for the perfect model. The model is not the bottleneck. Context, tooling, and infrastructure are. Teams that wait for the next model to "get good enough" are optimizing the wrong variable. The teams shipping today are shipping because they invested in the surrounding infrastructure, not because they have access to a better model.

You've worked through the playbook. Pick the action that fits where you are right now.