The New CLI Moat Isn’t UX. It’s How Agent Skills Get Shipped

For a while, the agent race looked like a stage show.

Better prompts. Better plans. Better terminal theatrics.

But under the floorboards, something more durable is taking shape.

Codex and Gemini CLI are both starting to treat agent capability less like a momentary runtime trick and more like a shippable artifact.

That may sound abstract. The code says otherwise.

Codex is turning system skills into a managed local layer

In OpenAI’s codex, PR 15712, “Move skills out of core”, is bigger than it looks.

The headline is architectural: shared skill types and rendering moved into a dedicated codex-skills crate. But the interesting part is what that crate actually does.

In codex-rs/skills/src/lib.rs, Codex embeds system skills with include_dir, installs them into CODEX_HOME/skills/.system, fingerprints the nested asset tree, and skips reinstallation when the marker matches. That is not “some prompts live in the binary.” That is a miniature packaging and cache system.

Then codex-rs/core/src/skills/system.rs simply re-exports install_system_skills and system_cache_root_dir from the new crate, while codex-rs/core/src/skills/manager.rs wires those install and uninstall paths into startup behavior.

In plain English: Codex is starting to treat built-in skills like managed inventory.

That matters because managed inventory travels better than hardwired behavior. It can be versioned more cleanly, swapped more safely, and reasoned about as its own layer.

Gemini CLI is making remote agents self-contained

Google’s gemini-cli is pushing the same strategic instinct from the other side of the stack.

PR 23743, “support inline agentCardJson for remote agents”, removes a surprisingly brittle assumption: that a remote agent must begin life by fetching its card from a URL.

In packages/core/src/agents/agentLoader.ts, Gemini now supports two remote-agent shapes: agent_card_url and agent_card_json. The latter is validated up front by attempting JSON.parse() during schema validation.

Then packages/core/src/agents/types.ts adds a discriminated AgentCardLoadOptions union — either { type: 'url' } or { type: 'json' } — plus a helper that can still recover a target URL from inline JSON when auth needs it.

The real tell is in packages/core/src/agents/a2a-client-manager.ts: when the load option is JSON, Gemini just parses the card inline and skips the initial fetch path entirely.

That turns a remote capability into something closer to a portable bundle. The definition can arrive already carrying its own card.

Different directions, same strategic move

Codex and Gemini CLI are not shipping the same mechanism.

• Codex is making skills portable locally by extracting them into a dedicated managed layer with install and cache semantics.
• Gemini CLI is making agents portable remotely by letting the card travel inline instead of forcing a first network hop.

But the product instinct is the same: reduce how much capability has to be discovered live at runtime.

That is a deeper move than a UI polish pass. It changes how agent powers get distributed.

Why this matters now

The terminal agent that wins long term may not be the one that merely feels smartest in a ten-minute demo.

It may be the one that makes capabilities easiest to ship.

Easiest to cache.

Easiest to trust.

Easiest to reuse across machines, repos, and teams.

That is where the moat starts to look less like “best model behavior” and more like supply-chain design for agent powers.

And the timing is not accidental. Gemini’s remote-agent productionization work is visibly active, including the just-closed issue #23742 for initializing A2A from agentCardJson. Codex, meanwhile, is in the middle of a broader capabilities expansion around skills and plugins. Both projects are building more than an assistant. They are building a distribution system.

The pattern worth watching

The first phase of terminal agents taught the model to do more.

The next phase may be about making those powers easier to carry around without breaking.

That is a quieter kind of progress, but probably the more important one. Once capabilities become portable artifacts, ecosystems compound faster. Teams can standardize them. Vendors can package them. Developers can trust them a little more because they arrive with more structure and fewer hidden dependencies.

So here’s the open question: if agent skills and remote agents become truly portable building blocks, does that accelerate a healthier open ecosystem — or just create new lock-in around whose packages ship best?

If you build in this space, watch the packaging layer as closely as the model layer. Then design your own agent capabilities so they can travel cleanly, verify cleanly, and earn trust the moment they land.