What Your Agent Can Drive: The Remote-GPU Toolchain, Sorted by Integration Surface

Two earlier posts settled the geography. Scatter the agent took an agent apart and showed where each piece lands; the wire between you and the GPU drew the boundary between your laptop and the rented silicon and showed what crosses it. Neither answers the question you hit the moment you start building: which software do you install, and which of it can your agent operate without you?

That second clause is the one that is never sorted for, and it matters more than the feature lists. An agent cannot use a product whose value is a graphical interface. It can use anything with a stable text surface. Sort the whole landscape on that and it collapses into something you can hold in your head.

The cut that sorts everything

Ask two questions of each piece of software.

First: what role does it play in the loop?

• Brain — the endpoint the loop calls in order to think.
• Hand — something the loop invokes as a tool: run this, fetch that, start a box.
• Floor — infrastructure underneath the agent, which the agent never perceives at all.

Second: is there a non-GUI surface the agent's act-step can reach? If yes it is integrable. If its value is the interface a human sits in front of, it is application-only — useful to you, invisible to your agent.

The interesting result is that the two questions are not independent. Brains are essentially all integrable and nearly interchangeable. Hands are where genuine product choice lives. Floors are neither — and one whole category of "remote GPU" software turns out to be a floor pretending to be a brain.

Brains: the endpoint that thinks

All integrable, and that is the point. Every row speaks some version of /v1/chat/completions, so switching is a base-URL change and a key. The portability of agents is a direct consequence of one API shape winning. It also means the software choice at this tier barely reaches your agent's design — it reaches your bill and your latency, which is a different conversation.

The nervous system: protocols and frameworks

Integrable by construction — this is the integration layer. The division of labour worth memorizing: MCP for tools, A2A between agents, an SDK or framework for the loop. They are not competitors, and a design that reaches for A2A where MCP belongs has usually mistaken a tool for a peer.

Hands: renting a box, and running jobs on it

This is where real product choice lives, and where the application-only rows appear.

The application-only rows are the ones people accidentally design around. A notebook is a superb way for you to hold a GPU session open and a terrible substrate for an agent, because the thing it provides — an interactive human loop with visible state — is exactly what the agent already has and does not need to borrow. "Remote development" and "remote inference" are different products that get conflated because both are described as using a GPU in the cloud.

Floors: device remoting, and the trap

None of these is integrable in any useful sense, because they sit below the layer the agent can see. More importantly, for language-model decoding they are the wrong layer entirely: as the wire post works through, a decode step is hundreds of kernel launches and the whole budget for one token is a few milliseconds, so paying a network round trip per launch is orders of magnitude over. The honest version of "use a remote GPU" is to move the whole model call, not the kernel calls. That the best-known product in this category has been end-of-life for a year is not an accident of the market.

Hands, continued: where the agent runs its tools

Sandboxes are the other half of the hand story — not where the model runs, but where the agent's code execution lands.

All integrable. The pattern to notice: isolation strength and GPU access trade against each other, because the sandboxing techniques that give the strongest guarantees are the ones that make device passthrough hardest. If your agent needs to run GPU code rather than merely call a model, that tension is your actual constraint.

And the confidential variants

Attested endpoints — confidential-mode GPUs behind an attestation you check before the first token — are brains with one extra step, and they are covered as a topology decision in the wire post rather than repeated here. They integrate exactly like row A, which is the useful part: choosing confidentiality does not change your agent's code.

Three rules that fall out

1. At the brain tier, do not agonize. One HTTP shape won; pick on price, latency and support, and keep the base URL in configuration so the decision stays cheap to revisit.
2. At the hand tier, choose deliberately. These surfaces are heterogeneous and your agent will be writing against them directly. A Python API beats a CLI beats a GUI, in that order, for everything an agent must operate unattended.
3. If it only has a GUI, it is for you, not for the agent. This single test retires a surprising number of candidate tools before you evaluate a feature.

The compression: remote-GPU software sorts into a brain your agent calls, hands it invokes, and floors it never sees — and only the surface, not the feature list, decides which is which. Brains have converged on one API shape and are therefore nearly interchangeable; hands are where your architecture is actually decided; notebooks and remote editors are human tools wearing cloud-GPU clothing; and CUDA remoting is a floor that cannot be promoted to a brain no matter how the marketing reads. If you are assembling this stack and want the integration surfaces mapped against what you are actually trying to build — rather than against a vendor grid — that's the work we do.

Related: The wire between you and the GPU · Scatter the agent · Know, do, decide · Do agents run on CPU or GPU? · The agent loop, pedantically · Parallel AI agents in practice.