KaisarCode

A Proposal for Case-Specific Context Reconstruction in LLM-Based Agents

LLM-based agents commonly preserve continuity by carrying material from previous interactions into later inferences.

Depending on the architecture, later inferences may inherit far more than the current exchange. Tool activity, retrieved material, and earlier intermediate state can all become part of what the model sees next.

This approach is practical, but it couples active inference context to interaction history. As an agent continues operating, later cases may inherit material solely because it was previously present, even when the current case has no use for it.

Context size can consequently reflect the age and activity of an interaction more than the semantic requirements of the inference being performed.

The resulting problem extends beyond token count because inherited history can keep dead state alive. Old assumptions and abandoned decisions may continue to shape later inference long after they stopped being valid.

For example, an interaction may preserve several successive transport proposals and reversals while the current semantic state required by a later case is simply:

project:X;transport:Unix domain sockets

Earlier proposals may remain useful for audit, debugging, provenance, or historical questions. They do not necessarily belong in every future inference.

Conversation history is good at preserving how an interaction unfolded, including order, wording, and turn boundaries.

Current reasoning often needs something else: a representation of what is still true, what still constrains the case, and what remains unresolved.

A conversation may therefore contain enough evidence to reconstruct current state without being an efficient representation of that state.

Common mitigations such as sliding windows, summarization, and periodic context compaction reduce representation size but may preserve the same underlying dependence on inherited state. When each new context derives from the previous one, transformation errors can propagate through successive summaries or consolidations.

These transformations can fail in ways that alter meaning rather than merely shorten text. A summary may drop a negation, blur two entities together, or carry an obsolete conclusion forward as if it were still valid.

Summarization may be useful at many stages of an agent system, but the architectural concern arises when each later inference begins from an incrementally inherited representation, allowing transformation errors and obsolete state to propagate forward.

A related problem arises from treating relevance as sufficient reason for context inclusion.

A long-running project accumulates knowledge across many concerns, most of which will be irrelevant to any one question.

For a question about how to compile the repository, only build commands, dependencies, and platform constraints may be necessary.

Retrieval can identify potentially useful material, but case construction must determine what actually reaches inference.

This proposal explores an alternative operating model: inference-scoped semantic context reconstruction.

Under the proposed model, durable knowledge remains external to active inference context. For each new case, the system may:

• retrieve potentially useful semantic units and episodic evidence
• rank candidates
• select material required for the current case
• integrate selected material into a dense semantic state
• materialize that state for a concrete inference capability
• execute the inference
• persist durable semantic changes when necessary
• discard the active case context

Conceptually:

current input
  -> retrieve candidates
  -> rank
  -> select necessary material
  -> integrate semantic state
  -> materialize case context
  -> infer
  -> reconcile durable changes
  -> discard active context

The proposal assumes that long-term continuity can emerge from recoverable and recomposable knowledge, with conversation state reconstructed only when a case requires it.

This changes the unit around which context is organized. The model treats each inference as a case with local semantic requirements and keeps durable state outside the ongoing session.

Two consecutive cases may therefore receive substantially different contexts even when they belong to the same long-running interaction.

A question about building a repository may require:

build commands
dependencies
platform constraints

A later question about an architectural decision may require:

current project state
relevant prior decisions
selected historical evidence

An acknowledgement such as:

Thanks

may require almost no recovered knowledge.

Context size is therefore expected to follow local semantic complexity.

A central distinction in the proposal is that retrieval and context construction are separate operations.

Retrieval produces candidate material, while case construction decides whether any of it belongs in the active case. Selected units may overlap, conflict, express stale state, or represent complementary fragments at different abstraction levels.

Before inference, the system may need to turn retrieved fragments into a coherent state. That can require merging overlap, resolving stale or conflicting material, and reorganizing information around the current case.

This document uses the term dense semantic unit for such a representation.

A dense semantic unit is intended to preserve information useful for downstream reasoning or later recomposition while reducing unnecessary representational structure. The term does not imply a mandatory syntax, schema, compression algorithm, model, vector representation, or storage backend.

Some examples in this document use compact textual records influenced by the kind of representation explored in IRGist:

https://github.com/kaisarcode/irgist

IRGist is used only as an illustrative reference for dense contextual semantic representation. The proposed model does not require IRGist, its syntax, its wrapper format, or any equivalent implementation.

This document presents a technical proposal and leaves implementation details open. Its purpose is to define the model clearly enough to guide implementation and evaluation without fixing a particular stack.

The proposal remains implementation-agnostic and leaves the model, prompt format, provider, database, embedding system, memory format, orchestration framework, programming language, and infrastructure open.

