Sources: Background Agents Summit session pages and the YouTube talks (6-7 May 2026). Definition from background-agents.com. I used Ona’s summit recap and llms-full.txt as indexes. Where a talk, a session page, and other Ona pages disagree, I leave the disagreement in.
I have been treating coding agents as a laptop problem: more terminals, more worktrees, more parallel sessions. That is useful. It is also the wrong unit of scale.
The Background Agents Summit put a sharper name on the next layer. Thirteen talks, recorded 6-7 May 2026, from Stripe, Uber, Cloudflare, Harvey, Open Inspect, Genentech, incident.io, Monzo, AWS, Tessl, Ona, Nono, and software-factory.dev. The claim is not that agents write more code. The claim is that org cycle time stays flat until the work leaves the laptop.
I am reading this as a field review. The useful part is how independently these teams landed on the same runtime.
What a background agent is
background-agents.com draws a hard line.
A background agent is an AI coding agent that runs autonomously on cloud infrastructure, triggered by events, schedules, or system signals, in its own full toolchain environment, decoupled from the developer’s laptop and session. The developer is on the loop (review later), not in the loop (steer live).
“Agents running in the background on a laptop” are not background agents. Extra terminals are still localhost. That is the same distinction I keep coming back to in From Chatbots to Agents: autonomy is not a longer reply. It is a loop that can proceed without you sitting in it.
The false summit
Coding assistants make individuals faster. Org cycle time and DORA stay flat.
That is the false summit the site names. PRs flood in. Review queues grow. The same security patch still has to land across the repos nobody wants to touch. Individual speed compounds with the person. Organizational velocity does not, until the work is triggered, isolated, governed, and reviewed as a system.
I have seen this locally: a strong laptop agent makes me faster. It does not shrink the toil that lives in Slack, CI, and migrations.
Coding agent vs background agent vs CI
Three different machines, three different jobs.
| Coding agent | Background agent | CI | |
|---|---|---|---|
| Where | Laptop | Cloud | Pipeline runners |
| Trigger | Manual prompt | Event, Slack, ticket, schedule | Predefined pipeline event |
| Scope | One repo, one session | Across the SDLC | The steps you already wrote |
| Human | In the loop: watch, steer | On the loop: review later | Out of the reasoning path |
| Reasoning | Yes | Yes | No |
| New code | Yes, under your hands | Yes, as a reviewable artifact | No |
CI tells you a dependency is stale or a test failed. It does not decide what to change. A background agent can reason, write the fix, run checks, and open a PR. That is closer to the loop in Anatomy of an AI Agent than it is to a build script.
flowchart TB
subgraph Cloud["Background agent"]
direction LR
T1[Event / Slack / ticket] --> S1[Cloud sandbox] --> O1[PR or report]
end
subgraph Local["Coding agent"]
direction LR
T2[Manual prompt] --> S2[Laptop] --> O2[Local diff]
end
classDef blueClass fill:#4A90E2,stroke:#333,stroke-width:2px,color:#fff
classDef orangeClass fill:#F39C12,stroke:#333,stroke-width:2px,color:#fff
classDef greenClass fill:#27AE60,stroke:#333,stroke-width:2px,color:#fff
classDef purpleClass fill:#9B59B6,stroke:#333,stroke-width:2px,color:#fff
classDef tealClass fill:#16A085,stroke:#333,stroke-width:2px,color:#fff
classDef redClass fill:#E74C3C,stroke:#333,stroke-width:2px,color:#fff
class T1 blueClass
class S1 orangeClass
class O1 greenClass
class T2 purpleClass
class S2 tealClass
class O2 redClass
Five primitives, independently arrived at
Stripe, Uber, Harvey, Cloudflare, and Open Inspect did not coordinate. The site says they still converged on the same five primitives.
flowchart LR P1[Sandboxed execution] --> P2[Runtime governance] P2 --> P3[Context behind the firewall] P3 --> P4[Triggers] P4 --> P5[Fleet coordination] classDef blueClass fill:#4A90E2,stroke:#333,stroke-width:2px,color:#fff classDef orangeClass fill:#F39C12,stroke:#333,stroke-width:2px,color:#fff classDef greenClass fill:#27AE60,stroke:#333,stroke-width:2px,color:#fff classDef purpleClass fill:#9B59B6,stroke:#333,stroke-width:2px,color:#fff classDef tealClass fill:#16A085,stroke:#333,stroke-width:2px,color:#fff class P1 blueClass class P2 orangeClass class P3 greenClass class P4 purpleClass class P5 tealClass
- Sandboxed execution. Each run gets its own full toolchain: isolate, reproduce, tear down. Without this, agents share machine state and security teams veto the rest.
- Governance enforced at runtime, not by prompt. Deny lists, scoped credentials, audit trails, human review gates. A system prompt that says “please don’t delete files” is a suggestion.
- Context and connectivity behind the firewall. IAM roles, private registries, internal APIs, replicas. A sandbox that cannot reach the real system produces code that compiles and does not integrate.
- Triggers. Scheduled, event-driven, fleets (one task across many repos), swarms (many agents, one outcome). If every run starts with a typed prompt, you automated the work and not the workflow.
- Fleet coordination. One intent, many repos, progress tracked and results aggregated. Updating one repository is a coding-agent task. Updating hundreds is a fleet task.
The order matters. Sandbox without governance is a liability. Governance without internal context is a toy. Triggers without fleet coordination still leave the 500-repo change as a multi-week project.
What 13 companies actually ran
Each section links the Watch recording and the session page. I am not collapsing conflicting figures.
Stripe: Minions
Slack, Jira, or the web allocates a dev box. Blueprints handle the deterministic steps: lint, generated code, tests. The agent opens a PR. Humans still review. The line that stuck: “dev boxes were a strategy credit.” Stripe built reproducible environments for humans first. Agents inherited them.
The published numbers do not agree, so I am not picking one. The session page says a 30-million-line Ruby codebase. In the talk, Gray says thousands of PRs a week with zero human-written code, and a codebase of “hundreds of millions of lines.” Other Ona pages, including the February 2026 white paper, say 1,000+ or 1,300+ PRs a week and 100M+ lines.
Uber: start with toil
Minion (singular; Stripe’s is Minions). The path was DevPod, then Minion. Shepard handles migrations. Code Inbox routes review.
The talk says over 11% of all merge PRs across Uber. The Ona recap sometimes says “generated PRs.” Those are not the same denominator. I am keeping the talk wording.
The correction I needed: start with toil, not novelty. Validation-heavy fixes and cleanup before the impressive generation demo.
Cloudflare: 93% is the stack, not the factory
AI Gateway, Access, Backstage, Agents.md, MCP, one-command setup. A multi-agent reviewer is tied to machine-readable standards.
93% of R&D is on that AI engineering stack: about 4,000 people, 295 teams, 4,000+ Backstage repos. The talk treats full background / delegated cloud agents as the next phase, not the current bulk of that 93%. The measurement note I am keeping: feature velocity, not just PR count.
Harvey: Slack as the workspace
Spectre, a collaborative cloud agent. The Slack thread is the shared workspace for engineering, PM, research, and legal. A GitHub repo is treated as a legal matter. Scheduled agents cover dashboards and triage.
The bottleneck they name is alignment, not code generation: permissions, context, and follow-through that a laptop tab cannot carry.
Open Inspect: review becomes the constraint
Internal platform: Cloudflare as the control plane, Modal and Daytona sandboxes, OpenCode as the agent. First use cases: SRE triage, support, PM prototypes, self-serve analytics. Modeled after Ramp. Boots typically under 2 seconds, with a goal under 10 seconds. Images rebuilt about every 30 minutes.
The scaling note is blunt. Once the laptop is no longer the boundary, review capacity becomes the bottleneck.
Genentech: genomics, then the Specificity Paradox
A team of 4. Failed analyses fan out across hundreds or thousands of instances. Agents produce incident reports, daily summaries, and routine tickets, with controlled merges. Nightly self-evolution pulls from logs, Slack, and Confluence. One sprint: 189 tickets, about 122 by the bot. Triage that took hours or days dropped to minutes.
The Specificity Paradox: highly specific skills can make agents slower. A rigid debug skill took 2× longer.
incident.io: design the handoff surface
AI SRE. Slack-native investigation: pinned summaries, canvases, threaded progress with citations. MCP and Investigation Sync move context into the IDE and into local coding agents. Netflix, Etsy, and Skyscanner are named as customers. Hundreds of telemetry queries per investigation. A heads-up only if the agent knows something humans do not, and it is relevant, confident, and citable.
The product lesson is the handoff surface. A background agent that dumps a wall of text into a channel is not collaboration. The work has to be skim-able in Slack and usable where the engineer already works.
Monzo: constraints help agents
A regulated bank: 3,000+ microservices in a Go monorepo. Golden paths, static analysis, data-flow controls. Sandbox untrusted work. Govern MCP. Own the model interface instead of coupling to one vendor shell.
The surprise is directional. Regulation and opinionated platform defaults are usually framed as friction. Here they are the reason agents can be let in: the secure path is already the easy path.
AWS: dark factories
Requirement to orchestrator DAG to isolated sandboxes. Plan and code adversaries apply back pressure. Deterministic gates decide whether work moves. Failed work is fed forward as rework, not retry. He ran a live factory demo.
I am treating “dark factory” as an operating model, not a slogan: humans move to requirements, tool curation, and verification. The loop still needs proof.
Tessl: Context Development Lifecycle
Context now needs the same discipline as code: generate, evaluate with LLM-as-judge, distribute via registries, observe, manage drift.
This matches how I already think about repo instructions and evals. If the agent is steered by skills, specs, and AGENTS.md, those files are production artifacts. Drift is technical debt.
Ona: enforce below the agent
Leo Di Donato and Lorenzo Fontana: prompt-level guardrails fail. Agents reason around rules written at their own level. Enforce below the agent.
That is the same conclusion I landed on in bounded autonomy for Claude Code: a hook or a kernel policy holds when a classifier or a system prompt will not.
Nono: Enforce, Attest, Decide
Three layers. Enforce at the kernel. Attest steering files and policies with Sigstore. Decide / grant capability expansion over Slack. Merkle audit log.
Sandboxing is not a boolean. Useful agents request more access. The reviewable path for that request is the product.
software-factory.dev: the factory in public
Building a software factory in public. Most of the other talks describe internal platforms. This one is an inspectable loop: agents across planning, implementation, review, and operations, with the human on spec and taste.
First 10 days of Memo: 375+ merged PRs, about 68k LOC, 16 automations, median issue-to-close 38 minutes, 87% of PRs merged autonomously, 98% of executions factory-triggered.
Peer numbers outside the playlist
These are not summit talks. The site cites them as peer deployments. I am repeating only the published figures, with their sources.
| Company | System | Published figure | Source |
|---|---|---|---|
| DoorDash | Flux | 130,000 automated engineering tasks in one month; 25,000+ code reviews a week | DoorDash AI on X |
| Spotify | Background coding agent | 1,500+ agent PRs | Spotify Engineering |
| Abnormal | Nora | 200+ PRs a day | Abnormal Builders |
I am not treating these as comparable benchmarks. Different units: tasks, PRs, reviews, days versus months. Useful as existence proofs that the laptop is already the wrong runtime for some orgs.
Trigger to output
| Trigger | Company | Output |
|---|---|---|
| Slack, Jira, or web task | Stripe | Dev box run, blueprints, human-reviewed PR |
| Toil and migrations | Uber | Minion PRs; Shepard migrations; Code Inbox routing |
| One-command platform defaults | Cloudflare | AI stack adoption; multi-agent review against machine-readable standards; delegated cloud agents as the next phase |
| Slack thread as shared session | Harvey | Spectre run across eng, PM, research, legal; scheduled dashboards and triage |
| SRE, support, PM prototype, analytics | Open Inspect | Internal platform work; sub-2s typical boot; review as the next bottleneck |
| Failed genomics analyses, tickets, logs | Genentech | Triage, incident reports, daily summaries, controlled merges |
| Slack incident | incident.io | Cited investigation, canvases, IDE / local-agent handoff; heads-up only if new, relevant, confident, citable |
| Untrusted or regulated work | Monzo | Sandboxed run, governed MCP, owned model interface |
| Requirement | AWS | Orchestrator DAG, isolated sandboxes, adversarial review, deterministic gates |
| Context change or drift | Tessl | Generated, judged, registered, observed context |
| Agent trying to bypass a written rule | Ona | Enforcement below the prompt |
| Headless capability request | Nono | Kernel enforce, Sigstore attest, Slack decide/grant |
| Public factory loop | software-factory.dev | Inspectable SDLC run in the open |
What I am taking from this
The category is real enough that thirteen teams, under different constraints, described the same runtime. I am not taking the marketing destination (“self-driving codebase”) as a plan. I am taking the primitives.
Dev boxes before agents. Stripe said it out loud. Uber’s DevPod-to-Minion path is the same idea. If I do not have a reproducible environment, I do not have a background agent. I have a prompt with extra steps.
Start with toil. Uber, Open Inspect, and Genentech all picked work that already had a definition of done: triage, migrations, routine tickets, failed jobs. Novelty is a poor first customer.
Review is the scarce resource. Open Inspect said it. Stripe still has humans reviewing agent PRs. Cloudflare measures feature velocity because PR count will lie, and its 93% is stack adoption, not a finished delegated factory. If I automate authoring and leave review unchanged, I have built the false summit again.
Governance sits under the model. Ona, Nono, and Monzo agree from three directions: prompt rules fail, the kernel and attestation layer hold, and a regulated platform’s defaults are an accelerant. That is also why MCP has to be governed, not just connected.
Context is now an artifact. Tessl’s lifecycle is the formal version of what laptop agents already depend on. I will version, evaluate, and watch drift on the files that steer agents the same way I do for code.
The handoff surface is product work. Harvey and incident.io are not “put the agent in Slack.” They are designing a shared object that other humans, and other agents, can pick up later.
I am still running coding agents on a laptop. That is fine for work I want to steer. The question this summit leaves me with is narrower: which of my triggers already have a sandbox, a review gate, and a definition of done, and which ones I am still pretending are a longer chat.
References
- Background Agents Summit
- YouTube playlist
- background-agents.com definition and primitives
- llms-full.txt
- Ona summit recap
- February 2026 white paper
- Stripe: Watch · session
- Uber: Watch · session
- Cloudflare: Watch · session
- Harvey: Watch · session
- Open Inspect: Watch · session
- Genentech: Watch · session
- incident.io: Watch · session
- Monzo: Watch · session
- AWS: Watch · session
- Tessl: Watch · session
- Ona: Watch · session
- Nono: Watch · session
- software-factory.dev: Watch · session
- DoorDash Flux
- Spotify background coding agent
- Abnormal Nora
Comments