DataQubeDataQube
Blog

Context compaction without amnesia

Every long AI investigation outgrows the context window — the honest question is what happens then. How DataQube separates the model's working context from the append-only record, makes compaction a visible event, and keeps compacted threads fully auditable.

E
Engineering
DataQube · 18 June 2026 · 5 min read
Engineering

Every agent that does real analytical work eventually hits the same wall: the investigation is longer than the context window. A supervisory response that spans three weeks, forty queries, a dozen revised assumptions, and two committee detours does not fit in any model's context — not today's, and not next year's either, because investigations grow to fill whatever room they're given.

What separates agent platforms is not whether they hit this wall. It's what they do there, and the industry's two standard answers are both quietly dishonest. The first is silent truncation: drop the oldest turns and hope nothing important was back there — amnesia, administered without telling the patient. The second is the infinite-context pretense: marketing that implies the window problem has been solved, when what actually happens under load is answer one, administered quietly. If your work is regulated, both answers fail the same test: can you say, precisely, what the agent was no longer considering when it produced this number?

DataQube's answer starts by refusing to let one data structure do two jobs.

Two memories with different jobs

The confusion underneath most context-window hand-wringing is treating "what the model sees" and "what happened" as the same thing. They are different objects with different guarantees:

Two memories, two guarantees
Working context
what the model sees — rebuilt to fit the window
summary of turns 1–141
pinned: definitions · decisions · open questions
recent turns, verbatim
The record
append-only — what actually happened
turn 1 … turn 141 — every event, kept
compaction event #3 — what was summarized, when
turn 142 …
Compaction rebuilds the left side. Nothing ever rewrites the right.

The record — the thread's conversation log — is append-only and complete: every turn, every tool call with its audit reference, every result, every decision, forever. It is the object the audit trail lives on, and nothing about context management is allowed to touch it. The working context is a projection built from the record for the next model call: recent turns verbatim, the rest represented by summaries and pinned essentials. It is rebuilt, resized, and rewritten freely — because it carries no evidentiary weight. The record answers "what happened"; the working context answers "what does the model need right now." Once those are separate objects, the context window stops being a truth problem and becomes an engineering budget.

Compaction is an event, not an eraser

When a thread's working context approaches the window, DataQube compacts it: older turns are folded into a structured summary, and the context is rebuilt around it. The part that matters for trust is how visibly this happens.

Compaction is an event, appended to the record like any other. It says when it ran, which span of the conversation it summarized, and what summary the model will be working from going forward. In the thread itself you see it as a marker between messages — anyone reading the conversation can see exactly where the agent's working memory was consolidated, the same way they can see where a tool was called. Nothing about the agent's cognition is off the record: even the moments where it reorganized its own memory are on it.

That visibility sounds cosmetic until you need it. When a reviewer asks why the agent's later answers stopped referencing an early caveat, the honest answer is findable: here is the compaction event, here is the summary it produced, and the caveat either made it into the summary or it didn't. The failure mode still exists — summarization is lossy by nature — but it is inspectable, which is the difference between a bug you can file and a ghost you can't catch.

What survives verbatim, and what compresses

Compaction is not uniform blending. Some things are pinned and survive every compaction verbatim, because their exact wording is load-bearing: validated definitions in play, decisions the user has made, the parameters of the task, and open questions the agent still owes an answer. What compresses is the bulk: long tool outputs, exploratory turns that led somewhere, dead ends that didn't.

And compressed does not mean gone. A summary line like "queried the loan book across nine segment variants; all reconciled within tolerance except Office (see turn 87)" carries a pointer back into the record. If the agent later needs the actual figures from turn 87, they are one lookup away — in the record, where they never stopped existing. The working context forgets the way a good analyst's desk forgets: the folder went back in the cabinet, not into the shredder.

Auditing a compacted thread

Here is the property that makes this design coherent with everything else on this blog: evidence never lives in the working context. Every figure the agent produced carries its chain — queries, documents, runs, checks — anchored in the record, not in whatever the model happened to have in its window at the time. So compaction cannot orphan evidence. A thread compacted five times audits exactly like a thread compacted never: walk any claim's chain, and every link resolves, because the thing the links point into was never compacted.

A reviewer examining a long investigation therefore gets both truths at once: the complete history (the record, untouched) and an honest account of what the agent was working from at each stage (the sequence of compaction events and their summaries). Nothing in that sentence requires trusting the summarizer — only reading what it wrote, when, on the record.

A record nobody can rewrite

The property to hold onto from all of this: in DataQube, the record cannot be edited — not by the agent, not by compaction, not by us. Some platforms manage context by compacting the conversation itself, summarizing old turns and replacing them; the day a review comes, the thread being read is no longer the thread that produced the numbers — it is a retelling, written by the same class of model the review exists to check, and your primary evidence has quietly become a derived artifact.

That is why we pay for the append-only record and its disposable projections gladly: storage is cheap, and a history that might have been edited is worthless at exactly the moment someone needs it. When you evaluate any agent platform, one question settles this whole topic: is the thread I audit the thread that ran — or a summary of it?

The same one-record-many-projections principle runs through the whole platform — the product page shows it as chat, notebook, and deck — and if you want to see a compacted thread keep its receipts live, book a demo and bring a long conversation.

Deploys in your cluster - nothing leaves

See your data answer questions - without leaving your infrastructure

Thirty minutes with an engineer: live product, deployment options, and your security team's questions answered by someone who wrote the code.