The central proposition is:

Long-term continuity should be recoverable from durable knowledge, while active context should be reconstructed for the semantic requirements of the current case.

Proposed Operating Model

The proposed model reconstructs active semantic context independently for each inference.

The general flow is:

current input
  -> retrieve candidate knowledge
  -> rank candidates
  -> select what the case needs
  -> integrate selected semantic material
  -> build one dense case state
  -> materialize
  -> infer
  -> reconcile durable changes
  -> persist when needed
  -> discard active context

Durable knowledge and complete history may remain externally available.

Continuity arises from recovering and recomposing required knowledge when a new case begins.

The model reconstructs case context at inference time, before accumulated context reaches any size threshold. Case context is constructed from current requirements at inference time.

A later case may require: more context, less context, different context, or no recovered context at all.

The active state of one case therefore need not become the starting state of the next.

Design Principles

Context is temporary working state

Context contains material assembled for a specific inference.

Durable agent knowledge remains external and survives after that context is discarded.

History and consolidated knowledge serve different recovery needs

History preserves events and sequence, including what happened, who said what, when it occurred, how events were ordered, which tools ran, and what they produced.

Consolidated knowledge represents semantic state through current facts, decisions, constraints, relations, conclusions, preferences, results, and unresolved questions.

Both representations may coexist because they support different forms of recovery.

Conversation is an interaction surface

Conversation provides an interface between user and system.

Continuity can be reconstructed by recovering and recomposing knowledge on demand without preserving the entire conversation inside active inference context.

Context is reconstructed per inference

Each case synthesizes active context from the current input and whatever external semantic knowledge, episodic history, or tool observations the case actually needs.

A later case may require more, less, or entirely different context than the previous one.

Context size follows case requirements

Active context may expand or shrink between inferences.

Its size depends on the information required for the current case. Agent age, session duration, previous message count, and total stored knowledge should have no direct effect.

Expected context size therefore exhibits peaks and valleys.

Selection is stricter than relevance

A knowledge unit may be related to an input and still contribute nothing necessary to resolving it.

The objective is to construct a minimum sufficient semantic state for the case.

Retrieval produces candidates for case construction

Recovered units rarely arrive as a clean context. They may overlap, disagree, or describe the same state at different levels of abstraction.

These units become inputs to selection and integration.

Semantic integration builds a new representation

Integration turns that uneven material into a usable state by reconciling overlap, updating stale information, and reorganizing what remains around the case.

The resulting semantic unit may differ structurally from every input and need not preserve retrieval order or source boundaries.

Dense semantic units are recomposable

A dense semantic unit remains reusable: later cases can combine it with newly recovered or newly observed information and produce another consolidated unit.

The result may itself become another dense semantic unit.

This allows semantic contexts to merge without preserving their original structure.

Durable memory remains external to active context

Persistent knowledge can use whatever recoverable storage fits the system; the proposal does not depend on one representation or backend.

Storage may use any durable, recoverable backend.

Retrieval representations are auxiliary artifacts

A semantic unit may also have separate retrieval artifacts that help the system find it without changing the unit's semantic content.

These artifacts help locate semantic units but remain conceptually separate from their semantic content.

Vector search is permitted but optional.

Semantic integration is an abstract capability

The proposal depends on semantic integration behavior without requiring one implementation strategy.

The architecture does not assume a single integration mechanism. Different parts may use learned models, deterministic logic, or domain-specific methods according to the kind of judgment required.

Evaluation should focus on observable behavior and preservation properties.

Main Components

Current input

The immediate input received by the system.

A case begins when new information demands inference, whether that arrives through user interaction, a tool, or an external event.

Current input initiates case construction.

Semantic store

A durable collection of recoverable semantic units.

A semantic unit needs enough metadata to be recoverable, scoped, and updated safely, while the semantic payload remains separate from retrieval infrastructure.

Separate retrieval metadata may provide embeddings, lexical index entries, relation links, and ranking features.

The store holds recoverable semantic units and does not require complete conversation transcripts.

Episodic history

An optional and separate activity record.

The episodic record may preserve full messages, timestamps, tool calls and results, events, errors, and temporal order.

An append-only file is one possible implementation, though any durable and inspectable representation may be used.

Episodic history enters active context only when a case needs it.

Retrieval representation

A semantic unit may have one or more external representations used for retrieval.

Retrieval representations are auxiliary structures used to locate semantic units efficiently, for example through embeddings, lexical terms, or scope metadata.

These representations belong to retrieval infrastructure.

Retriever

The retriever obtains candidate units for current input.

Retrieval may combine semantic similarity with scope, recency, explicit references, and other signals that narrow the search to the current case.

