The CLI Is Quietly Becoming an Agent Router

For the last few weeks, the terminal-agent story has been full of visible nouns.

Subagents. Threads. Skills. Forensics. Parallel tools.

Important stuff, sure. But still the stuff you can screenshot.

This week’s more interesting move lives deeper in the plumbing: Gemini CLI is starting to look less like a launcher for local agent tricks and more like a router for remote agents.

That sounds subtle. The code makes it concrete.

Gemini is wiring remote agents like real network peers

In Google’s gemini-cli, PR #21403, “enable native gRPC support and protocol routing”, does more than add one more transport option.

Inside packages/core/src/agents/a2a-client-manager.ts, Gemini now resolves an agent card with resolver.resolve(agentCardUrl, ''), normalizes the returned card, checks whether the card exposes a gRPC interface, and then constructs a client factory that includes REST, JSON-RPC, and gRPC transports together.

That is not just “support gRPC.” That is a runtime deciding how to talk to a remote agent based on the card it receives.

The normalization layer matters too. In packages/core/src/agents/a2aUtils.ts, Gemini maps supportedInterfaces to additionalInterfaces and protocolBinding to transport. In other words: the CLI is already doing adapter work so slightly different A2A card shapes can still resolve into something runnable.

That is the kind of code you write when the ecosystem is no longer hypothetical. It is what you write when real remote agents start arriving with just enough variation to break the happy path.

Then it added the parts you need outside the demo room

If PR #21403 established transport and routing, the surrounding changes filled in the adult supervision.

PR #21496, “add OAuth2 Authorization Code auth provider for A2A agents”, adds browser-based OAuth2 + PKCE, token refresh, persistent token storage, and discovery of auth details from an agent card’s securitySchemes.

Then PR #22199 adds proxy routing support for remote A2A subagents, so those agent-to-agent calls can honor a configured proxy instead of pretending every machine lives on a clean, wide-open network.

Put those together and the pattern gets hard to miss. Gemini is not merely teaching the model to invoke another agent. It is teaching the CLI to survive contact with real infrastructure.

That changes what a CLI is for

There is a difference between a terminal agent that can spawn help and one that can reach help.

The first is mostly a product trick. The second is systems work.

Once a CLI can normalize agent cards, choose transports, traverse proxies, and negotiate auth, it stops being only a wrapper around local workflows. It starts acting like a network-aware client for a distributed agent system.

That is a bigger role than most agent CLIs advertised when they launched.

Codex is investing in a different layer

OpenAI’s codex is not standing still. But its recent movement points somewhere else.

The codex-rs/app-server/README.md describes the app-server as the interface that powers rich clients such as the VS Code extension. It exposes JSON-RPC over stdio, an experimental websocket transport, thread and turn lifecycle APIs, metadata updates, and a growing event surface.

That framing matches the recent commit cluster: plugin-app loading, a typed skills/changed v2 notification, and a thread metadata update endpoint. Those are meaningful capabilities, but they are mainly about client/runtime integration and local capability surfaces.

Gemini’s recent cluster leans harder into remote agent interoperability.

So the contrast is not simply who is ahead. It is which layer each project seems eager to own.

• Codex: the local app/runtime surface where clients, skills, plugins, and thread state stay in sync.
• Gemini CLI: the remote connectivity layer where agent cards, auth, transport choice, and network policy have to line up.

Why this matters now

We are reaching the point where agent ecosystems can fail for boring reasons.

Not because the model is weak.

Because the card schema drifted.

Because the service sits behind a proxy.

Because the auth flow is real.

Because one side says protocolBinding and the other expects transport.

That is why these changes matter more than they look. They are small proofs that the next moat may live in compatibility plumbing rather than prompt cleverness.

If remote agents keep spreading, the winners will need more than good orchestration demos. They will need dependable routing, auth, normalization, and policy-aware connectivity.

So here’s the open question: if terminal agents become the routers for whole networks of other agents, does that make the ecosystem more open — or just shift lock-in from models to the connectivity layer?

If you build agent tools, design them for the messy world now: publish cleaner cards, test behind proxies, make auth explicit, and treat interoperability as product work. That is where the next real trust is going to be earned.