Building and Deploying Background Coding Agents at Scale

cognition · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Cloud coding-agent infrastructure

Cognition needed production background coding agents that could work autonomously in cloud environments, preserve state across software-development gaps, integrate with code review, and scale from local-assistant workflows to cloud execution.

Constraints:

Cloud agents need secure sandboxing and state management beyond a local IDE assistant.
Engineering tasks include asynchronous waits for CI, review comments, merge conflicts, and follow-up commits.
VM startup and sandbox readiness affect practical usability.
Agent-produced code must still fit GitHub, review, and merge workflows.

Architecture

The discussion frames a background-agent system as a control plane plus sandbox hands: the agent brain can run in a worker/control plane while a cloud sandbox or VM provides the development environment. The system integrates with GitHub, tracks pull requests, restores sandbox state, and supports moving between background and foreground workflows.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  developer[Developer] --> background-agent-ui[Background Agent UI]
  background-agent-ui --> control-plane[Control Plane]
  control-plane --> cloud-sandbox[Cloud Sandbox]
  cloud-sandbox --> repository-state[Repository State]
  state-restore-hooks[State Restore Hooks] --> cloud-sandbox[Cloud Sandbox]
  control-plane --> github-integration[GitHub Integration]
  cloud-sandbox --> github-integration[GitHub Integration]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Developer`	Human assigning and reviewing cloud-agent work.	`Background Agent UI`
`Background Agent UI`	Command center for starting, monitoring, and foregrounding agents.	`Control Plane`
`Control Plane`	Agent brain, orchestration, and session coordination layer.	`Cloud Sandbox`, `GitHub Integration`
`Cloud Sandbox`	VM or sandbox environment where code changes and tests run.	`Repository State`, `GitHub Integration`
`Repository State`	Restorable working tree and development environment state.	`Cloud Sandbox`
`GitHub Integration`	Tracks pull requests, comments, merges, and conflicts.	`Control Plane`, `Cloud Sandbox`
`State Restore Hooks`	Restore sandbox state when work resumes.	`Cloud Sandbox`

Data flow

A user starts a background coding task. The control-plane brain coordinates planning and tool use, the sandbox holds the development environment and repository state, GitHub integration opens and updates pull requests, and state restoration lets work continue after CI or review gaps.

“we'll have quote unquote the brain of the agent running in some type of worker uh control plane. That sandbox then is going to serve as the hands where the brain is basically operating and making tool calls into that environment to manipulate it. I guess other trade-off”transcript, stated

“uh control plane. That sandbox then is going to serve as the hands where the brain is basically operating and making tool calls into that environment to manipulate it. I guess other trade-off that you're making between the two”transcript, stated

Why this architecture

Cognition separates control plane from sandbox because cloud coding agents need both autonomous reasoning and realistic development environments. Keeping the sandbox as hands gives the agent full tool access, while the control plane manages orchestration, state, and integrations.

“needed like full VMs to be able to do these types of things. And especially nowadays where there's actually value in running the application and clicking around and sending you screen recordings of these things, like the value just”transcript, stated

“a sandbox uh environment setup. Open Inspect does have hooks as well where you can uh run a setup SH script that will pre-install everything. You can then pre-napshot that build so it starts instantly and then there is a a second”transcript, stated

Models used: Devin · Open Inspect · cloud coding agents

Scale

Devin commit percentages on all Devin repos went from 16% in January to 80% in March.
“on all Devon repos uh was 16% in January and now 80% in March. >> Yeah, [laughter] it's like uh it's a big shift right now. Um and so it makes sense that a lot of people are now thinking about you know”transcript, stated
Merged PR usage had grown 7x according to the discussion.
“has uh of PRs or our merged PRs has grown 7x since I I I forget what >> I think Dave uh maybe tweeted that. Yeah. Uh yes. >> Um it grew like 7x over like the last I think it was like 2 months, 3 months,”transcript, stated
Full VM requirements and cloud environments are recurring enterprise deployment needs.
“and VMs like we want as much of that logic to be shared as possible. So for our own practical purposes we try to share as much of it as possible.”transcript, stated

Alternatives considered (roads not taken)

Run the agent brain directly inside the sandbox.

Rejected because: That simplifies state but weakens security and makes the sandbox hold too much agent logic.

“doing that. The negative trade-off you're making is primarily security because the agent is running in that box. Unless you otherwise design it, all of your secrets need to go into that box as well. And given the nature of AI, it”transcript, stated

Use raw cloud VMs without optimized startup.

Rejected because: Boot time was too slow for practical background-agent workflows.

“off of raw VMs from cloud providers like EC2, the bootup time was so slow, I think. Uh, and especially the then like turning off the machines, saving them, and then be able to bring them back up again when the when you want Devon to wake up again later.”transcript, stated

Treat GitHub integration as optional.

Rejected because: Following comments, merge conflicts, and PR state is central to the background-agent loop.

“It will then uh if you have merge conflicts or whatever you have asked it to resolve it will then resolve it but it doesn't do it automatically yet.”transcript, stated

Patterns

`durable-execution` (coding agents)

Sandbox restore hooks preserve work across background-agent sessions.

“restore the state of the sandbox when it comes back”transcript, stated

`tool-use-orchestration` (software engineering)

The agent integrates with GitHub, sandboxes, review comments, and merge-conflict workflows.

“integrated into the system is a critical part of this background system.”transcript, stated

`human-in-the-loop-gate` (code review)

Humans still approve, merge, and foreground agent work.

“just click like approve. Okay, sort of start a background agent to go fix it.”transcript, stated

`safety-policy-enforcement` (sandboxing)

The discussion treats security as a core tradeoff in sandbox/control-plane placement.

“Docker containers not really a true security boundary”transcript, stated

Tradeoffs

Agent placement

Chose Control plane brain plus sandbox hands over All agent state inside the sandbox.

Rationale: This improves security and orchestration at the cost of more state management complexity.

“all of the state of that agent is actually in the box”transcript, stated

Isolation layer

Chose Full VM-style environments over Containers as the security boundary.

Rationale: The speakers explicitly call containers insufficient as a true security boundary.

“Docker containers not really a true security boundary”transcript, stated

Workflow mode

Chose Background and foreground handoff over Purely local or purely cloud agents.

Rationale: Users sometimes need to bring background work local to test and finish it.

“handoff from local to cloud is hard”transcript, stated

Gotchas (what bit them)

Where the agent brain runs is a security tradeoff.

Root cause: Running inside the sandbox keeps state simple but puts reasoning and secrets near untrusted execution.

Resolution: Move the brain into a worker/control plane and let the sandbox be the hands.

“actual agent running not directly in the sandbox”transcript, stated

VM boot time can make cloud agents feel unusable.

Root cause: Raw cloud VM startup is too slow for interactive handoff and background tasks.

Resolution: Use sandbox providers and snapshots/file-system formats optimized for fast spin-up.

“VMs could be spun up and down very quickly”transcript, stated

Background agents must be integrated into review systems.

Root cause: Code work is not done until PRs, comments, conflicts, and merges are handled.

Resolution: Build GitHub review hooks and PR tracking into the platform.

“It has a GitHub code reviewer that you can control the prompt.”transcript, stated

Evaluation

The discussion evaluates background agents through merged PR share, commit percentages, PR/comment tracking, merge speed, sandbox startup behavior, and real production use cases such as security scanning.

Metrics: Commit share · Merged PR growth · Merge time · PR comments · Sandbox startup time · Security scanning use cases

“monitor um the actual like pull requests being merged”transcript, stated

Outcomes

Devin commit share on its repositories rose from 16% in January to 80% in March.
Background agents are framed as critical infrastructure for future software engineering work.
The talk identifies VM isolation, state restoration, GitHub integration, and control-plane design as central platform requirements.

The transcript reports 16% to 80% commit share, 7x merged PR growth, full-VM requirements, state-restore hooks, and common use cases including continual security scanning.

“background agents are a thing now”transcript, stated