# Every agent needs a computer From local worktrees to cloud agents, and the hard infrastructure problems we had to solve to make them fast. - Author: Saai Arora - Published: 2026-07-22 - Category: Engineering - Canonical: https://tryreplicas.com/blog/everything-needs-a-computer Two and a half months ago, I did almost all of my coding locally. I used Conductor to spin up worktrees so I could work on multiple things at once. It genuinely made me more productive. I could hand one task to an agent, keep working on another, and avoid waiting for one long session to finish before starting the next. Then Connor told me he was building Replicas to run coding agents in the cloud. At first, I did not get it. The obvious benefit seemed to be that I could trigger an agent from Slack or Linear and let it one-shot a small task. That sounded useful, but most of the work I do is not one-shottable. I need to iterate, test, and then judge the work, usually through a few rounds of changing my mind. So Replicas felt like a nice-to-have. Definitely not something I needed. Looking back, I could not have been more wrong. All this time, however, I had already been dealing with the problems cloud agents were built to solve. My laptop would occasionally crash. Every agent competed for the same memory and CPU. I could only properly test one frontend change at a time because every worktree wanted the same localhost ports. And all of the work lived on my machine. Nobody else on the team could see the environment, inspect what happened, or pick up the context without me telling them about it. Worktrees solved a real problem. They also made the next problem obvious: parallel work stops scaling when every agent still depends on one laptop. ## The computer is the unit of work I only understood this later: cloud agents solve nearly every structural problem I had with local worktrees. Every agent gets its own computer. My laptop does not crash because I started five tasks. Agents do not fight each other for memory, CPU, ports, or browser state. Every task gets an isolated environment that can run the entire stack. The work also stops being tied to me. I can start something from my laptop, the Replicas dashboard, Linear, Slack, or my phone at the gym. The agent keeps working whether my computer is open or not. A teammate can open the same workspace, see the same terminal, inspect the same browser, and continue from the same context. This sounds like a convenience until you use it. Then it completely changes how you work. I saw this happen to myself, and I now see it happen with the teams that use Replicas. With local agents, I was keeping the machine awake, resolving port conflicts, watching resource usage, testing the output, and explaining the result to everyone else. Giving the agent its own computer removes me from most of that loop. The agent can own the full environment around its code and carry the work much further by itself. ## Writing code is not enough A useful coding agent continues after editing a file. It starts the database, backend, and frontend. It opens a browser. It clicks through the feature. It notices that the modal is broken, fixes it, and tests again. When it is done, it can send back a preview, a screenshot, or a recording of the feature working end to end. This creates a feedback loop that looks much closer to how an engineer works: **build, test, inspect, fix, repeat.** That loop helps before the pull request is opened, and it also changes code review. Internally, we run automated agent checks against every PR. We use them to catch things our team cares about: React effects that should not exist, unnecessary TypeScript casts, broken UX, missing verification, and other patterns that are easy to introduce and annoying to review repeatedly. The first agent writes the change. Other agents inspect it. Tests exercise it. Our agents reply to those reviews and make changes to the PR. By the time a human opens it, several rounds of mechanical review have already happened. By the end of these loops, a lot of PRs actually are ready to merge. When human judgment is still useful, it moves to the part where it is valuable. I spend less time pointing out a cast or asking whether someone opened the browser, and more time deciding whether the change is actually right for the product. The leverage comes from a loop of agents making the work faster and easier to trust. ## Giving every agent a computer is easy. Making it fast is hard. All of the above sounds simple: just give an agent its own EC2 instance and voilà, problem solved. It becomes much harder when you consider everything that needs to be on that computer, and how quickly it needs to be ready. Making delegation feel immediate is an infrastructure problem we think about constantly. A useful workspace needs more than an empty VM. It needs the repositories, credentials, environment variables, agent skills, system packages, language runtimes, and project dependencies required by that specific team. A Go codebase needs a different environment from a TypeScript monorepo. Some teams need multiple repositories. Others need databases, Docker services, private packages, or setup scripts before the agent can do anything useful. If all of that work begins after the user sends a task, a team with a large codebase can wait 30 minutes, and sometimes close to an hour, before the agent can even start. Replicas uses warm pools to move as much of that setup as possible off the request path. We prepare computers ahead of time, install the environment, clone the repositories, and leave the workspace ready to be claimed. The first warm claim we ever recorded took 59.4 seconds. By July 20, the platform-wide median (the time a typical claim took across Replicas) was 6.5 seconds across 3,240 claims that day. The p95 had fallen to 12.9 seconds, around 29% lower than the 18.2-second p95 from our first seven days of tracking. Knowunity is one of our biggest users. By July 20, they were in our top 10 organizations by workspaces created, with more than 1,800. Their main environment keeps a pool of 15 computers warm for a two-repository codebase and runs a 341-line setup hook. They made 1,671 successful warm claims across 59 active days. At that volume, every extra second compounds across the team, and their setup stresses the system in ways that smaller environments do not. Improving their claim times was especially important to us. The improvement for Knowunity is clear. Across their first 100 successful warm claims, p95 latency was 82.6 seconds. Across their latest 100 through July 20, it was 21.4 seconds: a 74% reduction. The median fell from 17.5 seconds to 12.7 seconds over the same two cohorts. Today we can give an agent a fully configured warm workspace in around six and a half seconds. That computer can already have the repositories, dependencies, credentials, skills, and environment the agent needs to start working. The biggest improvement beyond the median has been in the tail. Slow warm claims have become much faster and more consistent, which matters because users remember the one workspace that takes forever, not the hundred that started normally. There is still a lot of work to do. Six and a half seconds is fast for provisioning a fully configured computer. It still feels like waiting to the person who just delegated a task. We want the infrastructure to disappear. ## The agent has to use the computer too Provisioning is only half of the problem. Once the computer exists, both the agent and the developer need to use it. Connor recently wrote about our work on [making the agent's computer feel local](https://tryreplicas.com/blog/making-the-agents-computer-feel-local). Computer use sits at the interface between the agent, its environment, and the person supervising it. We have been improving that interface from three directions. First, the live desktop needs to feel responsive. Our current streaming path can hold around 50–60fps in normal use, and we are working toward 120fps with much lower input latency. Second, agents need a precise way to operate the browser. Screenshot, guess, click, and sleep is slow and unreliable. Replicas gives agents the browser's accessibility tree alongside the screenshot, so they can act on the actual button or input instead of guessing coordinates. On one controlled 43-action task, that reduced end-to-end completion time from 38.81 seconds to 2.47 seconds. Third, the result needs to be easy for a human to review. Agents can record their work, speed through idle time, keep actions at normal speed, and focus the recording around important clicks. The agent can show me a feature working instead of leaving me to reproduce every step myself. This is what I missed when I first thought cloud agents were mostly useful for one-shot tasks. Long tasks make the computer even more important. The longer an agent works, the more it needs a stable environment, its own feedback loops, persistent context, and a way to hand the result back to a human. ## The orchestration layer Models will keep getting better at writing code. That part is moving incredibly fast. Raw model capability is rarely the whole bottleneck. A great model in the wrong environment cannot run the stack, verify a UI, receive a review, or keep working after the laptop hosting it closes. The important layer is orchestration. An autonomous software engineer depends on a system around the model. It needs to automatically triage incoming work and decide what is actionable. It needs long-term memory so it knows what the team has already tried, how the codebase works, and which decisions should not be relitigated. It needs automated code review, tests, and browser verification. And it needs loops that can take every failure or review comment, make another change, and keep going until the PR is ready. Cloud agents make these systems possible because every step has somewhere persistent to run. An automation can find a bug, create a workspace, hand it to an agent, review the resulting PR, send feedback back into the same environment, and verify the next attempt. The agent's computer keeps the code, tools, and context alive through the entire loop. That is the layer we are building with Replicas. We will keep making the infrastructure faster, the computer easier to use, and the product feel more natural. We will also keep experimenting with new loops that make developers more productive and code easier to trust. Two and a half months ago, I thought cloud agents were local agents moved onto somebody else's machine. Now I think the computer is the point. The model is the muse. Replicas is the orchestrator. And every agent needs a computer.