A support lead sees ten customers confused by an invoice that still says “pending” after payment. They could file a ticket and wait. With Replit Cloud Agents, they can describe a narrow change against the company repository, inspect a development preview, and bring engineering a pull request with evidence. The useful shift is from customer knowledge to a reviewable proposal, not “AI ships code on its own.” Replit announced the workflow on October 27, 2026 and updated the post on October 29. This is a guide to an existing capability, not a November 8 launch.

Check access before promising the workflow

Replit's announcement says Cloud Agents for existing repositories are available to Pro and Enterprise customers. Its repository development documentation also calls this an early-access workflow whose availability and setup may vary by workspace. Check your account before planning a rollout. You need authorized access to a GitHub or GitLab repository; connecting an account does not grant permissions you did not already have. An administrator should decide which repositories and credentials the agent can use.

Start with a small, reversible change: the invoice status shown to customers, not the entire billing system. Write the user-visible failure and expected behavior. If you do not yet know whether the wrong state comes from data or a label, request investigation without edits first. Replit can explore code and dependencies before making a change.

A request an engineer can actually review

Paste the following into a chat connected to your repository and replace bracketed fields with your own test data. This is an illustrative request; we have not run it in a Replit account and are not claiming this bug exists in your product:

Context: Support reports that test invoice [ID] appears as “Pending”
even though its test payment is confirmed.

First, locate where the status is computed and displayed. Explain whether
the problem is in data, business logic, or only the label. Do not edit code
until you show the diagnosis and affected files.

If it is a presentation bug, propose the smallest change. Acceptance:
1. A paid invoice says “Paid” in both detail and list views.
2. A genuinely pending invoice still says “Pending”.
3. Do not change amounts, payment webhooks, or permissions.
4. Add or update a test for both states.
5. Show the diff, test results, and a mobile preview.

Stop before opening a PR if you cannot reproduce the case or the change
touches billing logic, sensitive data, or more files than expected.

The first instruction forces a diagnosis: interface label or underlying data? The pending counterexample prevents an indiscriminate text replacement. The scope limit gives the agent a clear reason to bring in an engineer. These acceptance criteria are useful even without Replit because a human can review them before giving any agent repository access.

Move from chat to a reviewable pull request

Replit's connection guide says to open Repositories, authorize GitHub or GitLab, choose a repository, and select “Use in chat.” Replit prepares a development copy in a sandbox. Repository instructions such as AGENTS.md or CLAUDE.md come with that code. Engineering should maintain those rules: test commands, architecture, review boundaries, and secrets policy.

Ask Replit to run the app and inspect the preview. Check a paid and a pending invoice on desktop and mobile. Its first contribution guide distinguishes a test activity in progress from the final result: a screenshot of a browser running tests is not proof they passed. Read the final report and the diff. Ask for a specific missing check. Screenshots and video attached to a PR help a reviewer understand the change, but they do not replace code review.

Only after the result matches the criteria, ask for a branch and a GitHub PR or GitLab MR. An engineer should review the diff, tests, scope, and dependencies and decide whether to merge. Opening the request does not merge or deploy it. If review asks for changes, continue in the same chat and on the same PR. Replit's review guide says new commits update the existing request. Do not open a duplicate PR for the same issue.

Measure outcomes, not just throughput

During the first week, record how many reports became reviewable PRs, how many needed human correction before merge, and how many resolved the customer problem without a regression. Counting PRs or minutes alone rewards shallow changes that may increase review load. For payments, authorization, and private data, require an engineering owner and test with fake data. Replit notes that sandbox isolation does not remove the permissions of credentials you supply, so use narrowly scoped development access.

This works best when support or product knows the problem and the team already has a review process. If Cloud Agents are unavailable in your workspace, keep the same request format and send it as a well-scoped ticket. The goal is a change the next person can verify, not turning every conversation into code without context.