Candidates may come from semantic knowledge, episodic history, or both.

The retriever supplies material for later stages.

Ranking

Recovered candidates may be ordered or filtered according to explicit criteria.

Ranking then estimates which candidates are most likely to matter, using whatever signals the implementation can inspect reliably.

Ranking identifies potentially useful material while leaving final inclusion decisions to later stages.

Selection

Selection removes material that may be related to the case but unnecessary for the inference.

This stage removes noise, weak associations, accidental context, peripheral information, and unnecessary duplication.

Selection may be implemented separately or combined with ranking or semantic integration.

The conceptual distinction remains useful because successful retrieval does not by itself justify inclusion in active context.

Dense Semantic Units

Definition

A dense semantic unit is a consolidated semantic representation designed to preserve information required for downstream reasoning or later recomposition while reducing unnecessary structure and redundancy.

The representation may discard source structure when that structure has no downstream value, preserving meaning without carrying the shape of the original inputs.

Information may be reorganized according to semantic relationships.

Possible roles

The same semantic representation can be reused across several roles, from durable knowledge to temporary case context or handoff state.

These roles may share a representation or use separate data types, depending on the implementation.

Role may be determined by usage and external metadata.

Dense semantic integration capability

The proposed model requires a capability that transforms one or more semantic inputs into a new dense semantic unit.

Conceptually:

D(X1, X2, ..., Xn) -> U

The integration capability may receive material from storage, prior semantic units, current observations, or tool output, depending on what the case requires.

The result is a newly integrated semantic representation.

Expected functional behavior

Depending on the input, the capability may need to:

• fuse complementary information;
• remove duplication and reorganize structure;
• reconcile updates and replace obsolete state;
• preserve negation, constraints, important relations, and unresolved questions;
• distinguish certainty from uncertainty;
• keep unresolved contradictions explicit;
• reduce redundant structure and unnecessary representation size;
• generate a coherent contextual unit.

Each invocation requires only the behaviors applicable to its inputs.

Implementation dependence

Different implementations may produce different valid dense semantic units from the same material.

The proposal therefore does not define a canonical semantic serialization.

It describes expected capabilities and architectural behavior.

Approximation

The transformation may be lossy, approximate, probabilistic, model-dependent, and domain-dependent.

Semantic preservation may be approximate.

Implementations should instead be evaluated against the information and behavior they are expected to preserve.

Semantic Recomposition

Recursive use

A dense semantic unit may become input to the same integration capability.

For example:

U1 = D(X1)
U2 = D(X2)
U3 = D(U1, U2, Y)

where Y represents additional semantic material.

U3 becomes a new consolidated unit.

Context merge

Multiple contexts may be merged into a new contextual unit.

For example, a system may combine project context with user constraints, task requirements, and tool observations.

The result is a new semantic projection for the case.

Hierarchical recomposition

Semantic units may be constructed at different levels and later merged.

Semantic units may be scoped narrowly or broadly, from a single case to an entire repository or user context.

This permits local projections without requiring a globally accumulated context.

Exact associativity is not assumed

Repeated integration may yield different results depending on grouping and transformation order because earlier condensation may remove information.

Therefore:

D(D(A, B), C)

need not equal:

D(A, B, C)

This behavior is compatible with lossy semantic recomposition.

Exact idempotence is not assumed

Repeated processing of the same semantic unit need not produce byte-identical or semantically identical output.

A practical implementation may instead seek approximate stability when no materially new information is introduced.

Recomposition does not replace evidence preservation

A recomposed semantic unit cannot substitute for original evidence when a case depends on exact provenance, wording, sequence, auditability, reversibility, or source material.

Systems may preserve original sources or episodic history separately.

Case Semantic State

Definition

The case semantic state is the dense semantic unit assembled for one specific inference.

It should contain information the current inference needs while excluding material that contributes no necessary effect.

The design objective is a minimum sufficient semantic state.

Construction

A typical construction process is:

current input
  -> retrieve candidates
  -> rank
  -> select necessary units
  -> integrate selected material
  -> case semantic state

The integration capability transforms selected knowledge into one case-specific semantic unit.

Retrieved units become construction inputs

The main inference need not receive recovered units directly.

For example:

K_case = D(U17, U42, U91)

The inference may then begin from K_case together with current input.

Retrieval results are source material for context construction.

Context Materialization

Materializer

The materializer transforms case semantic state into a representation consumable by a concrete inference capability.

Materialization may produce text, messages, tokens, structures, prefixes, latent representations, KV state, or combinations of them.

Materialization may use any representation the inference capability can consume.

