The Context Database That Builds Itself

---

An agent that serves people produces two useful products. The first is the answer. The second is the operational record around that answer: what the user asked, what the agent returned, which durable objects were involved, and which parts of the work are worth finding again.

In KDCube, the host already sits at the door of every turn. It accepts the message, binds the user, runs the agent, carries the stream, hosts declared files, and closes the turn. That makes the door the natural place to persist a shared conversation record. The application does not need to invent its own reload format or indexing pipeline.

The first searchable material needs no new agent protocol. The user prompt and final answer already cross the host boundary. The native KDCube ReAct agent also produces a compact working summary, retrieval anchors, and selected notes as part of its normal turn protocol. This is the sense in which the platform documentation describes the conversational index as managed by the agent as a byproduct of operation, not curated. The ReAct agent’s runtime path gives those signals identity, persistence, indexing, and a way back to the durable objects they name.

There are two separate contracts. A framework-neutral record rebuilds what the person saw: messages, context objects, attachment and output-file cards, and selected live activity. Topic discovery runs over separate content rows and then materializes the matching turn from its TurnLog. Every hosted-agent minimal TurnLog projects its folded user submissions and final completion into those search rows. The ReAct agent uses the same role-level contract and adds the summaries, anchors, notes, and attachment interpretation produced by its richer turn protocol. LangGraph and Claude Code keep their own checkpoints or session memory; platform conversation search does not replace them.

01 One turn, two products

The framework-neutral fallback is concrete. When it is the writer for a completed turn, the platform constructs the smallest valid TurnLog from the turn boundary:

• every user message folded into the turn, including whether it arrived as a prompt, follow-up, or steer;
• user context events and uploaded-file references;
• optional progress steps supplied by the adapter;
• references for files the assistant hosted into conversation storage;
• one final assistant completion.

The same fallback writes a small conv.timeline.v1 artifact containing the conversation title, start time, last activity time, and turn id. Its block list is empty. Its job is to make the conversation listable and refresh its recency, not to pretend that a run-to-completion adapter produced the ReAct agent’s progressive timeline.

Recorded communicator events and stream aggregates form another reload layer. They can preserve dynamic objects that were shown live, such as timing and cost badges, citations, steps, or a code-execution panel. The adapter must export those records before the turn closes. Tool activity is user-visible product state here, not a replacement for the framework’s private checkpoint.

This baseline is enough for conversation listing, fetch, reload, user and assistant bubbles, attachment cards, and hosted output files. Its TurnLog index row is compact accounting — timestamps, source ids, block count, tokens and feedback summary — and is not embedded. It also omits the prompt and answer text. Instead, the same minimal write derives one index-only row for each folded user submission and one for the final assistant completion. Those role rows carry conversation, turn, app, agent, event type, batch, and arrival-time identity. Their embeddings support semantic discovery when the model service is available; their stored text remains available to lexical and trigram search if embedding fails. Reload and discovery therefore share one accepted turn without confusing the TurnLog artifact with a transcript row.

02 What the native ReAct agent contributes

The native KDCube ReAct agent owns an ordered, model-visible block stream. That lets its adapter persist a rich TurnLog and project the same accepted blocks into a progressive conversation timeline. The timeline and TurnLog are siblings, not layers built on top of one another: the timeline is conversation-level, while the TurnLog is the persisted envelope for one turn.

The adapter writes the shared prompt/completion rows and adds searchable rows for semantic interpretation produced by its own protocol:

• user prompts and supported user-attachment text;
• assistant completions;
• the agent’s working summary of the goal, outcome, important facts and refs;
• retrieval anchors for literal phrases worth finding again;
• internal notes that the adapter deliberately exposes to this index.

Those rows are tagged with their role and embedded where that projection uses the model service. The full TurnLog, timeline, stream payloads, and arbitrary produced files are not blindly vectorized. A file may be binary, huge, private to an owning namespace, or meaningless without a format-specific extractor. Instead, the agent names important files inside context-rich completion or summary text. Search finds that language and its conv:fi: reference; the agent can then pull the exact bytes through the authorized resolver.

This division is useful. The host already owns the prompt and answer and can index them without asking the model for anything else. The ReAct agent additionally authors the semantic interpretation only its turn protocol knows: what the work meant and which output matters. Those summaries, anchors, and notes improve retrieval, but they are not prerequisites for preserving and finding another hosted agent’s visible turn.

