One Dataflow, Two Memories

mksglu/context-mode becomes easier to judge when its sandbox and knowledge-base paths are treated as two memories serving one dataflow. This checkpoint connects the already-established choices—gathering data, deriving an answer, indexing exact evidence, and retrieving a selected section—through one realistic engineering question. The practical judgment is simple but important: choose the memory path according to how long the information must live and what the next decision requires, not according to a single “compression” score.

One research question, two valid routes

Imagine an agent evaluating a library migration. The available material includes recent issue records, a repository’s change history, test output, and the migration guide for the proposed replacement. The agent wants to answer three different questions:

  • Which failure modes appear most often in the project’s recent history?
  • Does the proposed library document a supported replacement for the failing interface?
  • What exact configuration or code change should be made, and what qualification accompanies it?

Those questions look related because they concern one migration, but they do not ask for the same kind of evidence. The first is an aggregation problem. The second begins as a retrieval problem. The third may require an exact passage and then an exact edit in the repository. Treating them as one undifferentiated “read everything” task would make the model carry issue bodies, logs, documentation, and code before it knew which details mattered.

Context-mode offers two main routes. The ephemeral route processes input in a sandbox and returns a derived result. The durable route stores source material in the local knowledge base and returns selected sections on demand. They can use the same underlying inputs, but their output contracts are different. The first optimizes for a fact that can be recomputed from the source. The second optimizes for evidence that must remain recoverable with its wording and structure intact.

flowchart LR A[Large tool, API, file, or web input] --> B{What must the next decision preserve?} B -->|A derived fact| C[Sandbox computation] C --> D[Count, filter, parse, or compare] D --> E[Derived answer returns to model] B -->|Exact evidence later| F[Chunk and index] F --> G[Search by source and terms] G --> H[Matching section returns] H --> E F --> I[Freshness policy] I -->|Changed or expired| F

The diagram is not a sequence that every request must follow. It is a choice of ownership. The sandbox owns the intermediate data and the derivation. The knowledge base owns the durable representation and the search path. The model owns the question, the interpretation, and the final decision. Context-mode is valuable when those ownership boundaries prevent raw material from entering the conversation before it is needed.

Route A: derive and discard the intermediate bulk

For the first migration question—frequency of failure modes—the agent does not need to quote every issue or reproduce the complete test log. It needs a reproducible computation. A batch can gather several independent inputs, label them, and index the command output as a safety net. Its same-round queries can surface the sections that matter; if a repeatable aggregate is needed, a separate sandbox computation over the accessible source can produce the count without dumping every record into context.

The useful output is not just a smaller version of the input. It has a different semantic type.