KV state

KV state may serve as a computational materialization of case semantic state.

Under this model, KV state can be scoped to the semantic conditions of one case instead of acting as a container for accumulated interaction history.

Each inference may use a different KV state.

KV use remains optional.

Inference Engine

Conceptually, the inference engine receives system policy, materialized case context, and the current input.

Each inference executes as a new case and can operate without the complete accumulated conversation.

Main Flow

The normal flow is:

input
  -> retrieve
  -> rank
  -> select
  -> integrate
  -> materialize
  -> infer
  -> respond

Selected knowledge is integrated into one case-specific semantic state before inference.

Vector Retrieval Example

An implementation may maintain semantic units separately from an external vector index.

For example:

semantic store:
    U1
    U2
    U3
    ...
    Un

retrieval index:
    U1 -> v1
    U2 -> v2
    U3 -> v3
    ...
    Un -> vn

For a new input, vector retrieval may recover a small candidate set.

Selection then removes unnecessary units, and integration produces one dense case context.

The vectors remain external retrieval infrastructure, while the semantic units remain independently recoverable.

Closing Phase

A later case recovers information from the visible response only when that information becomes relevant again.

Before closing a case, the system may determine which durable semantic state changed.

The closing phase asks what, if anything, changed durably during the case. It can compare the prior state with the new input, result, and observed effects before deciding what to persist.

The result may be a new dense semantic unit or a revised set of units.

Persistence therefore supports semantic update, replacement, invalidation, and merge.

State Update

Update semantics

New knowledge may add, modify, merge, replace, invalidate, or deduplicate existing semantic state.

The proposal permits semantic reorganization whenever new information changes the meaning or validity of prior state.

Example

Previous state:

project:X;transport:HTTP

New decision:

project X will use local Unix domain sockets instead of HTTP

A resulting state may be:

project:X;transport:Unix domain sockets

The old transport can remain recoverable through episodic history or provenance when historical evidence matters.

Current semantic state need not represent both transports as simultaneously valid.

Persistence

A resulting semantic unit may:

• be normalized
• receive an identifier
• receive timestamps
• receive scope metadata
• receive provenance metadata
• receive an external retrieval representation
• be stored
• become available for future retrieval

Future inferences recover the unit only when the case requires it.

Parallel History

The system may maintain a complete activity history in parallel.

For example:

chat.log

The history may record user input, agent output, timestamps, tool activity, effects, and errors.

That record can support audit, inspection, debugging, reconstruction, episodic retrieval, and later reprocessing.

Its existence does not require default inclusion in active context.

A compact statement of the principle is:

The agent may preserve history without loading it into every inference.

Episodic Memory

Episodic memory preserves recoverable events.

Episodic memory is useful when the question depends on sequence or evidence: what happened, when it happened, or what came before a later decision.

Episodes may be recovered on demand through timestamps, vector representations, textual search, metadata, or explicit references.

Relevant episodes can then be transformed into a temporary dense semantic unit for the current inference.

The projection may be discarded afterward while original events remain intact.

Consolidated Knowledge

Consolidated knowledge focuses on surviving semantic state, so details of how that state was discussed can be omitted when they no longer affect meaning.

Example conversation:

A: perhaps we need an orchestrator
B: it could handle...
A: no, it is unnecessary
B: correct, the pipeline can be deterministic

A possible consolidated unit is:

architecture:no orchestrator;control_flow:deterministic pipeline

This representation preserves the surviving architectural state.

When sequence later matters, the system may recover it from episodic history or preserve it explicitly as durable knowledge.

Recursive Semantic Integration

A previously generated semantic unit may later be combined with new information.

New material can change the structure of existing knowledge, not merely append to it. A later fact may revise an earlier conclusion, replace stale state, or force relationships to be reorganized.

The resulting unit size therefore depends primarily on surviving semantic information.

Multi-Context Merge

The proposal explicitly permits merges across independently generated contexts.

A case context may combine project, user, task, and tool context.

These inputs may already be dense semantic units.

The merge produces a new case-specific semantic state.

This supports hierarchical context construction, agent handoff, project-to-task and repository-to-case projection, merging of parallel semantic analyses, and recomposition after tool use.

A global schema may be useful in some implementations, but the architecture does not depend on one.

Case Reconstruction Instead of Incremental Context Compaction

The model reconstructs case context at inference time, before accumulated context reaches any size threshold.

There is no required cycle of continuous growth followed by emergency compaction.

Instead, each case reconstructs the context it needs, executes inference, and discards active context afterward.

Semantic integration is not confined to one pipeline stage; it may be used whenever fragmented or changing information must be turned into coherent state.