03 Other agents keep their own memory

A LangGraph checkpointer and a Claude Code session store solve continuation inside those agents. Replacing them with a KDCube timeline would replace part of the agent implementation, contradicting the reason to host an existing agent in the first place. The integration seam is projection, not replacement:

agent-private continuation             shared KDCube conversation product
--------------------------             -----------------------------------
LangGraph checkpoints            +-->  all folded inputs, answer, hosted code files,
                                       selected activity, searchable transcript rows
Claude Code session/git          +-->  all folded inputs, answer, selected tool steps,
                                       searchable transcript rows
Native ReAct agent round state   +-->  rich blocks, files, transcript rows,
                                       summaries, anchors, and selected notes

The worked LangGraph integration already demonstrates the file path. Code runs in the shared isolated-execution machinery, produced files are detected in the turn’s files/ area, the trusted host stores them under conversation scope, and compact conv:fi: refs return to the graph. The refs are placed on state["hosted_files"], so the framework-neutral recorder persists file cards alongside the answer.

Its explicit turn recorder records every folded prompt, follow-up, or steer with its event type, submission batch, and arrival time, plus all folded context events and attachment refs, the final answer, and hosted file refs. The same write produces separate user/assistant search rows. The live stream emits chat.step rows for tool starts and completions, and code execution can emit subsystem stream panels. Recording state distinguishes minimal from rich: a minimal TurnLog prevents a duplicate log while leaving selected chat events and canvas/tool/subsystem streams eligible for their own replay artifacts. The graph’s checkpointer remains untouched.

The current Claude Code host has a different purpose. It commonly works on an application workset for trusted operator or editor roles, and its git-backed session store preserves Claude’s own continuation. That store is not automatic conversation-file hosting, and the generic runner does not claim security-grade workspace isolation. Treating it as a hostile-user, fully isolated multi-user agent would require a stronger workspace and execution profile than this integration currently provides.

The Press integration lets the base fallback write its TurnLog. It therefore records every folded user message, context object and attachment ref, followed by Claude’s final answer, and derives searchable user/assistant rows from that same payload. Claude emits tool starts and results as chat.step events; when the app includes those event types in its recorded conversation selector, the Steps view can be replayed. Files Claude edits in the application workset remain application state; they become conversation file cards only if the trusted host validates and publishes them into conversation storage and supplies hosted_files, which Press does not do today.

04 Neighboring context districts

• The agent’s working context — what the current adapter places in the model-visible prompt or restores from its private continuation store.
• The conversational memory index — the searchable temporal record of prior exchanges and semantic turn contributions.
• Durable user memories — curated facts, preferences, and decisions, visible and reconcilable by the user through their own tools and UI.
• The pin board — objects a person deliberately set aside.

The conversational district needs no manual curation. It still consumes storage, database work, and embedding calls where semantic indexing is enabled; “passive” describes how it is authored and maintained, not zero cost.

05 The index over the flow

Current conversation search has three candidate generators. Semantic retrieval uses embeddings and cosine similarity to find a paraphrase — “the spreadsheet trouble from last week” can find an openpyxl discussion. Lexical retrieval uses weighted text search to find exact names, error strings, and phrases; retrieval anchors strengthen this path. Trigram fuzzy retrieval catches misspellings and near-literal variants that exact lexical matching can miss.

All three operate on separate scoped content rows. Semantic retrieval requires an embedding on a row; lexical and trigram retrieval use its stored text and search fields. After candidate generation, the matching turn ids are joined to their TurnLog so the requested snippets and visible turn objects can be materialized. The TurnLog payload is the reload source, not the candidate text. The three ranked lists are fused with reciprocal-rank fusion. Recency is then applied as a configurable lift, with a seven-day half-life by default. It is not a fourth retrieval list.

The index also knows more than similarity:

• Who said what. Search can target the user’s words, assistant answers, summaries, notes, or supported attachment text.
• Where in the conversation. The turn catalog orders recorded turns, so ordinal and temporal questions have an explicit lookup path.
• Which surrounding snippets to return. A caller can request user and assistant snippets from the matched turn rather than receiving an isolated sentence; pairing is requested materialization, not an unconditional rule.
• How far to search. Scope can remain in one conversation or widen to the signed-in user’s conversation history.

