Building and Deploying Production Cloud Agents for Software Engineering

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: Production cloud software-engineering agents

Cognition needed cloud agents that could safely run real software-engineering workloads for enterprises, preserving full machine state across asynchronous SDLC gaps while scaling to thousands of concurrent sessions.

Constraints:

Untrusted code execution needs stronger isolation than containers.
Engineering work has idle gaps while agents wait on CI, reviews, and follow-up comments.
Sessions need to resume with memory, processes, filesystem, dependencies, and runtime state intact.
Enterprises must change planning, review, staffing, and quality processes around agent-produced work.

Architecture

Cognition built Devin cloud agents on VM-level isolation, microVMs with dedicated kernels, hypervisor-level full-machine snapshots, and orchestration for provisioning, demand prediction, crash recovery, and teardown across thousands of concurrent VMs. The company also emphasizes organizational adoption: engineer fluency, planning changes, and new review standards.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  engineer[Engineer] --> cloud-agent[Cloud Agent]
  cloud-agent --> microvm-session[MicroVM Session]
  microvm-session --> hypervisor-snapshotter[Hypervisor Snapshotter]
  microvm-session --> developer-tool-stack[Developer Tool Stack]
  cloud-agent --> orchestration-layer[Orchestration Layer]
  orchestration-layer --> microvm-session[MicroVM Session]
  enterprise-sdlc[Enterprise SDLC] --> engineer[Engineer]
  cloud-agent --> enterprise-sdlc[Enterprise SDLC]

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

Components

Component	Role	Interacts with
`Engineer`	Human directing, reviewing, and deciding on agent work.	`Cloud Agent`
`Cloud Agent`	Autonomous software-engineering agent running in the cloud.	`MicroVM Session`, `Orchestration Layer`
`MicroVM Session`	Dedicated-kernel execution environment for each workload.	`Hypervisor Snapshotter`, `Developer Tool Stack`
`Hypervisor Snapshotter`	Captures and restores full machine state across async gaps.	`MicroVM Session`
`Developer Tool Stack`	Browser, desktop applications, dependencies, and arbitrary tools.	`MicroVM Session`
`Orchestration Layer`	Provisioning, demand prediction, crash recovery, and teardown for VM fleets.	`Cloud Agent`, `MicroVM Session`
`Enterprise SDLC`	Planning, CI, code review, and shipping processes adapted to agent work.	`Engineer`, `Cloud Agent`

Data flow

A cloud agent starts in an isolated VM, works on a repository with full browser and tool-stack access, snapshots full machine state when idle, shuts down compute during async gaps, resumes when CI or review events arrive, and is orchestrated across large fleets of VMs.

“Our own implementation of microVMs took over a year of hypervisor engineering, ensuring every agent session runs on its own dedicated kernel with fully isolated storage, networking, and compute. A side benefit is that agents running in dedicated VMs can use a full browser, desktop”article, stated

“We solved this by snapshotting full machine state at the hypervisor level — memory, process trees, and filesystem. Compute shuts down while the agent is idle, and the session resumes exactly where it left off when a CI result or review comment arrives.”article, stated

Why this architecture

Cognition argues that containers cannot safely or durably support enterprise cloud agents. VM isolation addresses untrusted code, and hypervisor snapshots address the asynchronous reality of software engineering work without burning compute while idle.

“The industry consensus for running untrusted code is VM-level isolation — each workload gets its own kernel, with no shared attack surface. This is the direction the broader infrastructure community has been moving toward.”article, stated

“The root issue is that containers do not provide a reliable way to snapshot an individual container's full state, shut down compute, and restore it later.”article, stated

Models used: Devin · cloud agents

Scale

Cognition's microVM implementation took over a year of hypervisor engineering.
“Our own implementation of microVMs took over a year of hypervisor engineering, ensuring every agent session runs on its own dedicated kernel with fully isolated storage, networking, and compute.”article, stated
The orchestration layer can manage thousands of concurrent VMs.
“Our solution for the orchestration layer took over three quarters of dedicated engineering to build and can manage thousands of concurrent VMs — handling provisioning, demand prediction, crash recovery, and teardown.”article, stated
The orchestration layer took over three quarters of dedicated engineering.
“Our solution for the orchestration layer took over three quarters of dedicated engineering to build and can manage thousands of concurrent VMs — handling provisioning, demand prediction, crash recovery, and teardown.”article, stated
Itaú reported 5 to 6x faster migrations, 70% security-vulnerability auto-remediation, and 2x test coverage.
“completed migrations 5 to 6x faster, auto-remediated 70% of static-analysis security vulnerabilities, and increased test coverage by 2x.”article, stated
The Itaú deployment involved nearly 17,000 engineers after eleven months.
“> Itaú, the largest private bank in Latin America, is eleven months in with nearly 17,000 engineers — and has completed migrations 5 to 6x faster, auto-remediated 70% of static-analysis security vulnerabilities, and increased test coverage by 2x.”article, stated

