A conversational assistant does not need every previous message in every prompt. It needs the right context for the current task. That context may include a recent user request, an explicit preference, a summary of unfinished work or an approved source passage. These are different kinds of information and deserve different handling.
This guide proposes an application-managed context design using OriginChainDB records and retrieval. It does not claim that a database automatically creates trustworthy memory. The application remains responsible for ownership, permission, retention, summarization and prompt assembly.
1. Begin with a specific task
Use a fictional support assistant that helps a user track a replacement order. The recent conversation includes an order ID, a preferred delivery window and an old address that was later corrected. The assistant should preserve the useful request without treating the superseded address as current.
Define the task’s trusted source of current facts. Order status should come from the order record. A conversation can explain what the user asked, but it should not override a current fulfillment record just because an older message sounds confident.
2. Separate the record types
Keep messages with stable IDs, conversation ownership, sequence information and creation times. Keep summaries as derived records with a source range and version. Keep retrieved business evidence as references to its source record and revision.
An illustrative starting table for a synthetic exercise is:
CREATE SCHEMA context_demo_20261010;
CREATE TABLE context_demo_20261010.messages (
id TEXT PRIMARY KEY,
conversation_id TEXT,
owner_id TEXT,
sequence_no BIGINT,
role TEXT,
body TEXT
);
INSERT INTO context_demo_20261010.messages
(id,conversation_id,owner_id,sequence_no,role,body)
VALUES
('m1','chat1','u1',1,'user','Please help track replacement order r42.'),
('m2','chat1','u1',2,'user','A morning delivery window would help.'),
('m3','chat1','u1',3,'assistant','I will check the current order record.');This minimal fixture deliberately omits real personal data. In a production schema, add the timestamps, lifecycle state and ownership constraints required by your application. Do not infer authorization from a client-supplied owner ID alone.
3. Read recent context deterministically
SELECT id,sequence_no,role,body
FROM context_demo_20261010.messages
WHERE conversation_id = 'chat1'
ORDER BY sequence_no,id;The expected sequence is m1, m2, m3. In a server application, derive the allowed conversation from the authenticated principal and use supported parameter binding. A query that filters a conversation ID is not a complete authorization system.
For long conversations, keep a bounded recent window. Decide whether that window contains turns, messages or tokens; those are different units. Preserve enough adjacent context that a short reply such as “yes, that one” remains interpretable.
4. Summarize without erasing provenance
A summary is a lossy transformation. Store which message range it summarizes and which process produced it. Treat the summary as derived context, not a new authoritative user instruction.
For the fixture, a useful summary might say that the user wants an update on order r42 and prefers morning delivery. It should not state that morning delivery is confirmed. The source contains a preference, not a fulfillment guarantee.
When a user corrects a detail, record that correction and decide how it invalidates older summaries. Do not simply append conflicting facts and hope the model chooses the current one.
5. Retrieve evidence for the current question
OriginChainDB SQL can locate exact order identities, while FTS or vector retrieval can help find relevant support guidance. Keep those roles explicit. Searching for a related policy is not the same operation as reading the current status of order r42.
If you store embeddings, record the model setup and keep query embeddings compatible with the document embeddings. Link every retrieved chunk back to its source. Enforce permissions before any source text, title or citation enters the model prompt.
6. Assemble a prompt with clear boundaries
Keep application instructions, current user input, recent conversation and retrieved evidence in separate roles or clearly labeled sections supported by your model interface. Retrieved text can contain quoted instructions; that does not make it authoritative over the application.
Give the assistant an explicit fallback when evidence is missing. It should say that the current delivery status is unavailable rather than turn a remembered preference into a promise. Keep credentials and internal diagnostic data out of the prompt.
7. Test corrections and removal
Create tests for a corrected preference, an expired summary, an unauthorized conversation and a question that has no supported answer. Inspect the actual context sent to the model, using synthetic data, so you know which records influenced the response.
Define retention for messages and derived artifacts. If a conversation is removed, the application needs a policy for its summaries, indexed chunks and embeddings too. Keep the cleanup job recoverable and verify its outcome.
A useful context system remembers enough to help, distinguishes requests from facts and can explain where its information came from. Start with that contract before expanding the amount of stored memory.
Explore the OriginChainDB documentation for the current SQL, FTS and vector interfaces.
Give every context item a declared authority and lifetime
Use a compact context manifest while designing the application. For each item, record its source, purpose, version and expiration rule. A recent user message can express a current request. A business record can establish the current order state. A summary can compress earlier conversation, but it should retain the message range it represents and should not gain authority merely because it is shorter.
| Context item | What it may establish | What it must not silently establish |
|---|---|---|
| User request | The task the person is asking for | That an external action has succeeded |
| Delivery preference | A requested morning window | A confirmed carrier commitment |
| Conversation summary | A derived account of selected messages | A new verified business fact |
| Current order record | The status returned by the authorized source | Permission to expose another user’s order |
This table becomes a review tool for prompt assembly. If the model says morning delivery is confirmed, inspect whether the context accidentally promoted the preference into a fact. More stored history is not a remedy for a poorly defined authority boundary.
Build a bounded recent window without reversing time
For a short synthetic conversation, reading all messages is easy. A real conversation may be much longer. To inspect the latest messages, a supported SQL query can order by sequence descending and apply a limit; the application can then reverse that selected window before presenting it chronologically to the model.
SELECT id, sequence_no, role, body
FROM context_demo_20261010.messages
WHERE conversation_id = 'chat1'
ORDER BY sequence_no DESC, id DESC
LIMIT 2;The sample returns m3 followed by m2. If the prompt expects chronological order, arrange those two rows as m2 then m3 in the application. Do not confuse “latest two messages” with “first two messages in ascending order.” The authenticated application must still establish that chat1 is permitted before performing or returning this read.
Choose a budget in the unit your model interface uses and test it. A message count does not bound token count when one message can be very long. Reserve space for current user input and necessary business evidence before adding optional history. Reject or summarize oversized material through a declared policy rather than allowing an old message to displace the question being answered now.
Rehearse a correction and inspect the assembled prompt
Add a fictional fourth message saying that the user now prefers an afternoon window. The current preference should become afternoon, while the earlier morning statement remains historical. Mark summaries covering the earlier preference as stale or regenerate them through your chosen application workflow.
Inspect the actual synthetic context packet sent to the model. It should identify the correction and should not contain two unlabeled, conflicting preferences. An old summary must not overwrite the later user message. Record which source messages and current business records were included so a failed response can be investigated without guessing what the model saw.
Test removal across derived records
When the application removes or expires a conversation, decide what happens to its summaries, searchable chunks, embeddings and cached responses. Deleting the primary message row does not by itself prove that every derived copy is gone. Track cleanup work as recoverable tasks and verify the result through the retrieval paths the assistant actually uses.
Run the same question as a permitted user, another user and a user whose access has just been removed. The system should not expose previous titles, summaries or citations from disallowed conversations. The first successful outcome is a small context builder that selects recent, relevant, permitted information and can explain each item’s origin. Increasing memory volume should come after that contract works.