Daily Edition Sources +13

Agent Runtimes Are Learning to Ship Their Control Plane

A set of Codex, Hermes Agent, Gemini CLI, and Crush commits shows agent tools packaging the machinery around the model: shells, platform adapters, context profiles, and skill catalogs.

Newspaper-style ink illustration of an open shipping case with tagged runtime parts, showing packaged shell, plugin, context, and skills components as inspectable records.
Draft illustrationThe Engraver draft: hidden runtime machinery as packaged, inspectable control-plane parts.
repo openai/codex main
13 source signals 5 repos c7bcb90
> c7bcb90 / May 23, 2026 / Daily Edition

The next generation of agent software is not only about the model sounding smarter. It is about whether the software around the model is stable enough for people to trust: which shell runs the work, how messages reach outside platforms, how long sessions preserve context, and how users discover what the agent can do.

That surrounding machinery is the control plane. It is the part of an agent system that turns a chat loop into a working environment. Recent changes in Codex, Hermes Agent, Gemini CLI, and Crush all point in the same direction: the hidden support layer is becoming something projects package, name, configure, and expose.

Codex packages the shell it depends on

In OpenAI's Codex repo, commit c7bcb90f9 packages Codex's zsh fork as a runtime resource. The commit message says the package layout gives Codex a stable place for runtime helpers that should travel with the entrypoint, and the diff follows through by adding a checked-in DotSlash manifest at scripts/codex_package/codex-zsh.

That manifest points to platform-specific zsh artifacts, while install-context/src/lib.rs adds resource discovery for a bundled zsh path and its binary directory. The important product move is that the shell helper stops being a manual path knob and starts becoming part of the package contract.

For a coding agent, the shell is not background scenery. It is where commands run, tests fail, and files change. When Codex packages that dependency with the app, it is treating execution behavior as something the runtime owns.

Hermes turns Discord into a plugin surface

Hermes Agent shows the same pressure from a different direction. Commit cc8e5ec2 moves the Discord gateway adapter out of the old built-in platform path and into plugins/platforms/discord/adapter.py. The stat line is large because this is not a small wrapper: 42 files changed, with thousands of lines moving as the adapter gains a plugin home.

The new plugin.yaml declares the Discord platform's name, label, kind, version, description, and environment requirements. The adapter's registration block wires hooks for setup, connection checks, YAML configuration, standalone sending, lazy dependency checks, and message-length metadata.

The gateway runner also changes shape. In gateway/run.py, adapter creation checks the platform registry first, then falls through to built-ins. That is the control-plane story: Discord is no longer only a branch in core gateway code. It is a platform capability with metadata and hooks.

Gemini makes context policy a profile

Gemini CLI's May 22 context change, e6f92d66f, is less about external connectors and more about the agent's memory pressure. The diff adds and reshapes context-management code, including packages/core/src/context/config/profiles.ts.

That file defines named profiles such as a default generalist profile, a stress-test profile, and an experimental power-user profile. The power-user profile uses retained, normalized, and archived token budgets, an incremental garbage-collection strategy, named stages such as "Immediate Sanitization," "Normalization," "Archiving," and "Emergency Backstop," plus an async background garbage-collection path.

The configuration reference also exposes experimental.powerUserProfile. That matters because context handling is where agent sessions often become mysterious. Gemini is treating context policy as a configurable runtime mode rather than an invisible cleanup routine.

Crush makes skills visible metadata

Crush adds the user-facing side of the pattern. Commit 55721653 adds descriptions to the skill picker and changes how attachments are used. The core evidence is internal/skills/catalog.go, which defines catalog entries with an ID, name, description, label, and source.

That source can be system, user, or project. The same file adds functions for building the visible catalog, finding the effective skill, and reading a skill's content with metadata. The protocol layer backs this up: internal/proto/proto.go defines skill info and skill-read request and response shapes.

Skills are a powerful abstraction only when users can see what they are choosing. Crush's change moves skills toward an inspectable catalog instead of a pile of files that the agent happens to know how to load.

The shared move is operational

None of these commits proves a shared standard. The projects are independent, and each one is solving a different product problem. The pattern is narrower and more useful: agent runtimes are turning their support machinery into things that can be shipped, named, selected, and inspected.

That is where practical trust in agents will increasingly live. Does the app know which shell it is using? Can a platform adapter explain its setup and environment requirements? Can context policy be named and tested? Can skills be discovered by source and description? Can the frontend ask for the content behind a capability?

The model may still get the headline, but the control plane is where the work becomes reliable. These commits show that layer becoming less hidden, one runtime surface at a time.

Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.