Alternatives considered (roads not taken)

Use containerized agents as the main isolation boundary.

Rejected because: Containers lack reliable full-state snapshotting and are weaker for untrusted-code isolation.

“Another problem with containerized agents is they cannot survive the async gaps that define most real engineering work. An agent opens a PR, waits on CI, responds to code review, reruns tests, and pushes a follow-up commit.”article, stated

Keep agents alive through idle gaps.

Rejected because: That burns compute and still loses sessions on reschedule, timeout, or crash.

“A containerized agent can only survive async breaks by burning compute to stay alive — and if the container is rescheduled, times out, or crashes, the session is lost.”article, stated

Treat deployment as infrastructure only.

Rejected because: Enterprise planning, staffing, review, and quality standards must change too.

“When agents are doing a significant share of the execution, those processes need to be rebuilt around a different operating model. One where agents execute and humans direct, review, and decide.”article, stated

Patterns

`safety-policy-enforcement` (sandboxing)

Each workload gets VM-level isolation with its own kernel and isolated compute/storage/networking.

“each workload gets its own kernel, with no shared attack surface”article, stated

`durable-execution` (agent runtime)

Hypervisor-level snapshots preserve full session state across async SDLC gaps.

“session resumes exactly where it left off”article, stated

`human-in-the-loop-gate` (enterprise SDLC)

Humans direct, review, and decide while agents execute more of the work.

“agents execute and humans direct, review, and decide”article, stated

`observability-tracing` (operations)

The orchestration layer handles provisioning, demand prediction, crash recovery, and teardown.

“handling provisioning, demand prediction, crash recovery, and teardown”article, stated

Tradeoffs

Isolation boundary

Chose VM-level isolation over Container-only isolation.

Rationale: Untrusted code needs separate kernels and no shared attack surface.

“no shared attack surface”article, stated

State persistence

Chose Hypervisor full-machine snapshots over Keeping containers alive through idle gaps.

Rationale: Snapshots avoid burning compute and preserve state through CI/review delays.

“Compute shuts down while the agent is idle”article, stated

Enterprise rollout

Chose Process redesign around agents over Dropping agents into existing human-only SDLC.

Rationale: Planning, staffing, and review assumptions change when agents execute significant work.

“Every assumption about team sizing, sprint capacity, and project staffing changes”article, stated

Gotchas (what bit them)

Containers cannot preserve full engineering session state.

Root cause: They cannot reliably snapshot memory, process trees, and filesystem for one workload.

Resolution: Snapshot full machine state at the hypervisor level.

“containers do not provide a reliable way to snapshot an individual container's full state”article, stated

Agent code volume changes review economics.

Root cause: More code needs review, but human-authored review processes do not transfer cleanly.

Resolution: Create new review and quality standards for agent-produced work.

“review process designed for human-authored code doesn't transfer cleanly”article, stated

VM-based agent infrastructure is a multi-quarter investment.

Root cause: Isolation, snapshotting, orchestration, and fleet management must all be built and maintained.

Resolution: Staff dedicated teams for layers of the stack.

“dedicated team to manage each layer of this stack”article, stated

Evaluation

Cognition evaluates cloud-agent readiness through isolation guarantees, snapshot reliability, concurrent-VM orchestration, enterprise adoption metrics, migration speed, vulnerability remediation, test coverage, and review-quality practices.

Metrics: Concurrent VMs · Snapshot reliability · Migration speed · Security remediation · Test coverage · Engineer adoption

“increased test coverage by 2x”article, stated

Outcomes

Cognition built microVM isolation and hypervisor snapshots for cloud agents.
The orchestration layer manages thousands of concurrent VMs.
Itaú reported 5-6x faster migrations, 70% auto-remediation, and 2x test coverage after eleven months.

The source reports over a year of hypervisor engineering, over three quarters for orchestration, thousands of concurrent VMs, and Itaú's nearly 17,000 engineers with 5-6x migrations, 70% remediation, and 2x test coverage.

“Making this work reliably across thousands of concurrent sessions”article, stated