An Agent needs a way to look things up, too

Long-running work accumulates material: the original goal, later constraints, attempted routes, failed experiments and current progress. Sending everything again on each continuation repeats more and more content; keeping only a summary can make the original basis of a decision difficult to recover.

LoopX's context delivery separates these jobs: preserve complete sources, read the facts needed for the current decision, expand supporting material around questions, and reuse unchanged structures exactly within a valid compaction cycle.

This article describes the native Codex path in released LoopX 2.2.0. Supported POSIX Codex App/SSH sessions and new benchmark heartbeat trials default to context delivery; saved off remains effective and explicit off is available. When enabled, complete content is saved first and the Agent receives a reading entrypoint for current facts. See the 2.2.0 release notes for publication and validation scope. The synthetic measurements below retain their original source and experimental conditions.

Think of a capture as a complete book. An index locates its chapters; a JSON Pointer addresses a place inside it. Progressive reading determines how deeply to open the material now. Differential delivery determines what can be reused on the next continuation.

Follow one task: give an assistant voice input

Suppose an assistant needs to understand a voice note and reply in its original chat. Its complete material contains the goal, provider constraints, privacy requirements, acceptance and a long discussion of alternatives. This is a teaching example; the example program below generates the complete data in an isolated directory.

capture.json
├── goal
│   ├── objective: understand a voice note and reply in its original chat
│   ├── constraints
│   │   ├── provider: prefer the already configured speech service
│   │   └── privacy: no public audio; external processing needs authorization
│   └── acceptance: correct transcript, same-chat reply, explicit unavailability
├── providers
│   ├── configured
│   │   ├── formats
│   │   └── authorization
│   └── alternative
│       ├── formats
│       └── authorization
├── evidence: trial results, input formats and reply destinations
└── history: 80 complete discussion entries

First, the Agent needs to understand the integration boundary. It must see both the preference for an existing service and the authorization requirement. A provider preference does not authorize sending audio. The historical discussions remain available when comparing alternatives or checking their basis.

Complete sources are assembled from existing typed owners, with Goal material, full tasks, cumulative acceptance and revisions. Marked generated regions are supplied by canonical tasks; other original narrative, comments and stops remain complete. Headings do not determine which prose may be deleted. This example places its current integration requirements in goal; any additional source-owned mandatory reads still apply.

The figures below are actual reader and codec measurements on this synthetic material. They make no model or speech-service calls. The example program generates the complete sources; the original measurement record preserves the reported figures.

When you know the locations, read them together

/goal/constraints is a JSON Pointer: enter goal from the JSON root, then constraints. It resembles a file path but addresses a value inside JSON.

The file, Pointer and digest answer different questions. capture.json identifies the complete file; the Pointer identifies a location; SHA-256 pins its version. /requirements/0 addresses the first array item. Reordering can change what that index addresses, so use a Pointer with its capture version.

After running the example, $CAPTURE denotes the output directory’s capture.json; $SHA comes from its manifest.json. Select the three known locations in one request:

loopx --format json quota context-read \
  --capture-file "$CAPTURE" --capture-sha256 "$SHA" \
  --select /goal/objective \
  --select /goal/constraints \
  --select /goal/acceptance

This retrieves the objective, complete constraints and acceptance together, including both provider preference and privacy. Repeated --select arguments combine the read request; each value retains its own Pointer.

The complete capture is 51,547 bytes. Using the same file, 16,000-byte pages and a 20,000-byte CLI output limit:

The last two rows retrieve identical Pointer/value pairs; repeated requests and framing account for the difference. The first also retrieves the complete history, so its information scope is larger. This table compares the step of reading those three facts now. Capture generation, storage and the initial reference are shared prerequisites.

When the structure is unfamiliar, index the relevant subtree

If the Agent does not know the provider record's fields, it can expand /providers locally. --list returns metadata: Pointers, types, sizes, and member counts for objects and arrays.

loopx --format json quota context-read \
  --capture-file "$CAPTURE" --capture-sha256 "$SHA" \
  --select /providers --list --list-depth 2

Depth two exposes the provider entries and their fields together:

/providers/configured                 object
/providers/configured/formats         array
/providers/configured/authorization   string
/providers/alternative                object
/providers/alternative/formats        array
/providers/alternative/authorization  string

Next, batch the format and authorization fields. The index locates them; their values must actually be read before dependent decisions.

Listing /providers and each of its two children separately takes 3 calls and 2,784 bytes of CLI responses here. Depth two returns the same set of field addresses in 1 call and 1,283 bytes.

Read known addresses directly; index relevant structure when you need discovery. A small reference may already include the top-level index when it fits. Progressive reading follows the question rather than prescribing a fixed index–single-field–next-level sequence.

See requirements first, then open their evidence

A correct transcript alone does not establish successful integration. The result must return to the original chat.

The two example records say:

sample-1: correct transcript, returned to the original chat
sample-2: correct transcript, replied in another chat

A summary saying “transcription succeeded” can hide the second failure. The implemented native acceptance projection preserves complete requirements and current review state so the Agent first sees the relevant fields:

{
  "description": "Return the transcript to its original chat, preserving source, order and audio reference.",
  "status": "unverified",
  "agent_review": {
    "conclusion": "unmet",
    "basis_current": false,
    "independently_verified": false
  }
}

Unmet acceptance and a stale basis stay in the decision layer. Follow the original-material entrypoint to inspect why it failed and which evidence supports the judgment. Agent review and independent verification remain separate facts.

The implementation returns supporting_material_pointer, locating the outcome in the original capture. Call that returned prefix $P: append /requirements/2/agent_review/note for the explanation, or /requirements/2/agent_review/evidence_refs for evidence references. Use this capture's prefix rather than copying an array position from another file.

After assembling the voice task into the existing typed acceptance structure, its complete original capture is 57,014 bytes and necessary view 5,107 bytes. All 10 requirement descriptions remain complete, together with unmet/stale/independent-verification facts. The original 57,014 bytes also remain intact. Supporting history and long explanations have exact expansion addresses.

Relationship navigation can suggest which outcomes to inspect first using task dependencies, shared acceptance, sources and evidence. Incomplete relationships widen scope, and contrary evidence from other routes stays accessible. Navigation helps order reading; the Agent still determines what affects this decision.

Share exact records within one delivery

A task can appear in both current work and a queue summary. Repeating an identical complete record adds no fact.

The native necessary view can retain one complete task and reference it elsewhere:

{
  "todo_id": "todo_voice",
  "context_ref": "/agent_todo_summary/first_open_items/0"
}

The Pointer addresses the complete record in this same current view. Serialized separately with a trailing newline, the task record is 1,052 bytes, versus 80 bytes for its reference. Complete constraints remain at the original location, and every queue retains its membership and order.

This is exact sharing. Different revisions, owners, evidence or constraints remain separate even when titles match. Unknown fields and unsupported structures retain their original content. Response-local sharing needs no old session baseline; cross-Turn deltas are a separate mechanism.

On the next continuation, deliver what changed

The voice task progresses: a third sample is added, work moves from checking the original-chat return to checking a repaired return, and the review basis changes. The objective and most requirements remain unchanged.

This is where structured context deltas within a compaction cycle apply.

Within a valid cycle, a verified saved baseline supports exact reuse of unchanged text, arrays and objects. Additions, edits, removals and array reordering are explicit. A relocated subtree can reference its original position with current edits overlaid. Reconstruction must match the complete current source.

One valid cycle
Previous: complete objective + all requirements + samples 1, 2 + old work state
Current:  add sample 3; update work state and review basis
Restore:  the complete current context

For the same synthetic task and scope, the codec produces:

This table measures codec output. The native adapter also compares actual delivery bytes including references, page framing and reading instructions, selecting full when preferable. Size comparisons serve efficient delivery without replacing completeness.

When enabled, the default output is a reading entrypoint

Connect these operations back to the currently supported native Codex quota path:

decision-<id>/
├─ projection.json        source
├─ required-context.json  facts
├─ delivery.json          full/delta
└─ *.reader.json          reader

One useful property is that even with mode: "delta", the Agent can select facts directly through current recovery. It does not first need to read an old baseline or replay every delta. Delta's path may address delivery.json; recovery and select_command address the complete current view. context_details then connects supporting material to the original capture.

Native navigation also stores complete capture/selection digests in immutable private reader references. The Agent copies the returned reference; the CLI still verifies the complete digests, selection and cursor on every page. SHA256 itself is not shortened. A first_read_command starts a selection; it does not establish that all required sources were read.

# Copy the original recovery.reference_file from current returned navigation.
loopx --format json quota context-read \
  --reference-file "$RECOVERY_READER_REFERENCE" \
  --select "$POINTER_A" --select "$POINTER_B"

A continuation reference pins its selection: follow its next_command to EOF and return to the original recovery reference to change Pointers. Very small budgets may retain the explicit file/digest interface. The teaching measurements above use that compatible interface and retain their original conditions.

What was saved, and what the model has read

The delta codec answers: can the verified old file reconstruct the exact current file? The native captured_file path verifies the complete saved baseline, version and scope. It does not require the model to have read the old file, reached a selected page’s EOF or sent an ACK. Each baseline is itself a complete version, so the model need not replay a chain of deltas first.

Progressive reading answers a different question: which facts does this decision need? In the voice illustration, suppose the next continuation adds sample 3 while the privacy constraint remains unchanged. Consider a missed-read counterexample: the Agent skipped the required privacy constraint, or can no longer establish it after compaction. Before sending audio externally, it must recover /goal/constraints through the current entrypoint and honor the existing authorization boundary. It can read that fact directly, without first draining the old baseline. A saved file or an unchanged field does not replace the necessary read.

