Cognition argues enterprises should buy, not build, cloud agents
Cognition's team draws on two-plus years building Devin's cloud agent infrastructure to argue that most enterprises underestimate the depth of investment required to build their own cloud agents in-house.
Score breakdown
Engineering leaders evaluating whether to build or buy cloud agent infrastructure should weigh this breakdown of the hidden costs — VM isolation, async state management, and enterprise governance — before committing internal resources.
- 01The Cognition Team draws on over two years of building cloud agent infrastructure for Devin to make their case.
- 02Stripe's cloud agent, a commonly cited build-your-own example, was built on top of pre-existing dedicated EC2-based cloud development environments most enterprises lack.
- 03Containers share a host kernel, meaning a kernel-level escape by an agent could expose all co-located containers' filesystems, credentials, and network connections.
The Cognition Team published a blog post making the case that enterprises converging on cloud agents for software engineering should buy rather than build their own infrastructure. Using Stripe's widely-cited homegrown cloud agent as a reference point, the post argues that Stripe's success was built on a pre-existing foundation of dedicated EC2-based cloud development environments — infrastructure most enterprises have not invested in. For companies starting from scratch, the natural entry point of containerizing a CLI agent and moving execution to the cloud introduces a distinct set of hard problems.
The industry consensus, and Cognition's own approach with Devin, is VM-level isolation, where each workload gets its own kernel.
The post identifies three major technical gaps. First, containers share a host kernel, creating a security risk specific to agents that generate and execute arbitrary code — a kernel-level escape could expose every co-located container's filesystems, credentials, and network connections. The industry consensus, and Cognition's own approach with Devin, is VM-level isolation, where each workload gets its own kernel. Second, real engineering work is asynchronous — agents must open PRs, wait on CI, respond to review comments, and resume work hours or days later. Containers cannot reliably snapshot and restore full working state, meaning a containerized agent must burn compute to stay alive across async gaps or risk losing the session entirely. Third, running agents at enterprise scale demands orchestration (provisioning per-session environments, managing warm VM pools, keeping environments current), governance (identity chaining, access scoping, tamper-evident audit logging), and deep system integrations.
The post's central argument is not that building in-house is impossible, but that the time cost is prohibitive: by the time an enterprise finishes, competitors using purpose-built cloud agent platforms will have moved significantly further ahead in transforming how they build software.
Key facts
- 01The Cognition Team draws on over two years of building cloud agent infrastructure for Devin to make their case.
- 02Stripe's cloud agent, a commonly cited build-your-own example, was built on top of pre-existing dedicated EC2-based cloud development environments most enterprises lack.
- 03Containers share a host kernel, meaning a kernel-level escape by an agent could expose all co-located containers' filesystems, credentials, and network connections.
- 04The industry consensus for running untrusted code is VM-level isolation, giving each workload its own kernel — the approach Cognition took with Devin.