A security scan flags 200 vulnerabilities across 47 repositories. But your team is only six people. Each one of those tickets needs a package bump, a test run, and a PR that someone has to open by hand. By the time you finish triage, three new CVEs have landed.

This is the kind of engineering toil that often starts with mechanical steps, even when final review still requires judgment: dependency bumps, vulnerability patches, CI fix-ups, and ticket triage.

Background coding agents, or background agents, take the manual kickoff and first-pass toil out of the workflow. You assign a task, the agent works in its own environment while you do something else, and a reviewable pull request shows up when it's done.

In this article, we'll explain what a background coding agent is, walk through how it operates inside an isolated environment, look at the tasks it handles well and the ones it doesn't, and lay out the setup decisions that determine whether the pull requests it produces are worth merging.

What is a background agent?

A background coding agent runs a scoped software task asynchronously in a separate execution environment and returns a reviewable result, usually a pull request, diff, summary, or investigation. Instead of steering the agent turn by turn, you define the task, set the boundaries, and review what comes back.

The line between coding assistants and coding agents has blurred. Many tools now support multi-step edits, tool calls, repository context, and test execution. But the practical distinction still matters: are you actively driving the work, or is the agent running a task on its own after a trigger or schedule starts it?

Interactive agent work happens while you are present. You prompt the agent, watch the changes land, correct the direction, and decide what happens next. Background agent work is different. A GitHub issue assignment, CI failure, Slack request, cron schedule, or other engineering event can start the run. The agent works in its own environment, such as a cloud sandbox, remote VM, or self-hosted backend, then returns an artifact for human review.

The category is changing quickly. Anthropic's 2026 Agentic Coding Trends Report describes the task horizon stretching from one-shot bug fixes that took minutes in early 2025 to agents working for days at a time by 2026. The work an agent can hold in its head is growing, but the handoff stays the same: assign, walk away, review the PR.

That is the shift background agents introduce. They do not remove human judgment from software development. They remove the manual kickoff and first-pass toil from repeatable work, so developers and platform teams can focus on the review, approval, and higher-judgment decisions that still need a person.

How a background coding agent works

Every background agent runs inside an execution environment it owns: a sandboxed VM or container isolated from your local machine and your credentials. Treat that execution environment as a hard security boundary.

For instance, GitHub Copilot's cloud agent runs in a fully isolated environment hosted by GitHub, and Claude Code's sandbox runtime lets users define the directories and network hosts an agent can access through sandbox access controls.

Contrast this with a cloud coding agent platform like OpenHands, which operates as the layer above individual agents like Claude Code and Codex. The platform runs agent activity in containerized sandboxes and iterates a reason-and-act cycle until the task is done or it returns the work for human review. You can then manage those agents through Agent Canvas, the OpenHands interface, without changing your existing model or workflow.

Inside that environment, the agent runs autonomously. It reads the codebase, writes code, runs tests, and verifies against CI before it commits to anything. For instance, OpenHands agents ship changes end-to-end and return an artifact for your team to review.

Runs can start from all kinds of triggers, such as:

• A manual kick-off

• A GitHub issue assignment

• A Jira or Linear ticket label

• A Slack mention

• A cron schedule

• A CI failure event

Whatever the trigger, a background run should produce a reviewable artifact, typically a PR or diff, along with the logs, commits, and summary the platform exposes. Humans stay in the loop by reviewing PRs and handling the judgment calls the agent flags.

What tasks are background agents best at?

Use agents for mechanical, well-scoped, repeatable work that doesn't require live judgment. The agent either solves it cleanly or surfaces a reviewable draft. Start with bounded, repeatable work such as migrations or test generation, especially where success can be checked automatically. Event-driven outer-loop work fits when the same action needs to happen every time something occurs in GitHub, Jira, Slack, or CI.

A few use cases land here consistently:

• Automated code review: The agent reviews every PR for security issues, breaking API changes, best practices, and code smells before a human reviewer opens it. Over time, teams can expand the agent’s role from summarizing and flagging issues to proposing fixes or enforcing known review patterns, while keeping human reviewers responsible for final approval.

• Dependency upgrades: The agent can open PRs across affected services on a schedule when the upgrade pattern is narrow enough to verify. A human reviews the diff and merges after CI passes. This is useful when upgrades require code-level awareness.

• Vulnerability remediation: The agent can scan for CVEs and open PRs with package patches across every repo without per-service manual triage. OpenHands has a Fix Vulnerabilities workflow template for scheduled vulnerability scans and fix PRs across affected services.

• CI/CD fix-up: The agent responds to a failing build, identifies the root cause, and opens a fix PR without pulling the responsible engineer out of flow. CI failure fixes are a standard output for agentic workflows.

