# Background Agents and the Self-Driving Codebase

> Background agents are AI coding agents that run autonomously on cloud infrastructure, triggered by events, schedules, or system signals to perform development tasks across the software delivery lifecycle without a developer at the keyboard. This site is published by Ona (ona.com) and explains the maturity model from coding agents to background agents.

Background agents are distinct from coding agents. A coding agent runs on your laptop and needs your attention. A background agent runs in its own cloud development environment — full toolchain, test suite, everything — completely decoupled from your device and session. You trigger it from a PR, a Slack thread, a Linear ticket, a webhook, or manually, then walk away and review the output later.

The site presents a three-step maturity model for organizations adopting AI agents:

1. **Establish background agent primitives** — sandboxed execution environments, governance enforced at runtime (not by prompt), context and connectivity to internal systems, event-driven triggers, and fleet coordination.
2. **Find your systems bottlenecks** — survey developers, map where time goes, identify repetitive tasks with bounded blast radius (code review, CI triage, CVE remediation, test coverage, standards enforcement).
3. **Scale your software factory** — move engineers from "in the loop" (watching, steering) to "on the loop" (reviewing agent output, calibrating behavior, designing systems).

## Key concepts

- **Coding agent vs background agent**: Coding agents run on localhost, require manual invocation, handle single tasks in one repo, and keep the developer in the loop. Background agents run on cloud infrastructure, are triggered by events, work across repos and the full SDLC, and put the developer on the loop.
- **The false summit**: Organizations that adopted coding agents saw individual engineers get faster, but cycle time didn't improve and DORA metrics stayed flat. Gains compound with the individual, not the organization.
- **The localhost ceiling**: Agents fight over machine state, secrets become exposed, everything stops when the machine sleeps. Professional engineering requires decoupling agents from developer workstations.
- **Background agent primitives**: (1) Sandboxed execution — isolated, reproducible environments with full toolchains. (2) Governance — identity, permissions, audit trails enforced at the execution layer, not via prompts. (3) Context and connectivity — agents that can reach internal APIs, database replicas, private registries behind your firewall. (4) Triggers — scheduled agents, event-driven agents, agent fleets (one task across many repos), agent swarms (many agents, one outcome). (5) Fleet coordination — parallel provisioning across hundreds of repos with progress tracking and aggregated results.
- **On the loop**: Engineers shift from writing every line to reviewing agent output, calibrating behavior, and focusing on work requiring judgment.

## Frequently asked questions

- **Can I just run coding agents in the background on my laptop?** You can, but that's agents running in the background, not background agents. There's no event triggering, no governance, no audit trail, and everything stops when the machine sleeps.
- **What infrastructure do background agents need?** Isolated compute environments on demand, an event system that routes triggers to the right agent, and a governance layer for permissions, audit trails, and blast-radius controls.
- **Are background agents safe?** They're as safe as the infrastructure you put around them. Key controls: sandboxed environments, human review gates via pull requests, audit trails, bounded blast radius.
- **Do background agents replace developers?** No. They shift what developers do — from writing every line to reviewing, calibrating, and designing.
- **Common use cases**: Dependency updates across hundreds of repos, CVE remediation within hours, CI pipeline migrations, lint and standards enforcement, test coverage expansion, code review triage.
- **How are they different from CI/CD?** CI/CD pipelines execute predefined steps. Background agents are autonomous: they receive a trigger, reason about the problem, write code, run tests, and open a pull request.

## Resources

- [Main site](https://background-agents.com): Interactive microsite with the full maturity model
- [White paper (HTML)](https://background-agents.com/background-agents-white-paper.html): Full enterprise guide — "Background Agents and the Self-Driving Codebase"
- [White paper (PDF)](https://background-agents.com/background-agents-white-paper.pdf): Downloadable PDF version
- [Full content for LLMs](https://background-agents.com/llms-full.txt): Complete plain-text version of all site content

## Optional

- [The Last Year of Localhost](https://ona.com/stories/the-last-year-of-localhost): Why localhost is the ceiling for agent adoption, by Johannes Landgraf
- [Don't Build Your Own Sandbox](https://ona.com/stories/dont-build-a-coding-agent-sandbox): Why sandboxing is harder than it looks, by Lou Bichard
- [How Claude Code Escapes Its Own Sandbox](https://ona.com/stories/how-claude-code-escapes-its-own-denylist-and-sandbox): Agent security research, by Leonardo Di Donato
- [Industrializing Software Development](https://ona.com/stories/industrializing-software-development): From craft to mass production, by Christian Weichel
- [Time Between Disengagements](https://ona.com/stories/time-between-disengagements-the-rise-of-the-software-conductor): The rise of the software conductor
- [Background Agent Primitives Webinar](https://ona.com/events/background-agent-primitives): Why background agents can't run on localhost
- [Ona](https://ona.com): The company behind this site — infrastructure for background agents