Before you add cloud agents, check your team's setup

Last checked: 21 Oct 2026. The product facts in this post come from Anthropic's Claude Code documentation, OpenAI's Codex documentation (now hosted at learn.chatgpt.com) and Cursor's documentation, and the independent evidence comes from DORA, METR, Thoughtworks and published research preprints.

When an engineering team asks for cloud agents to work through its backlog, our view is that the request usually turns out to be about setup. The team needs shared instructions in the repository, an agreed standard for what reviewers flag, and a named person who owns both. Without those, agents that run unattended amplify whatever is already unsteady.

No vendor or study has tested whether teams without these things get worse results from cloud agents, so this is our judgement. It rests on the vendors' own documentation, which spends most of its length on setup, and on DORA's 2025 finding that AI amplifies what an organisation already has.

What cloud agents are, and what each vendor calls them

We use "cloud agents" as the generic term for a coding agent that runs on the vendor's machines, starts from your repository and hands back a pull request or a set of changes for someone to review. Each vendor names the product differently.

All three depend on an environment that someone has to prepare. Anthropic's documentation says "Every cloud session runs in a cloud environment, the saved configuration that controls network access, environment variables, and setup scripts." OpenAI tells Codex users to "Create a cloud environment with the repositories, tools, and access your project needs". Cursor's documentation says "Agents are only as capable as the environments they run in" and calls environment setup "the most important step".

The output still goes to a person. Cursor's security page says "Agents open draft pull requests. Nothing merges until a person reviews the change."

Signs the team needs setup work first

The working instructions live in people's heads or on their laptops

A cloud agent only sees what is in the repository. Anthropic's documentation is explicit: "Cloud sessions start from a fresh clone of your repository. Anything you commit to the repo is available. Anything you've installed or configured only on your own machine isn't available in the session." Cursor's cloud agents read rules at three levels: user rules follow one person, while repo rules committed to the repository "apply to all agents using that repository." Codex "reads AGENTS.md files before doing any work." If your senior engineers carry the conventions in memory, or each has tuned a private instructions file, the agent starts every task without them.

Reviewers cannot say what a good change looks like

Each vendor's review tool has to be told what your team cares about, and each reads its instructions from a different place. Claude Code Review reads REVIEW.md, which Anthropic describes as the place "to say what your team wants flagged, at what severity, and what to skip." Codex review rules go in AGENTS.md, and OpenAI says "Codex flags only P0 and P1 issues." Cursor notes that its project rules "do not apply to Bugbot runs", so Bugbot needs its own instructions. If two of your reviewers would disagree about whether a change is acceptable, there is nothing to write in any of these files yet.

The agent cannot run the tests

Cursor puts it plainly: "An agent that can write code but can't run tests, query services, or reach APIs cannot close the loop on its work." Anthropic describes what happens otherwise: "Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it." A team whose test suite is slow, flaky or only runs on one person's machine will get a lot of plausible changes and a lot of manual checking.

The automation would run as one person

Scheduled and triggered agents act under somebody's identity. Anthropic's scheduled tasks "belong to your individual claude.ai account", and "Commits and pull requests carry your GitHub user". Cursor's automations can run as their creator, in which case they "open pull requests as your GitHub account", or as a dedicated service account, which only team admins can choose. If the plan is for one enthusiastic engineer to set up the overnight runs under their own account, the team has a single point of failure before it has started.

Nobody owns the instruction file

Anthropic advises teams to "Treat CLAUDE.md like code: review it when things go wrong, prune it regularly". Thoughtworks put "agent instruction bloat" in the Caution ring of its April 2026 Technology Radar, warning that "As instructions grow, the likelihood increases that important rules are ignored." A file that everyone edits and nobody prunes gets longer and less useful.

Why starting with automation makes the gaps more expensive

A developer using an agent at their desk sees each step. Cloud agents remove that, by design. Cursor says its cloud agents "auto-run terminal commands so they can iterate on tests without stopping for approval on every step. This is more autonomous than the foreground agent, and it changes the risk model".

The volume lands on reviewers who may not have asked for it. A study of 33,000 agent-authored pull requests across five coding agents found that "Not-merged PRs tend to involve larger code changes, touch more files", and listed rejection reasons that include "lack of meaningful reviewer engagement" and "agent misalignment". Without an agreed standard, every one of those reviews becomes a fresh negotiation.

Agents also act in public under a person's name. When Claude Code fixes a pull request automatically, its replies "are posted using your GitHub account, so they appear under your username", and Anthropic warns that this can trigger comment-driven automation in the repository. Costs grow with parallelism too: Anthropic notes that "Running several sessions or subagents at once multiplies token usage", and Cursor asks new users of cloud agents to set a spend limit.

DORA's 2025 research gives the wider pattern. Its report states that "AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses." Google's summary of the same survey found AI adoption associated with higher delivery throughput, but added that "AI adoption does continue to have a negative relationship with software delivery stability." These are survey associations, and they point the same way as the vendors' documentation.

What we check before agreeing a scope

We look at three things before we agree what a cloud agent engagement should cover: the job, the people and what happens after launch. Our guide to running an AI pilot covers baselines and stop criteria in more detail.

The job: one workflow, and a way to see it failing

"Clear the backlog" describes an outcome. To scope the work you need one bounded job with a result you can check. OpenAI's guidance is to start with one representative task. The research on failed agent pull requests found that "tasks related to documentation, CI, and build update achieve the highest merge success", while performance and bug-fix tasks did worst. Even Anthropic's own example of overnight "backlog maintenance" in its scheduled tasks documentation is triage: applying labels and assigning owners.