Its role is architectural and applies throughout case construction, persistence, and reconciliation.

Shared and Managed Knowledge Across Agents

Because durable semantic knowledge and episodic history remain external to active inference context, they may be managed independently of any particular agent, conversation, or runtime instance.

Knowledge may therefore be:

• organized into collections;
• indexed through lexical, vector, structured, or hybrid retrieval;
• partitioned by scope, project, user, entity, task, domain, or organization;
• versioned, replicated, or migrated;
• shared between agents;
• restricted through access-control policies;
• reprocessed or reindexed without modifying agent logic;
• retained or expired according to explicit policy.

These operations are compatible with common retrieval-augmented generation practices.

Shared recoverability and shared active context are independent concerns.

An agent receiving access to a knowledge collection need not receive the collection itself. For each case, retrieval, ranking, selection, and semantic integration determine which material contributes to the active case state.

Conceptually:

shared durable knowledge
  -> retrieve candidates for current case
  -> rank
  -> select necessary material
  -> integrate
  -> provide minimum sufficient case state to agent

Different agents may therefore operate over the same external knowledge base while receiving different case-specific semantic projections.

For example:

shared project knowledge:
    architecture
    build system
    deployment history
    previous incidents
    user decisions
    tool observations

A build agent may receive only:

build commands
dependencies
platform constraints

A debugging agent may receive:

current failure
relevant previous incidents
affected components
recent tool observations

An architecture agent may receive:

current architectural state
surviving constraints
relevant decisions
selected historical evidence

The underlying knowledge may be common while active inference context remains case-specific.

This permits multi-agent systems to share durable knowledge without requiring agents to exchange complete prompts, conversation transcripts, accumulated contexts, or internal runtime state.

It also permits knowledge infrastructure to be managed using familiar retrieval practices while preserving strict case-local context construction. A system may change indexes, retrievers, ranking strategies, collection boundaries, or retrieval representations without requiring every agent to inherit a larger active context.

The principle is:

Shared knowledge should increase recoverability, not force context accumulation.

Inter-Agent Handoff Through Recoverable Knowledge

Under the proposed model, agent handoff need not be implemented as direct transfer of accumulated context.

A common handoff model is:

Agent A context
  -> summarize or serialize
  -> transfer
  -> Agent B context

This approach couples Agent B to the way Agent A accumulated and summarized its context, so irrelevant state and transformation errors can cross the handoff boundary.

An alternative supported by inference-scoped semantic context reconstruction is:

Agent A
  -> reconcile durable semantic changes
  -> persist recoverable knowledge

Agent B case
  -> retrieve what B needs
  -> rank
  -> select
  -> integrate
  -> reconstruct B-specific case state

In this model, Agent A contributes durable semantic changes to externally recoverable knowledge. Agent B reconstructs its own inference state according to its own case requirements.

The handoff transfers recoverable knowledge and task responsibility while each receiving agent reconstructs its own active context.

This changes handoff behavior in several ways:

• agents may use different inference models or context formats;
• each agent may receive a different projection of the same shared knowledge;
• one agent does not need to understand another agent's complete prompt state;
• historical evidence can remain recoverable without entering every handoff;
• access and scope policies can constrain what each agent recovers;
• agent replacement does not depend on preserving opaque runtime state;
• handoff size follows the receiving case.

A receiving agent can reconstruct only the state needed for its own case from shared knowledge, relevant evidence, and the current task.

The receiving agent does not need the complete context that produced those durable units.

A compact statement of the principle is:

Agent handoff may transfer recoverable knowledge and task responsibility without transferring complete accumulated context.

RAG as Knowledge Management, Not Automatic Context Injection

The proposed model is compatible with common RAG infrastructure but assigns retrieval a narrower architectural role.

A knowledge system may use conventional retrieval infrastructure, but those mechanisms manage availability rather than deciding what enters active context.

These mechanisms may manage contextual and historical knowledge at scale.

However:

retrieved

does not imply:

included in active context

Retrieval returns candidates.

Ranking estimates potential usefulness.

Selection determines whether material is necessary for the case.

Semantic integration constructs the active semantic state.

This distinction permits a large, shared, richly indexed knowledge environment while keeping each agent inference narrowly scoped.

Conceptually:

large managed knowledge environment
  -> retrieve small candidate set
  -> rank
  -> select smaller necessary set
  -> integrate into case state
  -> infer

The amount of knowledge available to an agent may therefore be much larger than the amount of knowledge materialized into any single inference.

This separates two concerns:

knowledge availability

from:

context inclusion

A system may maximize recoverability, organization, and sharing at the knowledge layer while minimizing active context at the inference layer.