• Ticket resolver: A Jira or Linear ticket gets labeled, the agent picks it up, implements the change, and opens a PR. The loop closes without manual initiation.

• Incident triage: An observability alert fires, the agent investigates the relevant services, and posts a root-cause summary back to the incident channel.

• QA and regression testing: The agent generates and runs test suites against changed code before a PR reaches review. This catches regressions that would otherwise slip through at merge time.

Background agents still struggle with tasks requiring live product judgment, changes that need real-time back-and-forth, and logic not specified in the ticket. The benchmark data backs this up. In the SWE-Bench Pro evaluation, the models it tested, including GPT-5 and Claude Opus 4.1, scored below 25% on that benchmark's complex, multi-file enterprise tasks, against over 70% for the same models on the well-scoped, single-issue tasks in SWE-Bench Verified.

The tasks where agents fall short are exactly the ones that require more nuanced judgment a ticket can't capture. So scope your agent to what it does well. Leave everything else for a human.

Why teams should move from local prompting to background agents

Prompting an agent manually on your laptop, one task at a time, still puts you in the loop for every action. Developers using local agents typically see significant productivity gains, but these are still bounded by their own attention. As long as you're steering the agent, it can only move as fast as you can supervise it.

Background execution breaks that ceiling. When the agent runs autonomously in the cloud, it gets kicked off by an event or a schedule, not by a human. It no longer occupies space in your brain, and tasks run in parallel while you work on something else. The productivity model changes. Instead of speeding up the work a developer is actively doing, background agents can move repeatable work forward while the developer is focused elsewhere.

Once execution is asynchronous, recurring SDLC work becomes a candidate for agent workflows, such as code review, CI/CD fixes, vulnerability remediation, ticket handling, and incident or observability response. These are the outer-loop tasks that run continuously in the background because a PR opened or a build failed, not because a developer kicked them off.

The end state teams are building toward is what practitioners call dark software factories, or codebases where agents handle all routine maintenance and humans set product direction and tune the agents. Background agents running on a schedule and in response to events are how you start getting there.

Spotify's Honk project shows what this looks like at scale. Honk is Spotify's internal background coding agent, designed to apply code changes across thousands of repositories in their GitHub Enterprise repository environment. As of the first post in their engineering series, it had merged over 1,500 pull requests. That is outer-loop work running at a volume no team could match by manual prompting.

Best practices for designing and managing background agents

Setup determines whether an agent merges clean PRs or produces noise. Spotify's Honk team published a public account of getting this right at scale, and these practices come from production experience.

Write tight, single-purpose prompts

Limit your prompts to one scope per run, with explicit conventions and scope boundaries. A prompt such as "make this code better" gives the agent no verifiable goal. Bundling related changes into one elaborate prompt is more likely to exhaust context or produce a partial result. Agents that drift outside the prompt produce PRs that cost more to review than to write yourself.

Cover the target code with tests before the agent touches it

Tests are the agent's primary self-correction mechanism. It generates code, runs the suite, reads the failures, and fixes its own work.

Low test coverage is a direct failure mode caused by nonsensical PRs that are expensive to review. No safety net means the agent ships confident-looking broken code.

Wire verification loops into execution

Verification checks should run before the PR opens. Martin Fowler splits these into two categories:

1. Computational verifiers that are deterministic and fast (tests and linters)

2. Inferential verifiers that are slower and non-deterministic (semantic analysis or LLM-as-judge)

A robust setup combines both layers. A deterministic verifier blocks the PR if required checks fail. On top of that sits an LLM-as-judge layer that evaluates the diff against the original prompt, catching cases where the agent drifts outside the instructions in the prompt, the most common failure mode. When the judge flags an issue, the agent often course-corrects on its own before the PR ever reaches a human.

Watch the cost, as frequent verifier runs can increase token usage. Start with a slower cadence and scale up only once the loop produces work you actually merge.

Sandbox with scoped permissions