Anthropic warns that a green status on a scheduled run "does not mean the work your prompt describes succeeded". Its usage dashboard counts "PRs and lines of code shipped with Claude Code assistance", which tells you about adoption and says nothing about whether those changes were right. Decide in advance what failure looks like: rising rework, longer review queues, more incidents traced to agent changes. We cover measurement in more depth in how to measure AI coding tools beyond seat count.

The people: who can unblock it and who lives with it

A named person needs to set the team's position on agents and sign off what is in scope. DORA's capabilities catalogue lists a clear and communicated AI stance among its AI-related capabilities, noting that "Ambiguity creates risk." Every product also needs someone with administrative rights to act. In Cursor, an account admin must connect source control before anyone can start a cloud agent. In Claude Code, only an Owner can create environments shared across the organisation. OpenAI states that "Codex Cloud is off by default for Enterprise workspaces" and splits access into two separate permissions. A sponsor without those rights, or without the ear of whoever holds them, cannot unblock the work.

The people who asked for agents are rarely the only ones who live with them. Reviewers absorb the extra pull requests. Whoever's account an automation runs under has their name on its commits. Security has a stake in shared credentials: Cursor warns that enabling team follow-ups means "a user can influence the execution of a cloud agent that runs with another user's secrets and credentials", and asks admins to treat the setting "with the same care you would give shared SSH keys or service credentials". List these people before scoping, and ask them what would worry them.

After launch: who keeps it working

Instruction files, review standards and automations all decay without an owner. Researchers studying 2,303 agent context files found that they grow through frequent small additions, and that "non-functional requirements such as security (14.8%) and performance (14.5%) are rarely specified." Cursor notes that "An automation that runs as a service account stops running if that service account is archived or deleted." Name the person who will own each of them. Our post on when a developer tool becomes a business dependency covers what happens when a workflow quietly ends up running under one person's seat.

What to do first

Our recommended order, once those checks have answers:

1. Commit one short shared instruction file to the repository. Codex and Cursor read AGENTS.md. Claude Code can read it too, but where a CLAUDE.md exists it reads only that by default, so a repository with both needs an import or a setting. Keep it short: Anthropic suggests under 200 lines per file, and OpenAI says "A short, accurate AGENTS.md is more useful than a long file full of vague rules." All three vendors say to add a rule only after the agent repeats a mistake (Cursor, for example, says "Start simple."). These files guide the agent without enforcing anything: Anthropic notes that CLAUDE.md is "context, not enforced configuration", and hooks or managed settings do the enforcing. Our guide to rules, skills, subagents and hooks explains which to use when.
2. Give the agent a check it can run. Anthropic's advice is to "Give Claude a check it can run: tests, a build, a screenshot to compare."
3. Write the review standard down in whichever file your review tool reads, and keep deterministic checks in CI. OpenAI's wording is that "Code review rules guide Codex; they don’t replace tests, branch protections, or required approvals." Anthropic says a Claude Code Review "never approves or blocks the pull request". None of these tools is a merge gate on its own.
4. Name the owner of the instruction files and the review standard, and give them time to prune both.
5. Settle access, secrets and spend. Check branch protection: Anthropic notes that "A rule that access can bypass doesn't block a session's push". Decide who can read environment variables, and set a spend limit.
6. Then turn on one automation against the workflow chosen in question 3, running under an identity the team controls.

Vendor-specific setup is covered elsewhere: setting up Claude Code safely for a business team and rolling out Cursor to an engineering team.

How to tell a team is genuinely ready

This is our own test, and no vendor publishes one. A team is ready for unattended cloud agents when the shared instruction file has been edited at least once because of a real mistake, and someone has pruned it since. Two reviewers given the same agent pull request would flag the same problems at the same severity. The agent can run the test suite in its environment without help. The planned automation does not depend on one person's account staying active. And a named person reads the failed runs each week and does something about them. If any of those is missing, the next piece of work is setup.

What the evidence does and does not show

The research is mixed. More than 80% of DORA's respondents believe AI has increased their productivity, while METR's randomised trial found experienced developers took 19% longer with early-2025 tools, and its February 2026 update calls the design an "unreliable signal" of the current effect. On instruction files, an evaluation of repository context files found that they do not generally improve task success rates and raised inference cost by over 20% on average, though they were useful for specifying non-standard coding practices. Thoughtworks, meanwhile, places curated shared instructions for software teams in its Adopt ring. The two fit together if the file holds only what is specific to your team.

Common questions

What are cloud agents, and what do the vendors call them?

Cloud agents are coding agents that run on the vendor's machines, start from your repository and hand back changes for a person to review. Anthropic calls its version Claude Code cloud sessions, also known as Claude Code on the web. OpenAI calls its version Codex Cloud. Cursor calls its version Cloud Agents, formerly Background Agents.

Are we ready to turn on cloud agents?

In our judgement, yes when the shared instruction file is committed and has been updated after real mistakes, reviewers agree what to flag, the agent can run the tests, automations run under an identity the team controls, and a named person reads the failed runs. Cursor's documentation calls environment setup the most important step.

Who should own cloud agents in an engineering team?

No vendor or study says who. Our recommendation is a named engineering owner for the instruction files and the review standard, and an administrator for access, environments and spend. All three products already reserve some of these controls for admin roles.

How do we know cloud agents are failing?

Look past activity. Anthropic warns that a green status on a scheduled run does not mean the work succeeded, and usage dashboards count pull requests rather than whether the changes were right. Watch rework, review queues and incidents traced to agent changes. DORA's 2025 survey associated AI adoption with lower delivery stability.

If you would like a second opinion on whether your team is ready for cloud agents or needs setup work first, our diagnostics are the place to start. If you already know what you need, see our AI implementation services and use Request a Quote.