Get your agents off laptops and onto shared infrastructure

There's a specific, recognizable point where a team's use of AI agents changes shape. Not when they adopt agents; most teams already have. It's when agents stop running on someone's laptop and start running on infrastructure that the whole team can see.

This is a real technical shift, not a policy change or a maturity score. Here's specifically what's different on each side of it.

What a laptop-run agent actually looks like

Key takeaway: An agent on a laptop is triggered manually, is visible only to the person running it, and stops the moment that laptop closes.

A developer opens a terminal or their editor and runs an agent against a task. They watch it work, or they don't, and check back later. If they close the laptop or the connection drops, the agent stops wherever it was. Nobody else on the team has any visibility into what ran, what it touched, or what it cost, unless that developer explicitly shares it.

This isn't a criticism of the developer. It's a description of the default. Nothing about running an agent this way was designed to be visible to anyone else, because the tooling was built around one person's editor, not a team's shared infrastructure.

What changes when agents run on shared infrastructure

Key takeaway: The trigger changes from manual to event-based or scheduled, the environment changes from a laptop to an ephemeral sandbox, and the record changes from nothing to a centralized log.

Three specific things change, not just one.

1. The trigger. Instead of a person deciding to run an agent right now, a workflow triggers on an event, a pull request opening, an issue mention, or on a schedule, a recurring dependency scan, a nightly maintenance job. The agent doesn't need anyone present to start.
2. The environment. Instead of running inside a developer's own machine, the agent runs inside an isolated, ephemeral sandbox, spun up for that specific run and torn down when it's done. It has access to what the run requires and nothing else.
3. The record. Instead of nothing, or whatever the developer happened to share afterward, every run produces a centralized log: what triggered it, what it did, and what it cost, tied to that specific run and visible to whoever on the team has access.

None of this requires the developer to change how they write code day to day. It changes where a specific class of agent work, the kind that used to run silently on one machine, actually happens.

Why this is the harder step, not the obvious one

Key takeaway: Adopting agents at all is the easy part. Moving them off individual machines is the step most teams stall on because it requires trusting infrastructure they didn't build themselves for the whole team.

Most teams get to "we use AI agents" quickly. Getting to "our agents run on shared infrastructure, and anyone on the team can see what they did" is a different, harder step, because it means trusting something beyond a single developer's own judgment and setup.

That trust has to be earned by the infrastructure itself, not assumed. An ephemeral sandbox needs to actually be isolated, not just described as isolated. A centralized log needs to actually capture what happened, not just claim to. A scheduled or event-triggered run needs to behave predictably without anyone watching it live, since that's the entire point of not requiring a person to be present.

What this looks like with Upsun Dispatch

Key takeaway: Upsun Dispatch runs agents this way by default. Triggered by real events, executed in isolated sandboxes, logged centrally, not as an upgrade path but as how it works from the start.

Upsun Dispatch™ works this way from the start rather than treating it as an advanced configuration. PR Review, the first-party workflow available today, triggers on a pull request event, not a person deciding to run it. It executes without requiring a developer's own machine to stay open. And it produces a record, tied to that specific run, visible to the team, not reconstructed later from whoever remembers what happened.

This connects to a repo on GitHub SaaS or self-hosted GitLab. The agent runs the same way regardless of which developer's laptop is open or closed at the time.

Start a workspace to see a triggered run in shared infrastructure for yourself.

Frequently asked questions (FAQ)

Does this mean developers can't run agents locally anymore? 
No. This is about a specific class of workflow, the kind that should run independently of any one person's machine, review, scheduled maintenance, anything the whole team depends on. It doesn't require changing how someone writes code day-to-day.

What makes a sandbox "ephemeral"? 
It's created for a specific run and torn down once that run completes. It doesn't persist between runs, and it doesn't share state with anything else on the platform.

Why does this matter more for scheduled or event-triggered work specifically? 
Because that work is designed to happen without anyone watching it live. If nothing is logging what happened, a scheduled run that fails, or does something unexpected, has no record for anyone to check afterward.

Is this only relevant for larger teams? 
The visibility gap exists at any size, but it becomes a real cost once more than one person depends on agent output they didn't personally watch happen.