I have reorganized the content of this podcast of Latent Space. It is worth taking a look at the in-depth discussion and sharing related to asynchronous Agent. I also highly recommend listening to this podcast. Original text: Latent Space "The Age of Async Agents — Cognition's Walden Yan & OpenInspect's Cole Murray" Source: https://www.latent.space/p/cognition Note: This article is compiled and translated based on the original text and the complete podcast verbatim draft, retaining the main points, cases and technical details, and rewritten into a structure suitable for Chinese long text reading. In the past year, the focus of discussion on AI coding is changing. In the early days, we talked about completion, Copilot, and pair programming in IDEs. Later, it became local agents such as Claude Code, Codex, and Cursor. Developers handed over tasks to the model in the terminal and editor and let it search, modify, run, and interpret. Now, the conversation is turning in another direction: asynchronous agents. It is no longer just sitting next to developers, waiting for your orders. It's put in the cloud, with repositories, development environments, shells, browsers, test systems, logs, knowledge bases, permission boundaries, and review loops. You give it a task, it continues to work in the background, and finally hands back pull requests, test evidence, screenshots, videos, or troubleshooting conclusions. This is also the judgment that Cognition and OpenInspect have repeatedly talked about in this dialogue: what really makes background agents come true is not just the model capability, but the entire engineering system surrounding the model. Why Everyone Is “Building Their Own Devin” Cole Murray observes that the engineering community is collectively realizing the value of background and cloud agents. Around December 2025, models such as Opus 4.5 and GPT 5.2 crossed a capability threshold: as long as the specification is good enough, the model can already go from a requirements description to a pull request with a high degree of completion. This incident changed the relationship between developers and agents. In the past, people had to constantly support the model while walking. Now, more and more tasks can be handed over to the agent itself. Developers have changed from "people who gradually accept completion" to "people who give tasks, review results, and adjust the system." Walden Yan of Cognition also mentioned that this change can already be seen in Devin’s internal data. Devin's number of merged PRs grew ~7x in just a few months, while the engineering team only grew ~10%. In Devin's own warehouse, the proportion of commits contributed by Devin increased from 16% in January to 80% in March. Noteworthy changes: The previous question was: "Should I stay in the IDE and stare at the model all the time?" Now the question becomes: "Which work can be thrown directly to the cloud and let the agent complete it by itself?" This change also explains why many companies have started to build Devin themselves. Large agent companies are rushing forward, and enterprises also want to have a background agent system that suits their own permissions, processes, code bases and compliance requirements. OpenInspect emerged in this context. When Cole first saw customers using tools such as Claude and OpenAI Codex, the biggest friction point was not necessarily the model capabilities, but the collaboration method. Many teams start Claude sessions through Slack, but the session is bound to the identity of the initiator. If the PM initiates a task and later wants an engineer to take over, the engineer will not be able to see the complete session and will have to copy and paste the context. This is almost unusable for real team collaboration. So he started to build a cloud background agent system. After Ramp published the article introducing the internal agent system, Cole found that he already had many components, so he used Claude to quickly reproduce a system based on the article content and open sourced it as OpenInspect. His judgment is straightforward: the background agent system is likely to become a critical infrastructure within the company. Since it is infrastructure, teams should be allowed to fork, transform, and connect to their own systems instead of locking everything in a SaaS. What does the Agent company really sell? A very real question is: If everyone can create their own background agent, what exactly does a company like Cognition sell? Walden's answer has several layers. The first layer is of course the Devin product. The second layer is the infrastructure around Devin. The third layer is the engineering services, integration capabilities and organizational implementation experience that help enterprises truly adopt AI coding agents. In the early days, Devin did not have mature infrastructure available. Cognition can only build a machine environment directly based on original VMs such as EC2, which is slow to start, save, and restore. After the machine is turned off and then waked up to Devin, it may take ten minutes to start cold. This type of cloud infrastructure is not designed for "agents to go online and offline frequently, save Status, continue working" this mode is designed. So Cognition had to do a lot of agent infra itself. The product boundary here is very important: selling a coding agent is not just about selling a model interface that can write code. You're also selling compute environments, permission models, sandboxes, security perimeters, recovery speed, enterprise integration, onboarding and adoption. This is especially true for large enterprises. Many people want to move their daily engineering work to AI, but not every team is familiar with AI workflow, and not every project is naturally suitable for agents. Cognition's work also includes helping customers connect integrations, automations, permissions, and project processes so that the team can actually use it. This is why agent products priced at $20 per seat are not easy to make. Cole believes that if it is only sandwiched between the model layer and the sandbox layer, the commercial space will be awkward: some people make money in the model layer, and players such as Daytona, E2B, and Modal also make money in the sandbox layer. If the middle layer does not master enough stacks, it can easily become a gray area that is difficult to price. The architectural watershed of background agent: Where to place the harness? For the background agent system, an infrastructure question is: Where does the agent run? Common sayings are: harness in the box: the agent runs directly in the sandbox or VM harness out of the box: the agent's brain runs on an external worker or control plane, and the sandbox is only called as hands. This is not a purely aesthetic choice, it will directly affect security, state management, permissions and system complexity.
- The biggest advantage of harnessing the agent in the box is simplicity. The status of the agent is all in the machine, and the files, environment, and execution traces are more localized. You have fewer system boundaries to manage. The problem is security. If the agent runs in the box, many secrets will also enter the box. AI behavior is uncertain, and it is theoretically possible to send secrets by mistake or perform unexpected behavior. This is difficult to accept in a corporate environment.
- Harness out of the box By placing the agent brain outside the box and using the sandbox only as hands, the decision-making system can be separated from the execution machine. The agent can control the sandbox through tool calls, but the secrets, permissions, and brain do not have to be all exposed to the machine. The price is complexity. State needs to be managed across systems, the control plane needs to be designed more rigorously, and tool invocation, permissions, logging, and recovery need to be reconsidered. Walden said Devin has been designed with a "brain and machine separation" from the beginning. In this way, the secrets placed on the machine only represent what the machine can do; the brain itself is not exposed to the machine, and it is easier for enterprises to restrict agents with minimum permissions. Architecture judgment: For serious enterprise scenarios, out of the box is usually more complex, but also more suitable for long-term evolution. It separates the agent's intelligence, machine execution environment and permission boundaries, leaving room for security and compliance. What is really difficult is repo setup. Many people underestimate the environmental issues of background agent. Letting the agent write code is only the first step. The real trouble is: can it run your code base? Can dependent services be started? Is it possible to obtain the necessary but restricted credentials? Can it be tested in a development environment that is close to real? Cognition internally calls this repo setup. Cole said a large part of his consulting work is helping teams plug this hole. Many companies do not have a reliable development environment setup. The real situation is often: "Go to Bob to get the secrets." This kind of human flesh process is completely unavailable to the agent. To make the agent work, the team needs to answer at least these questions: Can the full application be launched locally or in a sandbox? How to orchestrate microservice dependencies? Are there any local replacements for databases, caches, queues, and search services? Are there scoped versions of secrets? Can the setup script be run with one click? Can the environment be snapshotted and restored quickly next time? Can the agent run tests without touching production credentials? Docker Compose is a foundation many teams already have. But Walden also reminded that Docker is not a complete security boundary, and many real applications already rely on Docker. If you let the agent run in Docker, you will encounter complex problems such as Docker in Docker. This is why Devin needs a full VM. When the agent not only changes the code, but also actually runs the application, clicks on the interface, generates screenshots and records the screen, the value of the complete machine environment will continue to increase. Testing is much more difficult than computer use. Many people understand "AI can test applications" as computer use: the model sees the interface, sends out coordinates, and clicks the button. Walden believes this is only a small part. The real difficulty of testing lies in solving the problem: if you change a function that spans front-end, back-end and internal services, the agent must first figure out how to start the application, how to connect each service with the correct version, how to trigger the function, which permissions or feature flags must be turned on, whether to open two sessions to send messages to each other, and how to judge whether the results are really correct. These require code base context and orchestration. In some scenarios, Cognition found that a single frontier model could not even complete end-to-end testing independently, and different frontier models needed to be combined to solve the problem. The focus here is not "whether it can click the button": the focus is whether the agent can understand the system behavior, activate the necessary environment, construct the test path, observe the results, and generate credible evidence. A typical experience of Devin is: after the PR is completed, the user clicks on the test confirmation, and the system will send back a video. The video not only records the interface operations, but also annotates what is being tested. Swyx mentioned that this kind of proof will lead to a strong "I know it works" moment: you may not even want to go to GitHub to look at the code anymore, just want to merge directly in Slack. But to achieve this, there are many details behind it: The test path must be pushed out by the agent itself. Videos or screenshots must be able to explain "what it is verifying." PR comments must be understood and processed by the agent. AI reviewers cannot make low-signal comments. The agent cannot be trapped in a loop by reviewing itself. When the user's requirements are unreasonable, the agent must dare to point out problems. These details will ultimately affect one indicator: how quickly the code can be merged. GitHub, Slack, and Enterprise Integration: MCP Isn’t Enough MCP brings a lot of integration imagination. Give the agent a Slack MCP, and it can send messages; give it the GitHub tool, and it can view PRs, change code, and reply to comments. But Walden’s verdict: Real enterprise experience often requires capabilities beyond the MCP. Take Slack, for example. Devin is not a "tool that calls the Slack API" in Slack, but more like a colleague. It needs to support webhook callbacks, respond naturally in threads, control the frequency of speaking, and know when to continue asking and when not to disturb others. This is not just a simple matter of connecting a tool. Cole also mentioned that if an integration goes through almost every session, then it is critical enough to the company that it is worth having this layer of implementation for the team itself. This way you can continue to optimize experience, permissions, and performance. MCP is suitable for fast connections. Once a connection becomes a core workflow, first-party integration is often more reliable. Memory has still not been truly solved. For agents, memory is one of the most attractive and difficult capabilities to do well. Cole said that OpenInspect is not rushing to add full memory because it is still a difficult retrieval problem. The alternatives he sees on the customer's side are more about passing on preferences and knowledge through skills or updating Claude.md. Walden shared Devin’s memory experience. Devin had a system called Knowledge in its early days, with the goal of allowing Devin to automatically learn at work, rather than requiring users to actively write a large number of documents. For example, when the user reminds Devin that "Git is not used this way", the system will ask: Do you want to write this down and continue to use it in the future? The user simply approves or rejects. Walden mentioned that the vast majority of memories in Devin come from this automatic generation, rather than user handwriting. The difficulties lie at both ends:
- Generating memory is difficult. One-time instructions cannot be overgeneralized. Just because you asked to "make this PR a draft" does not mean that all future PRs should be drafts. But the system must also be able to refine stable preferences. For example, "Cole usually prefers to open a draft PR first" might be a valuable memory.
- Retrieval is also difficult. If there are thousands of memories, how can the system retrieve the correct few at the right time? If you take too much, the context will be contaminated by low-value information; if you take too little, the agent will forget important background. Walden mentioned that Cognition is also exploring making memory more like a file system, allowing the agent to navigate and maintain it by itself. Another direction is to have the resident Devin maintain a document similar to memory.md, and keep an eye on a certain product, issue collection or Slack channel for a long time, like a continuously online PM. This kind of always-on agent can record: The most important issue at the moment Who is responsible for the follow-up work Which tickets should be created Which issues have not been advanced for a long time Which work should be done by people and which can be handed over to other Devin This means that the agent may not only be the project executor, but also enter the upstream of the project to participate in triage, planning and product operations. Multiple agents will come, but the most practical one today is manager/sub-agent. Swyx mentioned that he is very optimistic about the direction of agents calling agents, spawn sub-agents, and even swarm. Cole and Walden were more restrained. They believe that today's truly stable and useful multi-agent model is still more like manager / sub-agents: a top-level agent splits tasks, and multiple sub-agents execute in a relatively isolated environment, each with independent machines, to minimize conflicts. The idea of a swarm of agents chatting with each other everywhere is attractive, but in reality it can easily become confusing. Walden also mentioned that Devins once had the ability to create other Devins at will and send messages to each other, but the most practical mode in daily life is still that a main Devin is responsible for managing tasks and isolating subtasks for execution. The value of multi-agent is more reflected in context management and parallel isolation today. It does not necessarily require simulating a group of agents meeting. Many times, a sub-agent is just a smarter tool call. However, Walden also acknowledged that models are now beginning to have more sophisticated communication capabilities. Devin sometimes tells users "you're wrong" instead of mechanically echoing them. This ability to debate, refute, and reach conclusions based on different information will make future multi-agent collaboration more feasible. Uncensored vibe coding will corrupt the code base. The most alarming part of the conversation was about experiments with vibe coding and auto-merge. Cognition has internally tried to develop real products based solely on AI superposition: auto merge, without code review, purely to see how long the system can last. The conclusion is very realistic: with the capabilities of around December 2025, it will probably last two weeks. After two weeks, you'll see the codebase start to deteriorate. For example, a button is implemented in 10 places with slightly different colors, and you have to look for it everywhere to change a style; there are more than a dozen versions of the same type of helper; local bad patterns are repeatedly cited by AI and gradually solidify into project conventions. Cole has a straightforward statement: Your codebase will degrade to the level of your worst engineers. If you have someone on the team who uses AI particularly aggressively but doesn’t review the code, his bad patterns will find their way into the code base. Afterwards, AI will regard these patterns as examples and continue to copy them, and the slop will increase exponentially. The response is not to completely prohibit AI from writing code, but to supplement the governance mechanism: Regularly clean up duplicate code. Clarify module boundaries. Key interface changes must be signed by someone. Use lint and Semgrep to capture AI code smells. Let AI reviewers participate, but the reviewers themselves cannot make noise. Maintain human judgment on architectural boundaries and abstract quality. Swyx mentioned that for engineering leaders, a feasible strategy is to draw clear module boundaries: the interior of the module can be more free, and the contract between modules must be checked by humans. AI code smell is taking shape. As more and more AI codes are written, the team has begun to summarize some typical AI code smells. Cole and Walden mention several examples.
- Overly defensive code in Python When AI writes Python, it often uses patterns such as hasattr and getattr, even if it already knows what attributes the object should have. Cole thinks this is a kind of hack rewarding: the model doesn't want the code to fail, so it adds caveats everywhere. Some customers have written this type of pattern into lint rules: if an unreasonable getattr appears in the PR, it will fail directly.
- Maintain backward compatibility at all costs. GPT series models often write strange import/export compatibility layers to avoid changing callers. Claude's new version is starting to show similar tendencies. This is also a manifestation of reward hacking: the model wants to avoid making mistakes, so it retains too many historical paths.
- Untyped tuples and any, hand-written dict[str, any], untyped tuples, and fuzzy data structures will increase the long-term maintenance cost of the code.
- Over-commenting Walden mentioned that some new models will write long "PRD-style comments" above the functions. Some content is indeed valuable and will explain why this implementation was chosen and why other solutions were abandoned; but too much information can also interfere with reading. Here's an interesting direction: If the agent needs to maintain the code long-term in the future, maybe it would be valuable to store design reasons, context, and prompts next to the code. The idea of GitAI is to store agent prompts into Git metadata so that future agents and code review bots can refer to them. Make the codebase agent-ready If the company wants to actually use background agents, the codebase itself needs to be migrated. Walden’s advice is clear: ultimately you want the agent to not only write code, but also run it, test it, and deliver evidence. To do this, the code base should try to support local running of: A local database A local Postgres or equivalent test environment Docker Compose or a stable dev environment A test path that does not rely on production credentials A setup script that can be called by an agent External services that can be mocked Repeatable test and verification commands The older the company, the higher the cost of transformation is usually. Many companies were founded when Docker was not yet popular, and the code base naturally relied on real services and complex environments. In order for the agent to enter such a system, it must first do a round of agent-ready migration. The good news is that AI itself can now help with this type of migration. Swyx mentioned an interesting idea: observing local traffic like Little Snitch and reconstructing the mock server from real requests. As long as you observe the network interaction for a period of time, you have the opportunity to automatically generate a local mock, allowing the agent to test without touching the real service. agent infra is one of the real moats This conversation repeatedly returns to infrastructure. Walden gave a small but typical example: when many people set up a coding agent, they found that grep on the agent machine was very slow, so their first reaction was to write a custom grep index. Cognition also encountered this problem early on. In the end, the infra team discovered that the root cause lies in the underlying file system: many VMs use network file systems, and files are actually cached in remote storage such as S3. Every time grep triggers a network request, that's why it's slow. The solution is not to pile up another AI-written index, but to replace the underlying file system. Another example is fast save and restore of VMs. Assume that the machine has a 1TB disk, but the agent only changed 100 lines of code. It should not be reprocessed as 1TB during recovery. Cognition has made an incremental file system format that makes the recovery workload close to file system diff, rather than the entire disk. These details don't appear to belong to the agent, but they determine the agent's usability. When you sell an agent product, what you are actually selling is agent plus agent infra. This is one of the reasons why Cognition built its own infra. After mastering the infrastructure, it can deploy Devin to more environments, such as customers' own clouds, VPCs, on-prem, and even more restricted government cloud scenarios. OpenInspect uses a more open provider abstraction. The control plane runs on Cloudflare, the sandbox can be connected to Modal and Daytona, and E2B is also in the roadmap. Cole believes that Modal has a good product experience in sandbox, snapshot and GPU support. Division of labor between local agents and cloud agents Windsurf
- 0 tries to solve another problem: when you have many background agents, some tasks will always need to be pulled back to the local. Walden envisions Windsurf becoming a local command center for all agents. You can pull down the work of a certain background agent for review, and other agents continue to run in the background; you can also throw the issue locally to the cloud and let the background agent fix it. The ideal behaviors of the local agent and the cloud agent are not exactly the same: the local agent should be faster and more suitable for back-and-forth cooperation with users. The cloud background agent should be more autonomous and continuously run to produce complete reports and test evidence. This may only be the difference between prompt and policy, but engineering needs to share logic as much as possible: Git provider, OS, VM, permissions, file systems, and tool calls cannot be made into two completely separated systems. The first few use cases that came to fruition. The most common use case that Cole saw was SRE. When an alert comes in from Slack, Sentry, Datadog or a generic webhook, the agent can be the first responder. It doesn't necessarily fix the problem immediately, but it can collect context first: production logs, database status, related code, historical playbook, recent changes. Many times, it can even generate a PR directly. This will change the troubleshooting process: In the past, alert came in, and people manually checked the logs, found the owner, and asked for context. Now, alert comes in, and the agent first gives a complete trajectory, and even attaches a repair plan. The second type of use case is that PM and non-engineering teams directly initiate code modifications. For some minor bug or copywriting fixes, the PM no longer creates issues and waits for engineers to schedule them, but directly describes the issues in Slack and lets the agent create PRs. The third category is customer support. When customer service encounters a customer problem, they can directly tag the agent and let it give a preliminary diagnosis based on the code base, logs and context, and then pass the complete information to the engineering team. Walden also added scenarios such as continuous security scanning, continuous security review, and auto triage. The CLI is difficult to use for non-technical people, but the chat interface is natural. As long as the agent has access to the code base context, support, sales, and PM can use it to answer code-related questions. Budgeting becomes a new management issue Background agents can be expensive. Common budgets Cole hears range from $1,000 to $5,000 per engineer per month. Higher numbers will also appear, especially once the agent actually enters the production process. Walden believes that an important trend will emerge: teams will use both expensive and smart frontier models as well as cheaper and faster sub-frontier models. The ideal form is a hybrid system: Use sub-frontier models to process fast, repetitive, low-risk parts. Call the frontier model when deep reasoning, complex judgments or high-quality results are required. Let the system maintain frontier-level performance as a whole while controlling costs and delays. This is very similar to the Smartfind idea that Cognition did in the early days: instead of using the most expensive model for all steps, different capabilities are combined. The Endgame of Asynchronous Agents: Autonomous Software Factories Walden finally used a statement: Many companies want to turn themselves into autonomous coding factories. This sentence sounds big, but when you break it down, it actually consists of a set of specific engineering capabilities: Ability to generate PR from specification Ability to build your own environment Ability to run applications Ability to test and provide evidence Ability to access Slack, GitHub, logs, databases, and knowledge bases Ability to maintain memory and long-term context Ability to be constrained by the permission system Ability to accept code reviews Ability to process PR comments Ability to switch between local and cloud Ability to select appropriate models within a budget Model capabilities make this feasible for the first time. The engineering system determines whether it can run reliably in a real company for a long time. Finally, this article can be reduced to one sentence: Asynchronous Agent has moved from demonstration to production. The next thing that really widens the gap will be the engineering capabilities surrounding the model such as orchestration, testing, permissions, memory, review, and infra. If the first generation of AI coding ools improves personal development speed, then what asynchronous Agent wants to change is the software production organization itself. Developers are no longer just people who write code, but will become more and more like designers, schedulers and quality managers in software factories. This is where the "Asynchronous Agent Era" is really worth paying attention to.