Agents should never run with broad developer credentials. Enforce least privilege per run. IEEE USA's zero-trust guidance calls for task-scoped credentials with least privilege and automatic revocation upon task completion. The Cloud Security Alliance's Agentic Trust Framework, a governance specification for autonomous agents rather than a description of any single product, calls for agents to authenticate as non-human principals (not under a user's credentials).

For example, OpenHands' Control Plane enforcement defines this at the highest level so every agent runs with explicitly defined permissions and never inherits broad developer credentials, with all activity confined to isolated runtimes.

Validate on one repo before scaling

One agent drifting is a prompt problem. But hundreds of drifting agents is an infrastructure problem. Agents tend to work fine in isolation but struggle to produce mergeable PRs reliably once you scale to broader use cases like cross-repo migrations.

Begin with a small pilot and measure the PR quality and defect rate of one agent. Then expand only after the control layer is in place. Do not scale until sandbox isolation is in place and required checks are auditable.

Encode the stable pattern as a reusable skill

Once a workflow holds up, encode it as a reusable skill so the team's conventions travel with the workflow on every run. Think of it as a maturity ladder, where a one-off prompt becomes a reusable skill, which then becomes an automation that runs on a schedule or event.

How OpenHands runs background agents at scale

OpenHands is built for the full journey from local to cloud. Start with Agent Canvas, the local-first interface that connects OpenHands, Claude Code, Codex, and Gemini CLI from one workspace. When you're ready to move execution off your laptop, connect to OpenHands Cloud or a self-hosted backend. The execution environment changes, while your workflow remains the same.

For teams scaling to hundreds of agents across dozens of repositories, the Agent Control Plane adds the infrastructure to run that at production with sandboxed Kubernetes runtimes, scoped least-privilege permissions, full audit logs tied to users and workflows, and cost attribution across teams.

Build background agents into your long-term engineering workflow

Background agents give you a different operating model for the outer loop, including the review, fix-up, patch, and migration tasks that fill your team's week without requiring their judgment. Adding a control layer makes them production-ready. This layer implements tests so the agent can self-correct, verification loops so bad diffs don't reach review, scoped permissions so agents never run with credentials they don't need, and audit trails so you can prove what ran and why.

Most teams hit the same wall: one agent on a laptop works fine. Running hundreds across an organization is a different problem. Who can run them, what can they access, what did they change, and what did it cost? Without a control plane, those questions don't have answers.

OpenHands is open source, model-agnostic, and MIT-licensed, and every reasoning chain and execution step is inspectable. That matters for regulated teams that need to prove to a security reviewer what an agent did and why. The same Agent Canvas interface spans local usage through enterprise deployment, so you never switch tools or learn a new UX as usage scales.

Try Agent Canvas and run your first automation locally, or request a demo when you're ready to run agents across your org with the control your security team requires.

Frequently asked questions about background coding agents

How is a background agent different from an agentic IDE mode like Cursor or Claude Code?

An agentic IDE mode like Cursor or Claude Code runs with you present: multi-step changes, in real time, on your machine. A background agent runs in its own cloud environment, picks up a task from a trigger, and hands you a PR when it's done. One keeps you in the loop for every change, while the other runs the work while your attention is elsewhere.

Teams use both. Claude Code or Codex on the command line handles work you're actively steering. Background agents running on OpenHands handle the outer-loop work that needs to run while you're not watching to cover every PR, failing build, and labeled ticket. For example, OpenHands runs Claude Code, Codex, and Gemini CLI as agent runners inside Agent Canvas via the Agent Client Protocol, so you keep your existing tools and subscriptions and add background execution on top.

Do background agents replace code review?

They complement code review by running a first pass before a human reviewer opens the PR, catching security issues and breaking API changes consistently. Humans still handle logic and judgment calls. Authentication, authorization, cryptography, and data validation should always receive manual review. The agent removes the wait-time bottleneck, but the reviewer still makes the final call.

Is it safe to let a background agent run against a production codebase?

A safe setup runs the agent in a sandbox with scoped least-privilege permissions, against code with test coverage, and requires a reviewable PR before merge. Agents should never inherit broad developer credentials. With OpenHands Enterprise, agents can run in strongly isolated containerized runtimes deployed on your own Kubernetes infrastructure inside your VPC (virtual private cloud), so source code never leaves your environment, and every action is logged and tied to a user and workflow for audit.

Can background agents run on a schedule, or only when triggered manually?

Both. For instance, OpenHands automations run on cron-style schedules or in response to real engineering events, like a PR opened in GitHub, a label added in Linear, an alert from monitoring, or a Slack mention. You define the workflow once and let it run on the schedule or trigger that fits the task, whether that's a weekly dependency sweep or an on-demand ticket resolver.

About OpenHands

OpenHands is the open-source platform for building and running AI coding agents, with the interface, automations, and control layer needed to go from a single local agent to a system running across an entire organization. The mission is to make agent-based software development accessible, transparent, and controllable by default. That starts in the open. The core framework is open source, giving developers and platform teams full visibility into how agents execute work and interact with their systems. The project has over 78,000 GitHub stars, 9 million downloads, and contributions from hundreds of developers. OpenHands is used by engineers at large enterprises and fast-growing startups to build, run, and scale AI coding agents across real software engineering workflows. The long-term vision is to become the full stack AI coding agent platform for software engineering. Not just helping developers write code, but running meaningful parts of the software lifecycle.