What an open-source cloud agent hands back: a change request

What a cloud agent is

Three sources define the term, and each stops in a different place. Cursor's docs put the weight on the machine: "Cloud agents use the same agent fundamentals but run in isolated VMs in the cloud with full development environments instead of on your local machine" (cursor.com/docs/cloud-agent). Alloy, writing for product teams, describes the environment and what it attaches to: "A cloud agent is a managed cloud environment connected directly to your real product" (alloy.app). The NHI Management Group glossary takes the security view: "A cloud agent is a delegated software entity that executes tasks in a remote cloud environment, often with persistent access to repositories, APIs, compute resources, or orchestration tools" (nhimg.org).

All three describe how the job starts. The machine is remote, the environment is managed, the identity is delegated.

For a team that has to ship, a cloud agent is agent work that starts on a machine nobody had to open and finishes as a change someone reviews in the workflow the team already uses. A remote session that returns a transcript has moved a chat window off a laptop. A remote session that returns a branch, a diff and a change request has moved the job.

Where the machine comes from, and why that matters

Cursor manages provisioning, isolation, snapshots and capacity for every cloud agent. Its docs describe environments with cloned repos, installed dependencies and secrets ready before the agent starts. Alloy spins up an isolated session per capture and keeps the preview link alive after it. Both are cloud agents under any of those definitions, and both keep the machine on the vendor's side.

Kortix describes the machine inside the project. "Every Kortix session gets its own computer: an isolated Linux machine that clones your repo, cuts a branch named after the session, and runs OpenCode" (kortix.com/agent-computer). The image is declared in kortix.yaml, so the Python version, CPU count and disk size are reviewable like any other config change, and the next session boots the same way.

Provenance matters because that machine holds the clone, the dependencies and the branch. When the definition lives in a vendor dashboard, moving it takes a support ticket. When it lives in the repo, moving it takes a diff. Isolation is the other half of the question, and it is worth checking per task rather than per account. One isolated sandbox per session. Each session has its own isolated machine and branch.

Where the machine runs is a separate decision from where its definition lives. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

What comes back when the task ends

Cursor's docs say cloud agents clone the repo, "work on a separate branch, then push changes to your repo for handoff", and that they "produce merge-ready PRs with artifacts". Alloy's sessions end in a shareable preview link. A Kortix session ends in a commit on its own branch and a change request toward main.

The three handbacks are different products carrying one name: a transcript, a preview link, and a diff. A transcript asks the reader to rebuild the work in their head before they can judge it. A preview link lets someone look at the result, which suits a design review where the picture is the deliverable. A diff and a change request let the team run the tests, comment on exact lines and decide whether the work lands.

The diff is the shape that survives a Monday, and it fits a process that already exists: files changed, tests to run, a person to approve, a history someone can read six months later.

How sessions, branches and review fit together

The docs call a session "one unit of agent work" that "runs in its own sandbox, on its own git branch". The branch takes the session id, so "the session_id, the branch name, and the session's sandbox_id field are the same value" (kortix.com/docs/work/sessions). A session may push only its own branch. When the work is ready, "the agent opens a change request. A person reviews it and merges it."

That chain is the definition made concrete: session, machine, branch, commit, change request, merge. Each step has one owner and one artifact. Skip the last two and the cloud agent is a capable intern with no way to hand in the work.

Session work reaches main through a change request. Merge is default-deny for agents.

What to check before adopting one

Isolation per task. Ask whether each task gets its own machine or several tasks share one. Shared machines turn a bad install into everyone's bad install, and they make the branch history hard to attribute.

Where credentials sit. Ask which credentials reach the sandbox and who can read them there. A remote agent inherits whatever the machine can reach, so the answer belongs in your security review, not in a footnote.

Who can merge. Ask whether the agent can land its own work. If a person can skip the review, the permission belongs in the product where reviewers can see it, not in a demo script.

What you keep if you leave. Ask whether the configuration, the images and the history come with you, and what rebuilding them somewhere else would cost.

Kortix answers the last one directly. Open source. Read it, fork it, audit it. The repo holds the agents, the skills, the memory and the connectors, so the setup travels with the company rather than staying behind in a dashboard.