This is a central consequence of the proposed architecture.

Context Curve

Active context follows local semantic complexity.

One case may require architectural state, build constraints, and previous decisions.

The next may require only one user preference.

A later case may require almost no recovered knowledge.

Context size can therefore increase or decrease freely between inferences.

Minimum Sufficient Context

The objective extends beyond token reduction.

A case should receive the smallest semantic state that still permits correct resolution.

In practice, this minimum will often be approximate. The design objective is practical sufficiency, not mathematical optimality.

The proposal uses local sufficiency as a design objective for context construction.

Compression, Integration, and Reconciliation

The proposal distinguishes three conceptual operations.

Compression

Compression reduces representation size while preserving useful information.

Its primary objective is a smaller representation.

Semantic integration

Semantic integration builds a unified semantic representation from one or more inputs.

Its primary objective is a coherent semantic unit.

Reconciliation

Reconciliation handles overlap, updates, contradictions, and change.

Its primary objective is a coherent usable state.

Combined implementations

A concrete dense semantic integration capability may perform all three operations internally.

Separate runtime components are optional.

The distinction exists to clarify behavior and failure modes.

Case Construction

For a new input, an implementation following the proposed model may:

• retrieve semantic and episodic candidates
• rank them
• select what the case needs
• integrate selected material into a dense case unit
• materialize that unit for the inference capability
• execute inference
• update durable knowledge when needed
• discard active case context

This sequence is conceptual.

Implementations may combine adjacent stages while preserving the relevant architectural behavior.

Independence Between Cases

Two consecutive inferences may require completely different semantic states.

For example, one case may need project architecture, build constraints, and a previous decision.

The next may need only the user's language preference.

A case context does not automatically contain the previous one.

Knowledge passes between cases when the later case actually requires it.

Episodic Retrieval on Demand

When a question depends on historical sequence, the system may query episodic history.

For example:

"What did we decide before changing the architecture?"

The system may:

• recover relevant events
• preserve or reconstruct temporal order
• select necessary evidence
• build a dense semantic projection for the case
• infer from that projection

Cases that require history can load it selectively without making history part of every inference.

Scope

Semantic units may belong to different scopes.

Scope can be as broad as a global or project context and as narrow as a single task or case.

Scope may influence retrieval, ranking, selection, semantic integration, and persistence.

Semantically similar knowledge may still be inapplicable when it belongs to another scope.

Scope information may remain in external metadata.

Provenance

The system may preserve origin or provenance.

Provenance records where a unit came from, which can matter later for audit, ranking, or conflict resolution.

Provenance can support audit, debugging, ranking, reconciliation, and later review.

Active context may omit provenance that has no effect on the current inference.

External references may remain attached to durable units.

Temporality

Time may affect semantic validity.

A unit may carry external temporal metadata for creation, update, validity, and observation time.

The proposal does not prescribe a particular temporal model.

Time matters when knowledge can become stale or when event order changes interpretation, so temporal metadata may affect both retrieval and reconciliation.

It may remain outside the semantic payload unless the case needs time as part of the meaning.

Contradictions

Recovered candidates may conflict.

For example:

deployment:local only

and:

deployment:cloud required

Integration should produce a useful case state based on available evidence.

When candidates conflict, integration should use available scope and temporal evidence to determine whether the conflict can be resolved; otherwise the uncertainty should remain explicit.

A result may be:

deployment:local only

or:

deployment:conflict unresolved between local-only and cloud-required states

depending on available evidence.

The proposal expects useful semantic handling without invented certainty.

Failure Classes

A case may fail even when relevant knowledge exists.

For analysis and inspection, failures should be traced to the stage that produced them. A missing fact could reflect absent knowledge, failed retrieval, an overly aggressive selector, or loss during integration.

These classes separate failures that may look identical at inference time but originate in different parts of the architecture.

For example, the same missing fact can originate in several stages of the pipeline, so inspection must distinguish whether the problem began in storage, retrieval, selection, integration, or materialization.

An inspectable implementation should make these distinctions recoverable where practical.

Dense Semantic Integration Failures

Semantic integration is especially risky because it can silently change meaning. A merge may collapse distinct entities, erase a constraint, or turn uncertainty into an unsupported conclusion.

Dense semantic integration is a critical operation because failures at this stage can silently alter the state presented to inference.

It should therefore be tested for semantic preservation under the kinds of transformations the system actually performs, especially around negation, entity separation, contradiction, uncertainty, and repeated recomposition.

Recursive Degradation

Repeated recomposition may progressively remove useful information.

