Replit Cloud Agents: Existing Repositories, Pull Requests and Team Review

Replit announced Cloud Agents for existing company repositories on October 27, giving Pro and Enterprise customers a way to turn requests into tested changes and GitHub pull requests or GitLab merge requests. The important shift is that more people can propose changes without moving the production application into Replit.

For a product manager trying to fix an onboarding screen, that is a different proposition from building a separate prototype. The proposed change can go into the application the team already maintains, with engineers still deciding whether it ships.

What Replit Cloud Agents actually do

The launch announcement describes a workflow in which someone asks for a change, inspects an app preview and sends the result through their team's existing code review process. Agents can exercise the application in a browser and attach screenshots or recordings as evidence.

Replit is also connecting this workflow to Slack and mobile. Microsoft Teams support is described as coming soon, not available today. A separate capability that proposes updates to team instructions from review feedback, subject to engineer approval, remains in early access.

Those distinctions matter. The repository workflow, the channels used to start it and the mechanism for remembering feedback are different capabilities with different readiness states.

Availability is clearer in the announcement than the docs

Replit says Cloud Agents for existing repositories are available to all Pro and Enterprise customers. However, its repository-development documentation still describes that workflow as early access and warns that setup and availability can vary by workspace.

Teams should therefore check the actual repository connection and workspace controls before planning a rollout. The announcement does not specify a separate Cloud Agents usage rate, so plan access should not be read as a promise of unlimited agent work.

Connecting a repository also does not grant permissions someone did not already have. A preview is a development artifact, not the live production application, and opening a pull request does not merge or deploy it.

How the sandbox fits around an existing codebase

According to Replit's code workflow documentation, work happens in an isolated microVM sandbox containing a development copy of the repository, its tools and the running application. Existing production hosting can remain where it is.

The agent can read repository guidance such as AGENTS.md or CLAUDE.md, along with reusable skills. When a change is ready, it can create a branch and draft pull request or merge request. Existing branch rules and the team's release process still apply.

A sandbox separates the work environment. It does not establish that a change is correct. Browser evidence can help a reviewer see whether the onboarding screen renders properly, but it cannot by itself establish that authorization rules, data migrations or less visible edge cases are sound.

That makes the quality of the repository's tests and instructions unusually important. Giving more people access to an agent increases the value of explaining what a safe, acceptable change looks like.

Shared environments reduce setup, with a freshness caveat

Teams can save a reusable environment with the code, runtime, dependencies and tools needed to start work. New chats use the latest successful build rather than requiring each person to reproduce the setup.

There is a practical limit: refreshing that environment does not update a sandbox that is already running. A failed rebuild also leaves the last successful image in place. Before a long-running task continues editing, the agent may need to fetch and inspect newer repository changes.

Background builds require workspace-level GitHub App or GitLab group access, separate from an individual's connection. Credentials should stay out of the saved image. These are setup decisions for the engineering team, not details to delegate casually to everyone requesting a change.

Review feedback can become another agent task

Replit's review-feedback documentation describes an automatic loop when the Git provider integration is configured, a pull request is linked and the Watch pull request setting is enabled. The agent can assess comments and update the same branch. Where that automation is unavailable, a person can ask it to handle feedback manually.

This is useful for straightforward revisions, but a review comment can also contain a product decision or disagreement rather than an instruction to edit. The agent may need a person to resolve that choice. Automatic response to comments should not be confused with automatic approval.

The useful measure here is not how many employees can generate a pull request. It is whether the team can accept more worthwhile changes without increasing the time engineers spend reconstructing intent, correcting assumptions and verifying the result. Cloud Agents make that question easier to test inside an existing workflow.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product launches and engineering updates into clear stories that developers and founders want to read and share.

Book a 30-minute call.