Bounded Context Without Erasing History
Apache Maka’s context system addresses a practical tension: a long-running agent can accumulate more history than a model can read, even though that history remains important to the task. This chapter explains how Maka shortens the provider’s working context while retaining the canonical Runtime facts, and how it keeps large individual tool results reachable without treating an archive placeholder as history. The useful judgment is whether a context reduction is a validated projection or an ungrounded replacement.
Imagine a two-hour session in which Maka explores a repository, runs tests, changes several files, abandons one approach, and returns to the next failure. The event history contains exact commands, results, decisions, and constraints. Sending every event to every new model request would eventually consume the context window, increase cost, and leave less room for the next decision. Deleting old events would solve the prompt-size problem by destroying the evidence needed to inspect or reinterpret the work.
Maka keeps those requirements separate. The Runtime Event Log remains the source of facts. Context management creates a smaller view for a particular provider request. The smaller view can be lossy, but it must say which source it represents and remain subordinate to that source.
The full history can outgrow the model
A language model does not need every historical token in every step, but it does need enough context to continue coherently. It may need the current goal, work already completed, decisions that remain in force, the latest file state, and the next action. It may also need to recover an exact earlier tool result when a summary is not enough.
Those needs point in two different directions. The runtime wants to preserve a complete record. The provider wants a bounded request. A design that treats the provider’s request as the only history must choose between overflowing the model window and deleting evidence. A design that treats an LLM-generated summary as a permanent replacement creates a different problem: the summary may omit a constraint or misstate a result, and no canonical source remains to correct it.
Maka instead treats context reduction as projection. A projection is a view computed for a purpose. It can select, compress, or reformat source data without changing the source. The Runtime Event Log answers “what facts were committed?” A compact checkpoint answers “what bounded representation may stand in for this completed prefix in the next request?” The provider request answers “what does this model need to see now?”
That distinction is the context-management version of the architecture’s wider rule: preserve facts first, then derive the view a consumer needs.
Three objects, one source
The three layers are easiest to see as a sequence.
- Canonical RuntimeEvents contain the ordered semantic history: user and model content, thinking, tool calls and results, permission actions, errors, usage, and lifecycle facts.
- A HistoryCompactCheckpoint is a durable projection of an ordered, completed prefix of those events. It may contain a text continuation summary or provider-native compact state, along with the information needed to validate its source coverage.
- The provider request is an ephemeral materialization assembled from the accepted checkpoint, the raw events after its coverage boundary, the current Turn, and the provider’s requirements.