Agent Atlas / Chapter 2

The Invisible Prompt

The model acts on an assembled viewport containing visible messages, hidden turn context, path-triggered instructions, memory records, tool schemas, permissions, and inherited state.

Learning objective

Use public evidence to answer: What does the agent know that the visible conversation does not show?

Working question

What does the agent know that the visible conversation does not show?

Context is a governed data pipeline whose omissions, provenance, and visibility shape every action.
Multiple context sources converge on a runtime context compiler, which selects a model-visible viewport while leaving stale, missing, or blocked material outside.
What reaches the model The model request is assembled from visible and hidden layers; excluded information remains outside the decision viewport. Open full-size diagram
Case file 02 / Hidden turn context

A turn receives facts the transcript never displays

Codex commit 768848ab adds experimental additionalContext to turn-start and steer calls. Clients can attach browser or automation state without converting it into visible user prompt text. Each entry is classified as untrusted or application and routed into hidden contextual message items with different roles.

The implementation includes truncation, deduplication, reset behavior, and tests. Those controls acknowledge a basic risk: hidden context can be useful, stale, duplicated, oversized, or hostile. A response may be consistent with the assembled request while appearing inexplicable from the visible conversation alone.

Latest newsroom receipts

What changed since the first Atlas draft

Mechanism trace

What actually happens

  1. Visible thread

    messages and displayed history

  2. Hidden context

    application and untrusted state

  3. Memory and files

    retrieval plus path rules

  4. Context compiler

    rank, budget, serialize

  5. Model viewport

    selected decision packets

  6. Outside the view

    missing, stale, or blocked

The viewport is assembled from unequal sources

Visible messages are only one layer. The request can also include application context, untrusted external material, project instructions, summaries, tool descriptions, permission state, and inherited thread history. These sources do not carry equal authority, visibility, freshness, or ownership.

A useful context pipeline needs explicit kinds and lifecycle rules. Codex distinguishes untrusted from application context, prevents blind replay through deduplication and reset behavior, and applies truncation. Without those distinctions, external state can masquerade as trusted instruction or survive after its relevance expires.

A file operation can discover new instructions

Gemini CLI PR 22082 adds discoverJitContext, which asks the context manager for GEMINI.md snippets associated with an accessed path. The discovered material is appended to tool output, allowing a file operation to supply local project rules at the moment the path becomes relevant.

The mechanism is wired into read, list, write, and edit tools. Context discovery failure does not block the underlying operation. That preserves tool reliability, but it creates a subtle failure mode: a write can succeed after the path-specific instructions that should have governed it failed to load.

Memory has addresses and ownership boundaries

OpenViking describes context through deterministic viking addresses with resource, user, agent, and session scopes. Its abstract, overview, and full-content layers let a runtime choose between compact orientation and deeper retrieval rather than treating every retained item as equivalent.

Codex commit aad59a09 draws a different boundary by moving generated memory rows and memory-job state into memories_1.sqlite while leaving durable thread metadata in the main state database. The separation identifies which records belong to a rebuildable memory pipeline and which records define the thread itself.

Provenance determines whether context can be audited

Lineage identifiers answer different questions: which thread supplied copied history, which thread performed the work, and which session grouped the activity. Without those distinctions, inherited context loses its origin.

Context quality is therefore not just a retrieval score. It is the ability to explain source, authority, freshness, selection, truncation, and placement for every packet that influenced a decision.

Failure modes

Where the contract breaks

Hidden context contradicts the visible thread

Application or external context affects the request without appearing as user-visible text.

Failure signalThe response follows an unexplained constraint or references absent facts.

Path-specific instructions fail open

JIT discovery can fail while the file operation succeeds.

Failure signalA successful write violates conventions documented beside the path.

Memory loses provenance

Stored facts and summaries outlive metadata explaining their source.

Failure signalA turn uses a fact that cannot be traced to a store, path, thread, or session.
Release tests

What the product must prove

  1. List every context item with source, kind, visibility, authority, timestamp, and truncation state.
  2. Link each filesystem operation to the path-specific instructions discovered or missed.
  3. Identify the active memory store, retrieval source, fork lineage, thread ID, and grouped session ID.

Projects In This Lesson

15 projects

Recent Reporting For This Lesson

6 articles