Async Agents Need More Than a Coding Model

From a specification to a shared work session

Give an agent a specification and ask it to return a completed pull request. When can you leave it working without constant intervention? One guest places the shift around December 2025, crediting Opus 4.5 and GPT 5.2, with an explicit condition: the specification has to be good enough. In that account, the models made background coding practical by carrying more of the task through to completion.

The Latent Space conversation brings together Walden Yan, introduced as Cognition’s co-founder and CPO, and Cole Murray, creator of [OpenInspect](https://github.com/ColeMurray/background-agents). Devin’s evolution illustrates another consequence of model progress: the transition to Sonnet 3.7 involved removing components that improved model intelligence had made unnecessary.

Internal usage reportedly changed sharply. A guest recalls roughly sevenfold growth in PRs or merged PRs over two or three months, alongside about 10% engineering headcount growth, while remaining uncertain about the exact metric and interval. Separately, a host describes Devin’s share of commits across Devin repositories rising from 16% in January to 80% in March. These are different measures of activity; neither establishes a sevenfold productivity improvement.

OpenInspect’s origin exposes a problem beyond code generation. A product manager could invoke an agent through Slack, but the session belonged to that person. When an engineer needed to take over, there was no accessible session to join—only copied text or the returned response. The work could be delegated to an agent but could not move cleanly between people.

OpenInspect grew from an existing experimental architecture. Ramp’s technical blog post then provided a basis for an implementation attempt with Claude, compared alongside GPT. Existing infrastructure and knowledge of how to verify the result helped. The motivation for releasing it was a perceived gap in open-source cloud agents: companies needed a foundation they could fork and customize as background agents became important infrastructure.

That framing shapes the commercial question. The OpenInspect account rejects competing at roughly $20 per seat when core features seem easy to copy and providers already capture value at the model and sandbox layers. Infrastructure and integrations might be offerings, but their monetization remains unclear. Devin’s commercial case includes operating the compute and helping companies adopt agents. Early cloud virtual machines (VMs) could leave Devin unavailable for roughly ten minutes during save-and-restore cycles; project planning and uneven familiarity with AI created further adoption obstacles.

Separate the decision loop from the execution machine

The first architectural choice is where to run the harness, the software executing the agent’s decision-making loop. It can live inside the sandbox—the environment where the agent runs and modifies code—or outside it, in a worker or control plane that operates the sandbox through tool calls.

The two arrangements make different trade-offs: - Inside the sandbox: agent state stays together, simplifying management. Unless explicitly protected, harness secrets are also exposed to activity in that environment. - Outside the sandbox: the decision-making system stays separate from the machine being modified, at the cost of more state-management work.

Devin is described as using this separation from the outset. It permits reuse of existing development machines without installing the harness’s dependencies and secrets on each one. A shared GitHub App illustrates the permissions problem: people using the same application can have different access rights. In the described design, narrowly scoped access on the execution machine defines what the user and agent can do, while the decision-making system remains inaccessible from that machine.

A sandbox still needs a working application

Once the harness can operate a machine, that machine must be useful. Cognition calls this repo setup: keeping dependencies current and making the application runnable and testable as the repository changes. Informal onboarding—asking a colleague for whatever access is missing—may get a human unstuck, but does not give an agent a reproducible setup procedure.

The VM-versus-container discussion distinguishes the agent’s execution boundary from the application’s supporting services. One speaker favors full VMs, citing container-isolation concerns and the complication of Docker-in-Docker when the application itself depends on Docker. Another recommends Docker Compose for supporting services because it reproduces engineers’ existing workflows. Their common ground is practical: a good local development environment makes agent setup easier.

OpenInspect’s preparation flow is: 1. Run a setup shell script to preinstall dependencies. 2. Snapshot the prepared environment for faster startup. 3. Run a second hook to restore sandbox state when it resumes. The aim is to make microservices available much as they would be on a developer’s machine. No startup latency measurement accompanies the description.

Platform requirements add another layer. The conversation raises macOS- and Windows-specific environments, then describes Android development support newly available in beta. Running an Android emulator inside a Firecracker VM introduced performance problems—a requirement the speaker tentatively describes as nested virtualization. A workable architecture still needs platform-specific engineering before it becomes a usable development environment.

Testing requires more than clicking

Computer use answers a narrow question: can the agent click the button it has decided to click? Testing a change requires determining which applications to start, which code versions must run together and which conditions make the changed behavior observable.

A change spanning a frontend, backend and deeper service may require administrator access, an enabled feature flag or two simultaneous sessions with a particular input sent to one of them. The testing team reports cases that no single frontier model could complete end to end, leading it to orchestrate different models. That reasoning and orchestration received more attention than the clicking, which recent models had made easier.

Background agents have useful material to reason from: the repository and the changes are present in their environment. In the Devin workflow discussed, approving testing after PR completion returns a video with a visible cursor and labels explaining what is being exercised. The annotations help reviewers understand the intended demonstration. One viewer wanted to merge directly from Slack after watching—an expression of confidence, rather than proof of correctness.

Review continues after the first PR. Devin receives GitHub comments and can address them; Devin Review can itself comment on a Devin-authored PR. Avoiding unproductive loops requires useful review comments and an implementing agent that can decide whether to fix or challenge them. OpenInspect’s reviewer has a configurable prompt, but follow-up work still requires explicitly tagging the GitHub bot, including for requested fixes and merge conflicts.

Integrations must handle the conversation

Launching sessions is only the beginning of company integration. Useful context may live in production logs, databases, Confluence or internal knowledge bases. Connecting those systems makes access control and compliance part of the agent’s design.

Slack shows why tool access alone is insufficient. An agent that can post messages still needs incoming webhooks, appropriate responses and restraint during long threads. The Devin account describes custom integration work to support that back-and-forth without flooding conversations.

Richer, bidirectional behavior also complicates the promise of a simple connection: supporting many variations can begin to resemble building first-party integrations anyway. The participants suggest judging by frequency and importance. An integration used in nearly every session may deserve direct ownership, so the company can tune the experience beyond an off-the-shelf implementation.

Memory needs scope, retrieval and revision

Memory remains unresolved in the OpenInspect discussion, with clients using skills or instruction files to bridge the gap. Storing guidance is only part of the problem; the agent must retrieve the right guidance when it matters.

Devin’s early Knowledge system starts with ordinary corrections. If a user corrects how the agent uses Git, Devin can propose remembering the lesson and offer a quick approval or rejection. The participant describing it recalls, uncertainly, that roughly 95% of memories came from generated suggestions. No measurement period or methodology is given, but the design motivation is clear: few users want to write extensive instruction documents.

A one-time request is not a lasting preference. Asking for one draft PR should not make every future PR a draft for everyone. A useful memory might instead capture one person’s general preference. Retrieval must then select among thousands of memories without filling the context with irrelevant material. The Devin account describes substantial evaluation work to keep this reliable as underlying models change.

When preferences change, Devin can propose editing the stored memory. That is the mechanism described in response to a question about forgetting; automatic age-based pruning is not specified. A filesystem-like memory interface is also under exploration, motivated by agents becoming better at navigating files themselves.

Persistent memory could support a continuing role rather than a single task. An ongoing experiment gives an agent a document such as memory.md and asks it to act as a product manager in a Slack channel: maintaining priorities, tracking ownership and potentially creating tickets for humans or other Devins. A weekly competitor-research automation exposes the missing feedback path: its user must manually add unwanted suggestions to the prompt to prevent repeats. Learning automatically from rejected PRs remains a feature request.

Coordination needs more than additional agents

As OpenInspect becomes more integrated, its control plane has more to manage. Initially, each integration lived in its own package, with the Slack bot forwarding webhook activity to the control plane. Centralizing GitHub handling is under consideration because open PRs, merges and comment activity describe the health of the whole system. Some newer tools already call back into the control plane to keep secrets out of the sandbox; moving the harness itself outside remains a future direction.

OpenInspect can reportedly launch subsessions, create separate environments and monitor them. With an external harness, child sessions would also run in the worker plane. The remaining coordination question is how the parent should interact with them.

Walden reports that giving Devin tools to message other Devins arbitrarily and create new ones produced chaotic coordination. The most practical arrangement remained one lead agent partitioning work among subordinate agents, each on its own machine to reduce conflicts.

He distinguishes sustained collaboration from a delegated lookup. A subagent can find a file or implementation and return an answer, keeping its intermediate searches and tool calls out of the main agent’s context. That is useful context management, but behaves much like a tool call. His optimism about deeper collaboration rests on agents becoming willing to disagree: agents with different information must reconcile their views of the correct implementation.

Walden also reports surprising results from letting one Devin run for an extended period on ambitious tasks, including a request described as rebuilding a Windows OS system. The scope and verification criteria are unspecified. His broader position is measured: multi-agent systems are an important direction, but enthusiasm may exceed their current incremental capability gains. Another participant wants much greater parallelism while acknowledging that adding reviewer agents can compound poor output.

The repository teaches the next agent

An internal experiment stacked AI-generated changes through automatic merging, with no code review. The participant’s informal December assessment was that maintainability became difficult after roughly two weeks; no model, year or formal evaluation protocol is specified. The telling symptom was a button-color change: the button existed in about ten places, with variations easy to miss. The response was to introduce review and ongoing cleanup.

The failure can reinforce itself. An unchecked implementation becomes repository context, and the next agent treats it as an example of how the codebase works. A long if/else chain becomes a pattern to copy; duplicated date-formatting helpers keep proliferating. Scheduled cleanup, by humans or systems that detect duplication, is proposed as a way to interrupt that cycle.

A complementary proposal places the strictest control at module contracts. Teams can tolerate bounded duplication inside a module while requiring clear interfaces and human sign-off for changes between modules. Agents get room to work within boundaries that remain deliberate architectural decisions.

Infrastructure determines how fast autonomy feels

Slow grep searches illustrate the value of infrastructure expertise. Other agent builders reportedly pursued custom search indexes. Devin’s infrastructure team traced its problem to a network-backed filesystem with data in S3: searches incurred network calls. The eventual fix was to replace that filesystem.

A separate block-diff storage format addressed VM suspension and startup. Its motivating example is a terabyte disk on which an agent adds only a hundred lines of code. Incremental layers let saving and restoring perform work proportional to the filesystem changes. The participant says this reduced startup time, but the implementation had already been replaced by a newer internal system. No timing measurements are given.

Owning both agent and infrastructure is presented as a deployment advantage: Cognition can work toward customer-specific cloud, on-premises or government-cloud environments without waiting for an underlying provider. OpenInspect uses Cloudflare for its control plane and Modal for sandbox execution. Daytona support had been contributed, E2B remained on the roadmap, and a provider abstraction was intended to accommodate further backends.

Modal receives praise for snapshots, GPU availability and convenient container workloads when full VMs are unnecessary. Language choice introduces another trade-off. Using one language across frontend and backend allows shared type definitions, while a participant finds many relevant libraries—especially for observability—remain Python-first. JavaScript can run inside Modal, but is described as involving an extra step. These are workflow preferences and ecosystem impressions, rather than language-adoption measurements.

Make quality constraints executable

Recurring generated-code patterns can become explicit checks. Speakers report unnecessary defensive attribute access in Python where they would prefer an error to surface. They speculate about training data and incentives to avoid failures, without establishing a cause. One consultant describes enforcing a lint rule against the unwanted access pattern so the PR fails instead of preserving it.

Comments present a less clear-cut case. One speaker observes Opus 4.7 writing long explanations of design decisions, alternatives and reasons for rejecting them. The volume feels excessive, but preserving that reasoning beside the code might help future agents maintain it. A verbosity setting is floated as a possibility. GitAI offers another approach in the discussion: storing agent prompts in Git metadata so later agents and review bots can recover context without filling source files with lengthy explanations.

Other reported patterns include awkward import/export arrangements to preserve compatibility in GPT-generated code and increasingly Claude 4.6, plus weakly typed structures and indiscriminate Any. Semgrep and linting are proposed to constrain recognizable patterns. The explanation that models are trying to avoid failure remains speculative; the actionable step is to turn an observed quality problem into a check.

The repository-level recommendation returns to local verification. Provide a local database and supporting services through tools such as Docker Compose and Postgres so the agent can implement, run and test without depending on live systems. An internal effort is described to make core components testable entirely locally. Migration can be harder for large, older microservice systems, although systems designed for local operation from the start may avoid that difficulty.

One proposed project would observe network traffic and use those interactions to generate local mock servers. No implementation or coverage results are offered. The goal is to make more of an application’s behavior available for the agent to exercise in its own environment.

Bring work forward when people need to inspect it

The Windsurf 2.0 discussion focuses on testing speed. An agent can test independently and send a video, but difficult cases still require pulling work down locally. The proposed command-center experience is to bring one agent’s work forward for review, move others into the background, test the change and launch another background fix from the same window.

Local and background agents need different behavior. In the team’s preferred design, a local agent responds quickly and leaves decisions to the person beside it. A background agent keeps working through testing so its next message contains what the user needs. The team still tries to share implementation logic across both modes, especially support for Git providers, operating systems and execution machines.

Incident triage is described by one participant as the easiest and most common cloud-agent use case they encounter. An agent can respond to an alert by collecting logs, database context and relevant playbooks before a human arrives. It need not resolve the incident to be useful, though the workflow may produce a PR. OpenInspect supports Sentry and generic webhook triggers; Datadog is presented as an integration someone could add.

The same access supports several other workflows: - Product requests: product managers ask for small fixes through Slack and receive PRs. - Customer support: staff tag an issue, let the agent collect diagnostic context, then bring engineering into the conversation with fewer requests for more information. - Security work: agents perform continual scanning and review.

Devin’s auto triage direction aims to begin investigating incoming alerts and bug reports immediately, keeping findings and follow-up questions in Slack. A chat interface with codebase access also makes technical answers available to support and sales staff who may find a command-line interface difficult to use.

Use expensive capability where it matters

The budget discussion produces differing anecdotes, not a spending benchmark. One participant commonly hears figures of 1,000–5,000 per engineer and has not encountered 50,000; another has seen spending that high. Neither currency nor billing period is specified.

A closing prediction is that expensive frontier models will coexist with users deciding they do not need the strongest available capability for much of their work. Hybrid model execution could serve both needs: fast, efficient models below the frontier call on frontier models when necessary. Retaining frontier-level performance for much of the work is the aspiration; no performance measurements accompany the proposal.

The conversation closes with an invitation to companies pursuing more autonomous coding to discuss using Devin or working with its team. The hiring appeal emphasizes product engineers with strong taste, especially people who have shipped products they are proud of. The consulting offer addresses organizations adopting tools such as Cursor or Claude Code: substantial work remains between deploying a background agent and integrating it throughout the company.