The loop most teams run today is: make a change locally, push, wait for CI, read a failure, push again. With human code that loop was tolerable. With agentic code it runs far more often, and the feedback cycle becomes the limiting factor. A slow pipeline does not just delay a merge; it delays the next attempt.

It is worth asking what the remote half of that loop is actually buying.

Remote CI is a proxy

Strip away the branding and a remote CI job is the same commands you would run on a development machine, executed on hardware you do not own. Same checkout, same install, same test command, same exit code. The value is not the commands. It is the properties around them: a clean environment, hardware isolation, a machine that is not your laptop, and a record that the work happened.

Those properties are real. The mistake is assuming they require the work to happen on someone else's computer every time.

What you need from CI

Four things are table stakes:

  • Fast. The loop is the product. A pipeline that takes twenty minutes trains people to batch changes and stop running it.
  • Secure. Jobs handle tokens, secrets and third-party code. Isolation is not optional.
  • Agent-driven. The system has to be controllable by an agent through an API, not only by a person clicking a UI.
  • Hardware-isolated. One job should not be able to observe or corrupt another.

Reproducibility is the bonus: the same inputs produce the same result, and you can tell when they did not. Avoiding unnecessary work is the other: a job whose inputs did not change should not run again.

None of those properties belongs exclusively to a remote service. They belong to the environment the work runs in, which can be next to the change.

Where the work already happens

Agents verify their own changes with more than tests. They drive a browser, use a computer, run integration suites, and occasionally check a formal specification. When the change is made in an environment that is a good proxy for production, that verification happens at the point of the change, where the feedback is immediate.

The artifact that comes out of that is the interesting object: an up-to-date, reproducible, tamper-evident record of what was verified. If you have that, the question "should we run the same commands again on a different machine?" becomes a cost question, not a coverage question.

What remote CI is still for

Some workloads do not fit on the development machine. A 32-bit environment, a Windows or macOS runner, a matrix with dozens of combinations, a job that needs more memory than a laptop has. Remote execution is the only practical option there.

Some checks belong after the merge regardless: deploys, smoke tests, release builds, anything that talks to production. Those are not pre-merge verification and should not be moved.

And some organizations need the separation for policy reasons: audit, secrets, network boundaries, a machine that is not developer-controlled. Those requirements are legitimate even when the engineering argument points the other way.

The split, not the choice

The useful framing is a split. Pre-merge checks run where the change is made, on an environment that is close enough to production to be meaningful. Remote CI validates that the right checks ran, using the artifact as evidence, and handles the checks that cannot be local. Post-merge work stays remote.

That split has a failure mode worth naming: it only works if the local environment is trustworthy and the artifact is verifiable. A developer machine with a modified test binary produces a green result that means nothing. The artifact has to carry enough provenance to show what ran, on what, and from which inputs, or the remote side has nothing to check.

What preloop does about it

preloop runs jobs in single-use microVMs on managed hardware. Every job gets a fresh machine, the workflow you already have runs unchanged, and the machine is gone afterwards. Caches are shared by content, so a warm dependency does not have to be rebuilt, and a job whose steps have not changed can reuse the recorded result instead of repeating it.

The API is the part that matters for agents: a run can be started, inspected, paused on failure and retried from a step, without a person in the loop. Pausing keeps the machine and the failure context alive, which turns a rerun into a debug session instead of a replay.

That is still remote execution. The argument here is not that remote CI is unnecessary. It is that remote should be a property of the checks that need it, not the default for every command in the pipeline.