The agent’s search tool, application APIs and named services, and the person’s chat search use the same conversation-search service and identity boundary. A search hit carries its conversation and turn identity. A separate known-turn materialization path can then reconstruct that turn’s hosted files, user attachments, and citations from its TurnLog. Topic search does not automatically return an exhaustive inventory of every ref authored in the matched turn.

06 Addresses, not copies

Durable conversation objects use canonical references in the conversation namespace. conv:fi: identifies file bytes and workspace objects; conv:ar: conversation records; conv:tc: tool records; conv:so: source rows; conv:ws: working summaries; conv:su: summary/search records; and conv:ev: accepted event occurrences.

A durable cross-surface ref carries both ownership levels:

conv:fi:conv_<conversation_id>.turn_<turn_id>.files/report.pdf

conv: names the owning realm. conv_<conversation_id> names the conversation inside that realm. The turn segment records where the object was authored. A later edition can receive a later turn’s ref while the earlier retained object keeps its own address.

This is how indexed language leads back to payloads. A completion or summary can say, “Produced the final forecast at conv:fi:.../forecast.xlsx after correcting the timezone conversion.” Search retrieves the meaningful sentence. Pull then materializes the exact retained file. The index does not need to vectorize the workbook to preserve a route back to it.

07 What a turn actually sees

The shared harness workspace is sparse. Its physical layout gives adapters a common place for current-turn uploads, produced files, editable project state, snapshots, and materialized external evidence. These directory names express meaning, not one hardcoded storage backend. Conversation files may be backed by local or S3-compatible storage. Project state may use custom hosted artifacts or an optional git lineage. External objects remain owned and authorized by their provider even after a resolver materializes bytes into the current turn.

The native ReAct agent currently exercises the full workspace lifecycle: ANNOUNCE, pull, checkout, code execution, optional snapshots, and cleanup. Another adapter can use the framework-neutral resolver and workspace primitives without inheriting the ReAct agent’s model-facing tools or round protocol. The LangGraph example does this for attachments and code outputs.

The physical workspace is execution state. A fresh turn must not assume an old worker directory exists. At turn end, the directory may be cleaned or retained for configured diagnostics; only objects explicitly hosted, published, or committed to the selected durable project mechanism are long-term state.

08 What actually builds itself

For the native KDCube ReAct agent, the full searchable context accrues during ordinary work: the user asks, the agent answers, the agent writes its working summary and anchors, and the runtime persists and indexes those signals. No application author writes a parallel indexing pipeline.

For another hosted agent, the same work happens at the shared turn boundary. The minimal recorder saves the reloadable TurnLog and derives separate search rows from the folded prompts and final answer the host already possesses. No summary hook or model-facing tool is needed. An adapter may additionally contribute summaries, anchors, or notes when its product benefits from them, and may explicitly publish durable files while preserving its own checkpoints and session memory.

09 The honest boundaries

• Conversation search is hybrid, not embedding-only. Semantic, lexical, and trigram candidates all require separate content rows; the TurnLog is fetched after a turn matches. Produced files are recoverable by ref, but their arbitrary contents are not automatically full-text searched.
• Every minimal hosted turn writes separate prompt/completion content rows from the same TurnLog payload. Embedding is best effort; lexical and trigram discovery remain available when the embedding provider fails. The ReAct agent adds summary, note, anchor, and supported-attachment projections.
• The ported LangGraph adapter preserves every folded submission and keeps event/stream replay independent of its minimal TurnLog. This platform record captures the user-visible turn boundary, not the graph’s private checkpoint transcript.
• Retention applies. Rows carry TTL, purge paths exist, and a ref resolves only while its retained object and authorization remain valid.
• Semantic indexing invokes the configured embedding provider. Lexical and trigram retrieval avoid embedding-provider calls but still consume ordinary database and storage resources.
• Claude Code’s current generic host is not a security sandbox. Its practical multi-user use is for trusted participants unless an integration adds a stronger isolation boundary.
• Claude workset edits and session git are application/agent state. A file becomes a durable conversation download only through a trusted hosting operation that validates the bounded output and emits its conv:fi: ref.
• Curated user memories remain a separate district. The passive conversation record preserves what was authored; it does not rewrite it into what a user “really meant.”

· Read the implementation contracts

· Continue with the related articles