Can Tool Result pruning read from the RuntimeEvent log instead of a separate archive?

[Astro-Han]

I ran into a context-compaction bug while testing #3545. Provider-native compaction succeeds and writes a checkpoint, but a later turn can fail to replay it with source_hash_mismatch.

The immediate bug is an ordering problem. A Tool Result inside the checkpoint's covered history can become stale on a later turn. Pruning replaces it with an archive placeholder before the checkpoint verifies the original RuntimeEvents, so the verification sees different content.

I plan to fix that separately by verifying and applying the checkpoint first, then pruning only the remaining history. I don't think the bug fix needs to wait for a larger design change.

While tracing this, I noticed that the full Tool Result already exists in the RuntimeEvent log, but pruning also copies it into a separate archive artifact so that ArchiveRead can retrieve it. That gives us two stored copies, a custom reference format, a dedicated tool, and compatibility code to keep the placeholder and artifact in sync.

I looked at pi for comparison. Large Bash output is written locally, the model sees a shortened result with a path, and normal read or grep can retrieve the rest. Maka has a different lifecycle problem because a temporary file can outlive or disappear before its session, but the RuntimeEvent log already gives us session-owned storage.

I wonder if we can keep Tool Result pruning but simplify retrieval:

1. Keep the full Tool Result in its original RuntimeEvent.
2. Return a shortened model-visible result containing the eventId.
3. Let the normal bounded Read path read a Tool Result from the RuntimeEvent log.
4. Remove the second archive copy and, eventually, the dedicated ArchiveRead protocol.

This would keep pruning while making the RuntimeEvent log the only stored authority. Session deletion would handle the data lifecycle, and we would not leave temporary files behind.

There are still questions around remote Hosts, permissions, copied sessions, old placeholders, and whether extending Read to RuntimeEvent resources is actually simpler than keeping ArchiveRead.

@likun666661, you worked on this area. What requirement led us to the separate Tool Result archive instead of reading the original RuntimeEvent? Do you think the event-log approach can cover it, or is there an important constraint I am missing?

Disclosure: I used Maka to inspect the local Runtime diagnostics, trace the relevant source paths, and compare the implementation with pi. I reviewed and approved this discussion text.

[likun666661]

Thanks for tracing this and for separating the immediate ordering bug from the larger design question. I agree that the checkpoint should be verified and applied against the original covered RuntimeEvents before pruning the uncovered tail.

For the larger design, though, I do not think the RuntimeEvent log should replace the Tool Result archive read path.

The two stores have different responsibilities:

• The RuntimeEvent log is the canonical, immutable execution ledger, optimized for append, replay, recovery, and audit.
• The Tool Result archive is a model-facing serving representation, optimized for bounded retrieval, structured inspection/query, and independently managed lifecycle.

Reading Tool Results directly from the ledger would make the model resource protocol depend on RuntimeEvent identity and layout, historical event schemas, session/run lookup, copied-session ID rewriting, remote Host placement, authorization, retention, and future ledger storage changes. It would also move paging, size limits, structured query, and selective disclosure into the canonical ledger boundary. Keeping archives separate allows us to evolve chunking, indexing, compression, encryption/redaction, deduplication, retention, and specialized query behavior without coupling those concerns to RuntimeEvent persistence.

I also do not see the second copy as requiring ongoing synchronization. RuntimeEvents are immutable. The important contract is a one-time write-before-placeholder invariant:

1. Persist the archive body.
2. Bind it to the source runtimeEventId, body hash, and byte size.
3. Emit the placeholder only after that write succeeds.
4. Fail open and keep the original Tool Result visible if archival fails.

After that, there is no mutable source to keep synchronized. The archive is a derived, purpose-built materialization, not a second execution-history authority.

So my preference is to fix the source_hash_mismatch ordering independently and keep Tool Result archive management separate from the RuntimeEvent ledger. We can still simplify the archive implementation and compatibility surface, but I would not turn the canonical event log into the online Tool Result serving layer.

[Astro-Han]

Thanks, I agree with the boundary you described. The archive should remain a separate model-serving materialization. I am not proposing that Read fetch Tool Results from the RuntimeEvent ledger.

After looking through the current implementation, I think we can simplify the model-facing side without changing archive ownership:

Model
  -> Read({ ref })
       -> resource router
            ├── runtime resources
            ├── attachments
            └── Tool Result archive
                 -> archive artifact store

Read already accepts either a filesystem path or a resource ref, and already routes runtime and attachment refs. We could add maka://archive/... to that router while keeping the archive reader as a separate Runtime/Host capability. Session ownership, source/hash/size validation, conversation copy, and Session retirement would stay where they are today.

I would also reduce the generic archive API to bounded paging. The model would call:

Read({ ref: "maka://archive/..." })

If more content remains, the result would include a continuation ref for the next Read({ ref }) call. Keeping the cursor in the ref means we do not need archive-specific fields in the Read schema.

This seems better than conditionally advertising ArchiveRead. Adding and removing a tool between requests changes the tools prefix and may reduce prompt-cache reuse. Reusing the existing Read tool keeps that prefix stable and removes the recurring schema cost of a separate tool.

I also think we can remove generic inspect/query. The current query path only understands a top-level items array and knows several agent-swarm fields. It does not help with ordinary archived Grep, Read, or Bash results. In one audit run, inspect only returned keys: ["matches"] and told the model to call read, so it added a round trip without helping select content. We found no production code dependency on query beyond its implementation and tests. If swarm later needs item-level retrieval, it could expose stable item refs rather than putting swarm-specific structure into the generic archive reader.

Internally, this could narrow the capability from:

writer + replay reader + resource reader + ArchiveRead tool

to:

writer + archive resource reader

The replay reader also appears to have no production caller after context compaction was unified. Persisted v1 placeholders would still be supported by deriving their archive ref during model projection, but their instruction would point to Read({ ref }).

One separate correctness issue surfaced in the audit: archive writes currently accept results larger than 4 MiB, while retrieval rejects them. We should either leave those results unpruned or implement chunked storage reads, so a “still readable” placeholder is always true.

Does this preserve the separation you have in mind? If so, would you be comfortable with us shaping the implementation around this design?

AI-assisted analysis: Maka helped audit the implementation and draft this proposal. I verified the architecture and am asking for design feedback before implementation.