The old way to talk about agent context was simple: make the prompt bigger, summarize harder, hope the model remembers the right things. The source trail from the last day points somewhere more operational. Context is becoming a runtime object.
That continues a beat from the May 21 edition, which followed goals becoming explicit runtime state. Today's evidence moves the same question one layer closer to the model. What the agent knows, where that knowledge came from, which thread inherited it, and which tools can feed it are starting to get their own protocol fields, databases, metrics, and pickers.
Codex separates hidden context from the user prompt
The sharpest evidence is OpenAI Codex commit 768848ab, which adds experimental additionalContext support to turn start and steer calls. The commit describes context supplied by clients, such as browser or automation state, without turning that data into visible user prompt text.
The shape is small but important. Each entry carries a value and a kind: untrusted or application. The implementation routes those entries into hidden contextual message items, with different roles for untrusted external context and application context, then adds dedupe and reset behavior so repeated turns do not blindly replay stale entries.
That is a different contract from "put this in the prompt." It says external state can be attached to the turn as context, classified by trust level, hidden from the visible thread, truncated, tested, and reset.
Memory gets its own store and its own meters
Codex commit aad59a09 makes the same point from the storage side. Generated memory rows and memory job state move into a dedicated memories_1.sqlite runtime database, while thread metadata stays in the main state database.
The commit message is explicit about the boundary: memory-pipeline data can be rebuilt independently from durable thread records. That is not a branding change. It is a schema decision about which state is owned by memory and which state belongs to the thread system.
Two nearby commits make that memory surface more tool-like. Commit 3936ed22 adds a memories/add_ad_hoc_note tool behind the memories backend, with append-only note creation, filename validation, path-like filename rejection, empty-note rejection, and create-new semantics. The same commit says the tool contribution remains behind an existing commented-out registration path, so the evidence supports an implemented surface, not a claim of broad exposure.
Commit 01a8bf0a adds the observability layer: a codex.memories.tool.call counter tagged by tool, operation, scope, status, and whether a result was truncated. Memory is not only stored; memory operations are becoming measurable.
Lineage becomes part of the context story
Long-running agent work does not stay in one straight thread. Codex commit 1911021c adds forked_from_thread_id to turn metadata so a forked thread can carry the immediate source of its history. The patch also prevents turn-scoped client metadata from overwriting Codex-owned lineage fields.
A companion analytics commit, 48752173, adds session IDs to runtime events so related root and subagent activity can be grouped. The stated reason is practical: thread IDs identify the individual thread, while session IDs identify the shared session across root and subagent threads.
Together, those commits make context provenance less mystical. If a subagent or review turn inherits state, the runtime needs identifiers that explain where the work came from and how related events should be grouped.
Other agent tools are moving context decisions into controls
The pattern is not only in Codex. Google Gemini CLI commit 4a5d5cfc updates default auto routing by changing several documented roles from a fixed gemini-2.5-flash-lite model to a flash-lite routing alias, and adds related model configuration and tests. The article should not pretend that proves model quality. It does show another context-shaping choice moving into named configuration rather than a single hard-coded model string.
NousResearch Hermes Agent commit 8b69ec03 approaches the same pressure from the tool side. It adds a curated MCP catalog, an interactive picker, an install command, optional MCP manifests, credential handling rules, and install-time tool selection. That is context too: external tools decide what an agent can see and do, so the catalog and picker become part of the context boundary.
The prompt is no longer the whole surface
These are independent commits, not a shared standard. They do not prove that every agent project is adopting the same architecture. But they do rhyme around a useful engineering pressure: context is too important to remain an invisible blob of prompt text.
Once context becomes runtime state, it can have ownership boundaries, provenance, metrics, routing policy, and tool selection. It can also become something users eventually need to inspect. The next editions should watch whether these hidden surfaces turn into visible debugging controls: not just what the agent answered, but what context it received, which memory store it touched, which thread it forked from, and which tools were allowed into the room.