Where It Runs

The same agent loop runs in three places: inside your editor, in a terminal on your machine, and in the cloud on a machine of its own. What changes between them is reach: what the agent can see, what it can run and what it can damage. Your view of the run changes too, from watching every edit appear to reading a pull request that arrived while you were doing something else.

Choosing where to run a task is choosing its blast radius, the set of things the worst command could reach. Chapter 3 measures that radius properly. This page gives you the three places and what each one hands the agent.

In the Editor

An editor agent works in the project you have open. It sees the files and the editor's own diagnostics, the type errors and lint warnings already underlined in red, and shows its edits inline as they happen, file by file, often with an accept or reject control on each change. Commands it runs go to the editor's terminal, under your account.

The strength is close watching. You see the agent open refunds, change a line, notice a type error and fix it, and you can stop it the moment it heads somewhere you did not intend. The cost is that your attention goes to watching. Twenty minutes spent following an agent's edits is twenty minutes not spent on anything else, and watching is not the same as reviewing the finished diff.

Inline accept and reject controls add a quieter risk. Accepting hunks one at a time as they appear is review by fragments: each piece looks reasonable on its own, and nobody reads the change as a whole, with its tests, once it is finished. Use the controls to stop a wrong turn early, then read the complete diff as if you had not watched it being made.

In the Terminal

A terminal agent runs as a program in your shell, in the directory you started it from. It inherits your environment: your environment variables, the credentials your tools have stored, your SSH keys and your network. Starting it in the repository root sets where it begins, not where it can go.

On a developer laptop that is usually far more than any task needs. The refund change needs the repository and the test database. The environment it inherits also holds the login for the cloud account, the token that can publish packages and a configuration that points at staging. None of those appear in the request, and all of them are one command away.

Environment variables are the easiest part to forget. A shell profile that sets a database address for your own convenience, pointing at staging because that is where you debugged something last month, hands that address to every command the agent runs. The agent does not need to read a configuration file to use it. It only needs to run a command that reads the variable, and the test runner does.

In the Cloud, on Its Own Branch

A cloud agent gets a fresh environment built from the repository, works on a branch of its own and returns a pull request. It cannot touch your laptop at all. It reaches only the secrets and the network that environment was given, which is decided once, by whoever configured it, rather than inherited from whatever happens to be logged in on your machine.

You do not see the steps as they happen. Whatever the agent read, tried and abandoned stays in its environment's log, and the pull request is the whole review surface. That is a fine trade for a well-specified task with good tests and a poor one for anything you would have wanted to steer. Chapter 13 covers agents that open pull requests as part of a team's process.

The cloud environment is configured, not inherited, and that cuts both ways. Somebody wrote the setup that installs the toolchain and starts a test database, and somebody chose which secrets and which network destinations it gets. Done carefully, it has less reach than any laptop. Done hastily, with a broad token added to make one task work, it has more reach than anyone remembers granting, and nobody is watching while it uses it.

The Same Loop, Different Reach

The read, act, observe cycle is identical in all three places. Only the tools' reach and your view of the run change. A destructive command, such as deleting a directory or dropping a table, is a nuisance in a throwaway container that holds nothing but a copy of the repository. The same command is an incident on a laptop holding production credentials.

	Editor	Terminal	Cloud
Runs as	You, in the editor's terminal	You, in your shell	A service account in a fresh environment
Can reach	Everything your account can	Everything your account can	The repository and the secrets it was given
Your view	Every edit, inline, as it happens	The transcript, as it scrolls	The pull request, afterwards
Best for	Changes you want to steer closely	Interactive multi-file work	Well-specified tasks with good tests

One thing does not change with the place: where the code goes. Wherever the commands execute, the files the agent reads go to the model provider as context. Running the agent in the cloud moves the commands off your laptop; it does not keep the code in-house.

Your view changes as much as the reach does. In the editor you see edits as they land, which tempts you to review by fragments. In the terminal you see a scrolling transcript, which is the most complete record of what the agent read and ran and the easiest to stop mid-run. In the cloud you see a pull request and, if you go looking, a log nobody reads. The review you owe is the same in all three: the whole diff, after the fact, with the tests.

Choosing the Place

Interactive work you want to steer belongs in the editor or the terminal, where you can stop a wrong turn early. A well-specified task with good tests can go to the cloud and come back as a pull request, because the tests do the watching you will not be doing. Two tasks at once need separate checkouts wherever they run, or the agents edit the same files under each other; Chapter 9 sets that up with worktrees.

The rule that covers all three: choose the place by the worst command the task could need, then check that the place cannot reach further than that. For the refund change, the worst command it needs is "run the tests against a local database". A laptop logged into the cloud account reaches far beyond that. A container with the repository and a test database does not.

The same reasoning sorts Cragmoor's other early tasks. Reading pricing to learn how discounts work needs only reads, so any place will do, provided reads are all it is allowed. Adding boundary tests for the refund window needs the test runner and nothing else, which makes it a good first task for a cloud agent once the tests can run there. A one-off check of last month's bookings against staging needs staging access, and that is a task for you, by hand, not for any agent.