The Cloud Agent Thesis
Most coding agents today run inside a developer’s local workflow. You open an IDE or terminal, the agent reads the repo on your machine, proposes edits, and you approve or redirect changes as they happen.
That works well when one person is actively working with the code, but the session stays tied to that person’s laptop, local setup, open repo, and attention. Starting ten refactors means managing ten local workflows. A security fix across several repos still needs someone to clone the right projects, install dependencies, and keep the work moving.
Cloud agents move those sessions to remote infrastructure, where teams can run many sessions in parallel across any number of repos, each with the right dependencies, environment variables, and config already set up. They can start work from Slack, Jira, Linear, GitHub, an API, or a CLI, then review the PRs when they are ready. One person can start ten refactors, a security team can patch the same issue across multiple codebases, and CI can start a debugging session when a check fails, without tying the work to one laptop.
Everyone has a way to contribute. A senior engineer can start a session from the CLI. A PM can tag the agent in Slack. A junior developer can kick off a migration from a Jira ticket. A designer can report a bug and have a fix ready for review by end of day. And not every task needs a person to start it: a failed GitHub check can launch a debugging session on its own, and a weekly automation can ask Devin to update dependencies and open a PR.
This gives more people a way to request code changes. They don't need to set up a local environment, use Git, or clone the repo (or even be able to), they just need to be able to describe the task clearly enough for the agent to attempt it and for an engineer to review the result.
I've been thinking about this since joining Cognition and watching how the team uses Devin internally. The useful patterns are not only about helping engineers write code faster, they come from giving the whole team access to an agent that can work across repos without depending on anyone’s laptop.
The core idea is simple: cloud agents are not just local agents running somewhere else, they are a different category, and the differences compound.
What a cloud agent actually is
A cloud agent runs on remote infrastructure. It has its own shell, IDE, and browser. It connects to your repos, CI, deployment pipeline, issue trackers, observability tools, and whatever else your team uses.
You communicate with it the way you would communicate with a remote engineer: send a task, let it work, then review the output.
The local agent model, like Cursor, Devin Local, or Claude Code in your terminal, is a human and an AI sharing one environment. You are pair programming.
The cloud agent model is delegation. You describe the task, the agent works independently, and you get back a PR.
These approaches are not mutually exclusive. They are complementary. Local agents make individual developers faster. Cloud agents open up the codebase to the rest of the organization, which matters a lot more as teams scale.
More people can request changes
At Cognition, non-engineers tag @Devin in Slack to fix documentation, report bugs, or request small features. They don't need Git installed. They don't need a local dev environment. They don't need to know what a branch is.
Many small fixes get delayed because the person who finds the issue cannot make the change themselves. Someone notices a typo in the docs, a broken link, or a small product bug. Filing a ticket feels too heavy, and they do not have the tooling to open a PR. So the issue stays there.
A cloud agent removes that extra step. The person who finds the issue can tag the agent, describe the fix, and move on. The PR shows up. Someone reviews it. The work gets done.
One agent can work across repos
A local agent sees the repo a developer has open. A cloud agent can be configured for every repo in the org.
You can ask it questions about any codebase, start tasks in any repo, and let it handle the setup. An engineer on Team A can request a small fix in Team B’s repo without cloning it, installing dependencies, or stepping away from their current environment.
That matters for cross-team work. Small changes no longer require a full local setup just to get started.
Work can run in parallel
When you use a local agent, you are usually working with it in real time. You watch it work, approve edits, and correct it as it goes. That makes sense for architecture, complex debugging, and unclear requirements. Those tasks need someone with context making decisions.
A lot of engineering work does not need that level of attention. Targeted refactors, lint fixes, CVE remediation, test coverage, dependency upgrades, documentation updates, and migrations usually need clear instructions, tests, and review.
Cloud agents let you start those tasks without staying in the loop the whole time. You can describe ten tasks, start ten sessions, and come back to ten PRs. The limiting factor becomes review, tests, and merge decisions.
Events can start sessions
Sessions can start from events in the tools your team already uses.
A bug report lands in Slack, a CI check fails in GitHub, a Linear issue gets a bug label. A Sentry, Datadog, or PagerDuty alert hits a webhook. A weekly dependency update runs on a schedule.
Each event can start a new session with the relevant context attached. Conditions can filter when it runs, like only for a specific repo, only after a failed GitHub check, or only when a Linear issue has the right label.
The action can either start a new session, message an existing session, or send a notification. Cloud agents like Devin’s automation model supports triggers, conditions, and actions across Slack, GitHub, Linear, schedules, and webhooks.
That covers work that already starts from alerts, tickets, failed checks, support reports, and scheduled maintenance. When a check fails, an agent can investigate. When a vulnerability appears, an agent can open a fix PR. When a bug report lands in the right channel, an agent can triage it or start a repro.
Event-based workflows still need limits. Invocation caps, ACU budgets, filters, and permissions keep a noisy channel or repeated CI failure from creating too many sessions. With those controls in place, an event comes in, the agent gets the context, and the work starts.
Playbooks make repeated work easier
Once a team teaches the agent a workflow, other people can reuse it.
For example, a security engineer can write a Playbook for remediating vulnerabilities from SonarQube. After that, other teams can run the same workflow instead of asking the security engineer to repeat the same steps every time.
That is where cloud agents become more useful inside large companies. The value is not only one developer using one tool. The value is a shared agent that follows the company’s conventions, uses the right tools, respects permissions, and produces work the team can review.
Code Reviews
More agent sessions create more PRs. That increases review load.
The same cloud setup that runs coding agents can also run review agents. A review agent can group related diffs, detect moved code, catch obvious bugs, and answer questions about a change with codebase context.
Teams using cloud agents heavily need automated review. Without it, people either rubber-stamp PRs or spend too much time reviewing agent output.
Where the agent connects
A local agent connects to your filesystem and terminal. A cloud agent can connect to the tools your team already uses.
Slack and Teams can start tasks and send updates. Jira and Linear can provide ticket context. GitHub, GitLab, and Bitbucket can handle PRs and code review. Sentry, Datadog, and Vercel can provide logs for production debugging. Data warehouses can answer metrics questions without pulling an engineer into the request.
Because the agent runs in the cloud, these integrations can be configured once for the organization. Individual developers do not need to set them up on their own machines.
MCP makes this easier to extend. Connect Sentry, and the agent can inspect error logs. Connect a database, and someone on the team can ask a data question in Slack and get the SQL back with the answer, so they can check the logic.
What this means for pricing
Local agents are usually priced per seat because one developer uses the tool in their own workflow.
Cloud agents are usually priced by usage because tasks can come from many places. A PM can tag the agent in Slack. A Linear ticket can start a session. A CI failure can start a debugging task. Those requests do not map cleanly to one developer seat.
The unit of value is the work completed. That is why usage-based pricing makes more sense for cloud agents.
How teams get results
Deploying a cloud agent takes more than buying access. Teams get better results when they assign specific projects, write Playbooks, add Knowledge for repo conventions, track usage, and set permissions for different groups.
The best deployments start with high-ROI work: migrations, security remediation, flaky tests, dependency upgrades, documentation, and repetitive maintenance. Those tasks are easy to describe, easy to verify, and expensive to leave sitting in the backlog.
Some companies are reporting 5 to 6x faster migrations, 70 to 90 percent of security vulnerabilities handled automatically, and every PR reviewed by an agent. Those results come from giving the agent specific work and measuring the output.
Teams that only buy seats and wait for adoption usually get weaker results. Someone has to decide what work the agent should own, how people should use it, and how PRs should be reviewed.
Two ways to use coding agents
Use local agents when you want to sit with the code and make decisions while the edits happen (tight feedback loops)
Use cloud agents when the task is clear enough to run on its own and come back as a PR.
Both workflows matter. Local agents are useful for hands-on coding. Cloud agents are useful for maintenance work, cross-repo tasks, ticket-driven work, refactors, bugs, and requests from people who do not have a local dev environment.
The teams that use both have more options. They can keep developers in the loop when judgment matters and let agents handle the work that can be reviewed after the fact.
Cloud agents as shared engineering infrastructure
Cloud agents run in a separate environment, connect to team tools, accept tasks from multiple entry points, and return PRs.
They give engineers, PMs, designers, support, and other teams a way to request code work without setting up a local environment.
Local agents help developers while they are coding. Cloud agents help teams get work done when no one has the repo open.
At @cognition, we built Devin around this from the start.
Devin is available from Slack, CLI, API, Linear, and Jira. It is already deployed at organizations like Goldman Sachs, Citi, Ramp, Cal.com, Exa, and Eight Sleep.
Try Devin or reach out to see what this looks like across an engineering org.