Recover missing context while preserving the original work

After host compaction, a subsequent work Turn builds a new complete baseline. Original goals, requirements and sources remain available for necessary reads.

If compaction, missing pages or truncated output interrupt an unfinished Turn, recover missing facts from its original capture while retaining task, effect and settlement identity. If a voice result was already sent but its receipt was lost, recovering context must not become sending the result again.

Reading has explicit failure boundaries:

• Changed bytes with an unchanged digest: reject the read and verify the version.
• A missing Pointer: reject the whole batch; index a known parent to recover. A present JSON null returns normally.
• Paged content: follow next_command with capture digest, selection digest and byte cursor; combine contiguous content in order. Selection EOF covers only that selection.
• Unknown or inapplicable structures: retain complete content and original read obligations rather than guessing which prose can be hidden.

Continuity and recovery

One valid cycle: complete baseline → changed facts and delta → exact reconstruction.

New cycle or known continuity loss: complete current source → read necessary facts again.

What the measurements establish

The example separates three mechanisms: avoid repeatedly moving history not currently needed, combine reads that belong together, and avoid retransmitting unchanged verified structures. Complete sources, requirements and recovery connect them.

Reader figures include actual CLI page metadata; local path length affects a small amount of framing. Projection figures compare capture bodies; the cycle table compares codec output. The reproduction script checks these distinct measurements and exact reconstruction.

Real long-running tasks must also count necessary later reads, recovery, cache hits, model input/output, tool calls, waiting and human attention. Effectiveness depends on constraints understood, decisions made and accepted outcomes. The synthetic voice example above measures the mechanical path; below we examine multi-task and layered ablation observations on 18-hour trajectories.

Multi-task and layered ablation: benefit chain and boundary counterexamples

In EdgeBench ANN vector search optimization (gpt-6.1-sol / xhigh, 18h, subject to Recall@10 ≥ 0.95) and cross-task ablations, we separate Context Delivery (progressive selection and cycle deltas) from Stride (evidence-conditioned experiment sizing), auditing selected control-packet bytes, main-session model input tokens, and local/early-window counterexamples side by side (reconciled from archived trajectories and receipts by @shangzh0):

Multi-task ablation and layered accounting

This dual-track audit shows why control-packet byte reduction (−74.25% / −38.54%) must not be equated with whole-episode model token savings (−12.07% uncached, −7.46% total), nor used to hide early-window indexing overhead (4.05× in the first 2 hours) or cross-task counterexamples. Context Delivery’s practical value lies in slowing context bloat across 10–18 hour runs so that, together with Stride, preserved attention converts into effective late-stage experiments (see EdgeBench late-stage breakthroughs and five-arm attribution).

2.2.0 ships complete sources, file entrypoints, batch selection, index depth, applicable acceptance layering, exact sharing, cycle deltas and recovery. Broader decision-stage candidate, preference and Explore delivery and consistency across all entrypoints remain unfinished. Disable in Settings → This machine → Capabilities → Differential context → Codex; saved off survives upgrade. A command or new benchmark trial can use --context-delivery off. Trials do not inherit the machine switch, and existing frozen trials are not rewritten. Under the default policy, ordinary CLI, unsupported hosts and non-heartbeat benchmarks retain their full paths; an explicit unsupported on request is rejected. Unavailable hooks use full delivery. Saving configuration, actual installation and model adoption remain separate checks.

Read the same material yourself

example.py generates this complete synthetic voice task and invokes the existing reader, progressive projection and delta owners. It checks selected values, directory addresses, all ten requirements, shared references and complete recovery. It registers no Goal, admits or settles no Turn, and calls no model or speech service.

Prepare the original measurement checkout, a4a0fad889d91cba0d945ce658788bdb76ba351e, and its compatible dependencies. Run from that checkout’s root, substituting the downloaded program path. The output directory must be empty.

uv run --extra test python /path/to/example.py \
  --loopx-root "$PWD" --output .local/context-delivery-example

Generated capture.json retains all 80 history entries. projection.json and required-context.json hold the complete/necessary views; cycle-base.json and cycle-delta.json hold cycle encodings; manifest.json pins files and digests. Production reads use currently returned paths, never copied teaching fields or another capture’s array indexes.

The original measurement record pins this article’s figures. Running on other source can check its mechanisms but cannot rewrite the original observation. Local path length also affects page framing bytes. Understanding this example requires no new research run.

Sources: complete-delivery contract, progressive projection, selection/index, delta/recovery. The example ran on a4a0fad; its three measured core owners are byte-identical in 0e78a19. The implementation links above are pinned to released v2.2.0; the old numbers are not a post-release rerun. Native final delivery also accounts for references and later reads, beyond codec output.