A unit produced from already condensed material cannot recover information discarded by an earlier transformation unless another source reintroduces it.

Implementations should therefore avoid assuming that semantic loss can be reversed automatically.

When exact recoverability matters, original sources or episodic evidence should remain separately available.

One-Case Inference

The expression one-case inference means that each case reaches the inference engine as a self-contained inferential unit.

The term places no constraint on internal reasoning, computational pass count, tool use, external loops, or iterative sampling.

Its defining property is that execution does not depend on loading a growing accumulated conversation as historical state.

Tools

Tool results may participate in active case state.

A case may:

• begin from a dense semantic state
• request a tool
• receive a tool result
• integrate that result with current case state
• continue inference

Tool effects may also feed the closing phase and durable knowledge update.

Persistence can preserve semantically durable effects while transient tool output remains ephemeral.

Orchestration

Orchestration may remain deterministic software, with semantic models used only where semantic judgment is required.

Deterministic software can handle the mechanical parts of the pipeline, leaving semantic judgment to components that actually need it.

Inference or semantic models may be used where semantic judgment is required.

Mechanical operations can remain conventional software.

Implementation Agnosticism

The proposal defines conceptual operations and observable properties while leaving implementation choices open. Its claims should therefore be evaluated at the level of behavior, not tied to a particular stack.

The same architectural model may be implemented through different mechanisms.

A concrete tool or representation may serve as an example or reference implementation without becoming part of the proposal itself.

Architectural Invariants

The following invariants characterize the proposed model.

They describe architectural properties independent of a particular implementation.

No dependence on complete accumulated history

An inference can execute without loading all previous turns.

Ephemeral case context

The active context of a case can be discarded after inference.

External durable memory

Durable knowledge survives outside active context.

Selective retrieval

Retrieval targets candidate material for the current case.

Selection by necessity

Related material does not enter case context automatically. Inclusion depends on its expected contribution to case resolution.

Retrieval and context construction remain distinct

Recovered material first enters later construction stages, which decide whether it reaches active context.

Dense semantic integration

Multiple selected units can be transformed into a new dense semantic unit before downstream inference.

No mandatory semantic concatenation

Case state does not require direct appending of recovered units.

Recomposability

Previously generated semantic units may become inputs to new semantic integrations.

Multi-context merge

Independently generated contextual units may be merged into a new contextual unit.

Mutable consolidated state

New knowledge may reorganize, merge, correct, invalidate, or replace previous semantic state.

Separate episodic history

Episodic history may be preserved independently of active context.

Consolidated persistence

Durable semantic changes produced by a case may be integrated and persisted before closure.

Variable context size

Context size may increase or decrease freely between inferences.

Independence between cases

A case does not automatically inherit the materialized context of the previous case.

Discardability

Discarding active context does not destroy durable knowledge.

External retrieval representation

Embeddings, vectors, lexical indexes, and related artifacts remain external retrieval mechanisms and need not form part of semantic units.

Implementation agnosticism

The architectural model does not depend on a particular model, tool, format, provider, or storage backend.

Reconstructed continuity

Agent continuity arises from recovering and reconstructing required knowledge for each case.

Knowledge management is independent of active agent context

Durable semantic knowledge and episodic history can be managed independently of any particular agent, which allows shared knowledge infrastructure without shared active context.

Shared recoverability does not imply shared context

Multiple agents may access common knowledge sources while receiving different case-specific semantic states.

Selective inter-agent knowledge transfer

Knowledge may pass between agents through externally recoverable units and case reconstruction. Complete transcripts, prompts, accumulated contexts, and runtime state remain unnecessary for most handoffs.

Retrieval access does not imply context inclusion

An agent may have retrieval access to a large knowledge environment while materializing only the subset necessary for the current case.

Desirable Properties

In addition to the architectural invariants, an implementation may seek the following properties.

Semantic density

Maximize useful information per token or representation unit.

Inspectability

Permit inspection of retrieval, ranking, selection, integration, materialization, and persistence decisions.

Mechanical determinism

Keep non-semantic operations in conventional deterministic software when practical.

Durable persistence

Avoid dependence on volatile runtime state for long-term knowledge.

Portability

Permit migration of semantic units, indexes, and episodic history between implementations.

Legible degradation

Failures in knowledge, retrieval, ranking, selection, integration, or materialization should remain identifiable by class.

Context minimization

Avoid introducing material that does not affect case resolution.

Approximate semantic stability

Repeated processing without materially new information should avoid unnecessary semantic drift when practical.

Merge quality

Merging semantic units should preserve necessary complementary information while reducing redundant representation.

Shared knowledge manageability

