Goodbye Background Agents

Our team writes 100% of our code in the cloud using Tembo. This is the future, and more teams are realizing it.

Historically, teams used most cloud agent tools as “background agents” for quick, one-off tasks that required little iteration. Almost never would teams think to reach for a background agent for sync work. This is changing.

Most high-agency startups in Silicon Valley and around the world increasingly rely on cloud agents for their day-to-day work.

To us, the table stakes for moving 100% of our local coding workflows (not just a subset of them) to the cloud are clear:

You Need a Real Computer

No container BS. You need a persistent machine that can run for as long as the work takes.

It must be able to run Docker, Postgres, Docker Compose, Chromium, and any other software your workflow requires, without crazy "hacks" to get them working. These are normal parts of serious engineering workflows, not edge cases.

It also needs a real desktop for both you and the agent: computer use for the agent, plus a desktop view you can watch or take over.

You also need plenty of RAM, fast CPUs, and lots of disk. A majority of serious dev teams need at least 32 GB just to run a build. We’ve even talked to some companies that need 128 GB just to run tests or type-check their repo.

Environment Configurability

Cloud computers must be easy to configure, ideally through a declarative configuration your team can version and reuse.

Environment variables and secrets are part of that configuration too. Agents need secure access to the right credentials without committing them to the repo or adding them for every run.

Once your have the right environment configured, cloud agents can pause, sleep, and resume from snapshots without rebuilding their environments from scratch every time. This lets you easily reuse the same environment across multiple multiple sessions or team members.

The environment must also support custom dependencies, arbitrary scripts, and whatever else the work requires. As with local development, installing what you need should be easy.

Iteration & Verification Is Key

The workflow must let you iterate on a branch or series of changes before opening a PR.

Most "background agent" tools used for coding just open a PR immediately. You should see the diff before a PR is opened so you can iterate, test, and verify the work. This lets you only open a PR when your work is ready to share with your team.

Previews

The environment needs to somehow let you access your locally running applications and services. Especially for frontend / ui changes, previews are crucial. We've found that the best way to do this is to just expose each local port as tunnels to the running VM. This lets you view changes in a new browser tab, just like you would locally.

Each preview must preserve the local development loop. e.g if you expose a Next.js app, every update should hot reload in the browser.

If an agent changes a web app, you should be able to open it, click through it, find issues, and keep iterating in the same environment. These days, reading a diff is not enough to verify every change, especially for ui work.

Fast

Every capability above must be extremely fast with as little latency as possible.

Cloud agents must feel as fast as local. Otherwise, you'll just return to your local CLI or GUI.

Full VMs must spin up quickly. Repos should not be cloned for every run, especially in multi-repo workspaces where cloning everything can take some time. Dependencies should be pre-installed as well, not installed on demand. Otherwise, the entire loop will feel slow.

Speed and low latency is not really a nice-to-have here. It decides whether the cloud becomes the default place you run agents or a thing you try once before going back to local.

Interface

The interface has to be top tier because you are going to spend a lot of time in it.

It needs to make it easy to see what the agent is doing, inspect the diff, open a terminal, view a preview, send a follow-up, and decide when the work is ready for a PR. If the interface is not excellent, the infrastructure underneath it will not matter at all.

Bonus: Nice to Haves

Session Visibility

Not every session needs to be public. Sometimes you want a private space to iterate with agents on your own, then make the session public and share it with a teammate when it’s ready.

Similar to something like Notion, you need a way to configure access levels and invite specific members of your team to certain sessions.

Artifacts

Artifacts let you package arbitrary files, links, and other outputs from a session or VM. Because the work happens inside an isolated cloud VM, artifacts make selected outputs visible, accessible, and linked to their source.

Files

Some people still need to look at files :). Cloud agents should make it easy to open a file or make a quick inline edit.

Conclusion

Of course, there are still many use cases for agents that run in the background, whether in response to events or on a schedule. But the tools once known as “background agents” are quickly becoming where developers do much of their synchronous work, too.

We’ve covered all these requirements at Tembo. Join the best engineering teams building with us at app.tembo.io.