The default place to run a coding agent today is inside your editor. Cursor, Claude Code, the assistant in your IDE — they sit next to you, you watch them work, you approve each step. It feels natural because it mirrors pair programming: a very fast junior developer at your shoulder, and you keeping a hand on the wheel.
That model is a perfect fit for an agent that needs constant supervision. The trouble is that agents need less supervision every month, and the more autonomous they get, the stranger it looks to keep them tied to a single laptop that is only awake when you are.
The ceiling on local
A local agent inherits all of your constraints. It runs while your machine is on and stops when you close it. It competes with your editor, your browser, and your build for the same CPU and memory. It works on one thing at a time, because you can only watch one thing at a time. And everything it does happens in a place only you can see.
None of that is a flaw in the tools — it is the logic of "local." The agent lives where you live, so it is bounded by everything that bounds you: your working hours, your hardware, your attention, your single pair of eyes. When the agent needed a human watching every step, those bounds were free. Once it does not, they are pure cost.
The async, remote alternative
The other model is the one we built TaskGoblin around: the agent does not live in your editor at all. It lives on dedicated infrastructure and reaches you through the tools your team already uses — a Linear issue, a GitLab or GitHub merge request, a Slack thread. You hand it work the way you would hand work to a remote teammate in another time zone, and it goes and does it in a cloud sandbox while you get on with something else.
The shift sounds like a matter of where the compute runs. It is really a matter of what the agent is allowed to be. Move it off the laptop and the constraints of "local" fall away one by one:
- It runs in parallel. Ten issues can be in flight at once, because no human has to watch any single one of them.
- It is always on. A remote agent does not stop when you close your laptop; work assigned at 6pm is done by morning. The available agent-hours in a day stop being your working hours.
- It runs on infrastructure built for it, not fighting your editor for resources on a developer laptop.
- It works where the team can see it. The output is a merge request and a comment trail, not a private session — supervision becomes something the whole team does in shared spaces.
- It is native to the platform. It is triggered by the events already flowing through your tools — an assignment, a mention, a new pull request — rather than by you opening an app.
- It is isolated by construction. Each run is a fresh, sandboxed environment with scoped, brokered credentials the agent never holds — a security posture a process running on your own machine cannot match.
None of these advantages are dramatic on their own. Together they compound into a gap that is hard to argue with: ten agents working around the clock against one that stops when you do.
"But I need the tight feedback loop"
The strongest objection to remote is the tight loop: the fast back-and-forth of watching an agent, correcting it mid-stream, steering by feel. It is real, and for genuinely exploratory work — spiking an idea, debugging something you do not yet understand — local is still the right tool.
But two things are true about that loop. It is a smaller fraction of the work than it feels like; a great deal of real engineering is well-specified tasks that do not need a human hovering. And it shrinks every time the agents get better, because the reason you hover is that you do not yet trust the agent to finish unattended — and that trust is exactly what is rising. The tight loop is not going away, but it is going to describe less and less of the day.
"But security"
The most serious objection is not workflow, it is trust: putting your code and credentials on someone else's infrastructure. This one deserves a real answer rather than a wave of the hand, and it is a large part of what we build. Runs are isolated per sandbox; secrets are encrypted at rest and never placed in the agent's environment; every organisation's data is strictly partitioned from every other's. Remote does not mean careless — done properly, a purpose-built sandbox with brokered credentials is more defensible than an agent running loose on a developer's laptop with the real tokens in its environment.
Where this goes
We are not claiming local disappears. Exploratory work and some compliance-constrained environments will keep a place for an agent in the editor for a long time. The claim is narrower and, we think, harder to dodge: as agents become able to finish real work without a human watching, the centre of gravity moves off the laptop and onto shared, always-on infrastructure — not because developers prefer it, but because a team that runs ten agents around the clock will simply outproduce a team that runs one until it closes the lid.
That is the bet TaskGoblin is built on. Not a better window onto an agent on your machine, but an agent that was never on your machine to begin with — waiting in the tools your team already uses, ready before you have finished your coffee.