Permit contextual and historical knowledge to be organized, indexed, scoped, governed, and shared across agents without requiring wholesale transfer into active inference context.

Non-Goals

The proposal deliberately leaves several goals outside scope. It does not aim to reconstruct prior conversations exactly from semantic memory, preserve complete original wording, replace episodic audit, guarantee reversible compression, maintain an infinite session, maximize context quantity, or preserve all knowledge in every inference. It also imposes no vector database, embedding system, specific LLM, canonical semantic serialization, exact associativity, exact idempotence, lossless recursive recomposition, or global fact schema.

Minimal Example

Durable semantic store:

U1 = user prefers concise technical responses
U2 = project X uses C
U3 = project X has no external dependencies
U4 = project Y uses Python
U5 = project X uses an append-only event log

External retrieval index:

U1 -> v1
U2 -> v2
U3 -> v3
U4 -> v4
U5 -> v5

Input:

"Let's implement the parser for X"

Retrieval may produce:

U1
U2
U3
U5

Selection may retain:

U2
U3
U5

Semantic integration may produce:

project:X;
implementation_language:C;
dependencies:no external dependencies;
event_storage:append-only log

The inference starts from that case context.

Unrelated knowledge such as:

project:Y;language:Python

does not need to enter the case.

The conversation in which the append-only log was originally chosen also remains unnecessary unless the current task depends on that history.

Example of Multi-Context Merge

Suppose the system has:

U_project:
project:X;language:C;deps:no external

U_task:
task:parser;requirement:preserve byte offsets

U_user:
response_style:concise technical

U_tool:
existing_library:text routines available

These units may be integrated into one case context.

A possible result is:

project:X;
implementation:C;
dependencies:no external;
task:parser;
parser:preserve byte offsets;
reuse:text routines;
response_style:concise technical

The inference starts from this consolidated case state.

Example of State Change

Previous semantic unit:

project:X;transport:HTTP

New decision:

project X will use local Unix domain sockets instead of HTTP

A recomposed semantic unit may become:

project:X;transport:Unix domain sockets

The previous state remains separately recoverable when historical evidence matters.

Current semantic state need not preserve both transports as simultaneously valid.

Example of Context Variability

Case A:

"How do I build the project?"

Required context may include:

build commands
dependencies
platform constraints

Case B:

"What did we decide about storage?"

Required context may include:

storage decisions
relevant alternatives
current state

Case C:

"Thanks"

Required context may be minimal or empty.

Each context follows local case requirements.

Operational Definition

The proposed model may be summarized as follows:

current input
  -> retrieve candidate semantic units and episodes
  -> rank
  -> select necessary material
  -> generate one dense case unit
  -> materialize it for the inference capability
  -> infer
  -> respond
  -> update durable semantic knowledge when needed
  -> discard active case context

Retrieval representations such as vectors remain external to the semantic units they index.

Compact Definition

This proposal describes an agent architecture in which the system:

• receives an input
• retrieves potentially useful semantic units and episodes
• ranks candidates
• selects material necessary for the current case
• transforms selected material into a new dense semantic unit
• uses that unit as the semantic state of the case
• materializes the representation required by the inference capability
• executes a self-contained case inference
• returns the output
• integrates semantic changes produced by the case
• persists durable semantic units for future retrieval
• maintains retrieval representations externally as needed
• discards active case context

Agent continuity arises from reconstructing the knowledge required for each new inference.

The proposed model can be summarized by the following principle:

Preserve durable knowledge externally, reconstruct active semantic state for the current case, and discard that state when the case ends.

Related Work

This proposal exists within a broader body of work on retrieval-augmented generation, external memory, episodic and semantic memory, context compression, and multi-agent systems.

References

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks - Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, Douwe Kiela.

https://arxiv.org/abs/2005.11401

• MemGPT: Towards LLMs as Operating Systems - Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, Joseph E. Gonzalez.

https://arxiv.org/abs/2310.08560

• Generative Agents: Interactive Simulacra of Human Behavior - Joon Sung Park, Joseph C. O'Brien, Carrie J. Cai, Meredith Ringel Morris, Percy Liang, Michael S. Bernstein.

https://arxiv.org/abs/2304.03442

• ReAct: Synergizing Reasoning and Acting in Language Models - Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao.

https://arxiv.org/abs/2210.03629

• Lost in the Middle: How Language Models Use Long Contexts - Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang.

https://arxiv.org/abs/2307.03172

License

2026 KaisarCode

This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (CC BY-NC-ND 4.0).

You are free to share, copy and redistribute the material in any medium or format, provided that you give appropriate credit, do not use the material for commercial purposes, and do not distribute modified versions of the material.