Zengram-Lite: An In-Browser Agentic-Memory Framework - Semantic Knowledge, Session Tracking, and Token-Budgeted Context

Availability

• The web-target bundle is attached to a GitHub Release; publication to npm is pending.The bundle is free for any use, including commercial use.Source: Availability · pp. 1–2
• The Zengram framework source is planned for release under Apache-2.0, but the linked Zeta engine remains closed, so the WebAssembly build is distributed as a prebuilt binary.Source: Availability · p. 2
• Three interactive demos, the API reference, and the smoke and end-to-end harnesses are public in the zengram-lite repository.The demos cover agent memory, the SQL playground, and a local browser agent.Source: Availability · p. 2
• Every §7 measurement can be reproduced from the repository against the published artifact using the listed commands.Source: Availability · p. 2
• The companion engine report is identified as [ZL].Source: Availability · p. 2

1 Introduction

• Client-side vector stores support semantic recall, but leave fact confidence and contradiction, conversation structure, and token-budgeted prompt selection to application code.Source: §1 · p. 2
• Server-hosted agent-memory frameworks provide coherent memory and context management, but run in Python or Node processes that place the framework and user data on the server side.Source: §1 · p. 2
• 12The framework combines a knowledge tier with lifecycle and provenance, a session-tracking tier, and token-budgeted context assembly over one transactional engine in a single WebAssembly artifact.Source: §1 · pp. 2–3
• The bring-your-own-result seam runs the framework’s real code paths using asynchronous LLM and embedder results computed by the application in JavaScript.Source: §1 · p. 3
• The superset bundle combines the framework and a full transactional SQL engine with copy-on-write branching in one ∼2.95 MB artifact.Source: §1 · p. 3
• The framework is presented as a v0.1 preview and as the smallest, most complete public form of the full Zengram framework.Source: §1 · p. 3

2 Background and Related Work

• Server-side agent-memory systems offer a store, lifecycle, and context management, while Zengram-lite’s stated difference is that the framework and store run in the browser tab.The cited systems include MemGPT / Letta [1], mem0 [2], and LangChain and LlamaIndex.Source: §2 · p. 3
• Browser embedding and nearest-neighbor systems support semantic recall, but lack a fact lifecycle, session or turn model, and context assembly.Zengram-lite uses this class of embedder at its boundary; these systems are the knowledge tier’s substrate, not a substitute for the framework.Source: §2 · p. 3
• Without a framework, browser agents keep conversation history and tool-call logs in ad-hoc application structures and manage context manually, with no shared schema linking facts to their originating turns and tool calls.Source: §2 · pp. 3–4
• Zengram-lite identifies the client-side gap as a coherent agentic-memory framework combining a knowledge lifecycle, first-class session tracking, and token-budgeted context assembly in one artifact.Source: §2 · p. 4

3.1 What zengram-lite inherits

• From zeta-lite [ZL], the framework inherits snapshot-isolated transactions, HNSW and full-text retrieval, copy-on-write branching, OPFS snapshots, and a small headers-free artifact.The paper identifies these as engine capabilities and points to [ZL] for their mechanisms and evaluation.Source: §3.1 · p. 4

3.2 The superset bundle

• The single superset WebAssembly bundle exports both the full SQL engine and the memory tier, avoiding a second package, engine, and wasm heap when a page needs both.The framework adds roughly 0.08 MB gzip over the engine’s 2.87 MB.Source: §3.2 · p. 6

3.3 Why memory over a SQL engine

• Knowledge, session, and provenance tables share one transactional engine and snapshot, so related writes commit consistently rather than requiring reconciliation across separate stores.The cited alternative is a vector database beside a document store and hand-rolled session log.Source: §3.3 · p. 6

3.4 The schema as one system

• The current build defines 46 tables, including configuration and persistence tables and compiled-in tables whose typed APIs are not yet exposed.The compiled-in set includes task management, reminders, permission rules, subagent runs, a code graph, object knowledge, and fleet/mailbox coordination.Source: §3.4 · p. 6
• The schema’s foreign-key spine links accounts, projects, sessions, turns, parts, and tool calls, while provenance connects a derived fact to its source turn and tool call.The fact’s origin can be carried across the knowledge and session tiers under the same snapshot.Source: §3.4 · p. 6, Figure 2 · p. 7

4.1 What a fact is

• A fact is a scoped row with content, confidence, importance, lifecycle status, confirmation and contradiction counts, and timestamps used for decay.Scopes partition memory by project, session, or user within one store.Source: §4.1 · p. 8

4.2 Remember and recall

• Hybrid vector-and-full-text recall ranks facts within scope, while restating a subject supersedes its prior fact instead of adding a near-duplicate.The vector search can retrieve a semantically related fact even without keyword overlap; remember stores content verbatim rather than extracting atomic facts.Source: §4.2 · p. 8

4.3 The lifecycle: confidence, importance, decay

• A fact’s standing changes over time: confirmation raises confidence, contradiction lowers it, and untouched facts fade.Importance decays exponentially using a specified half-life, charging time since the fact’s last decay.Source: §4.3 · p. 8
• factsAboutPeer returns active facts attributed to a peer, ordered by importance, so memory can represent who said or did something.Source: §4.3 · p. 9

4.4 Provenance

• Facts extracted from a conversation retain session and turn provenance, allowing their origin to be traced to the producing turn.In v0.1 provenance is recorded and inspectable through SQL; typed traceBack/traceForward methods are planned for a later release.Source: §4.4 · p. 9

5.1 The conversation as data

• Sessions, turns, typed parts, and tool calls form relational conversation data, making questions about tool errors, branch cost, and turn contents answerable with SQL.A part is an atomic typed content unit with a JSON payload and position; tool calls have states, timing, and token cost.Source: §5.1 · p. 9

5.2 The loop, in the bundle

• The framework supports an in-tab agent loop that records exchanges and tool use, assembles prompts, and folds extracted facts or insights into knowledge.The described smoke harness checks this sequence end to end against the artifact.Source: §5.2 · p. 9

5.3 Token-budgeted context assembly

• At budget 200, only 3 of 12 turns fit and 9 are evicted; at budgets 1000 and 4000, all 12 fit.Source: Figure 3 · p. 10
• assembleContext packs system instructions, permissions, knowledge, tasks, recent history, cross-branch summaries, and pending state under a caller-supplied token budget.History is packed newest-first; remaining history is summarized or skipped when the budget binds.Source: §5.3 · p. 10
• The structured ContextWindow reports typed blocks, token use, turn counts, source ids, and a knowledge fingerprint stable for an unchanged knowledge set.An unchanged fingerprint signals that the knowledge portion of the prompt prefix is identical and can be reused.Source: §5.3 · pp. 10–11

5.4 Why this is the hard part

• The framework makes bounded, reusable prompt construction a system operation, connecting conversation state with knowledge that has been confirmed, contradicted, and traced to its source.The paper presents this as work that applications otherwise do by hand and incompletely.Source: §5.4 · p. 11

6.1 The impedance mismatch

• The browser’s synchronous wasm surface cannot await the asynchronous embedder and completion model required by canonical framework operations.A naive port would block the thread or require an async wasm surface the engine does not have.Source: §6 · p. 11, §6.1 · p. 11

6.2 The bring-your-own-result seam

• The bring-your-own-result seam has JavaScript compute asynchronous results, then hands them to the framework for its normal synchronous code paths.The framework retains its deduplication, supersession, embedding, provenance, and storage logic.Source: §6.2 · pp. 11–12
• In v0.1, extraction and reflection are not automatic: the application supplies their model-generated results.Source: §6.2 · p. 12

6.3 Engine modes: isolated or shared

• ZengramMemory can open an isolated engine or attach to an existing engine so application SQL and memory tables share one database.Shared mode reserves migration-created table names; migrations are idempotent.Source: §6.3 · p. 12

6.4 Persistence

• Persistence uses whole-database snapshots rather than incremental saves, so each snapshot is O(database size).The shipped agent throttles saves to about 60 seconds and flushes on tab hide or close; a hard crash can lose up to one throttle window of facts.Source: §6.4 · p. 12

7 Evaluation: Coverage, Framework Behavior, and Size

• The evaluation tests framework behavior and size rather than engine throughput, concurrency, or soak behavior, which are covered by zeta-lite’s evaluation.Measurements use harnesses against the published artifact and are reproducible from the public repository.Source: §7 · pp. 12–13

7.1 Functional coverage

• The harnesses pass 19 core checks and 27 agent-loop checks, while real all-MiniLM-L6-v2 vectors retrieve facts with zero keyword overlap.Together, the harnesses cover every tier, persistence, the embedding path, and the bring-your-own-result bridges.Source: §7.1 · p. 13

7.2 Context assembly under a token budget

• At 200 tokens, assembly includes system and knowledge blocks plus the three newest turns, skipping nine older turns; at 579 tokens, all twelve turns fit.Raising the budget from 1000 to 4000 tokens changes nothing, and the knowledge fingerprint stays byte-for-byte identical across repeated calls on unchanged knowledge.Source: §7.2 · pp. 13–14

7.3 Artifact size

• 2.95 MB gzipped is the bundle size, versus 2.87 MB for zeta-lite, adding about 0.08 MB gzip for the framework.The comparison is with the engine that the bundle supersets.Source: §7.3 · p. 14

7.4 End to end: the shipped local agent

• The shipped local agent stores and recalls facts by meaning, records tool calls, and persists memory to OPFS across browser restarts, with only LLM inference remote.The demo runs the framework described in §§4–6 with a real model.Source: §7.4 · p. 14

• Extraction and reflection are caller-supplied rather than automatic; remember stores content verbatim and does not split prose into atomic facts.The synchronous wasm surface cannot call the asynchronous completion model, so the application supplies extracted facts and synthesized insights.Source: §8 · p. 14
• Episodic timelines, provenance tracing, reminders, and memory branching are compiled in but currently reachable only through query(), not a wider typed JavaScript API.A wider typed surface is planned; fleet coordination, pgwire, and object-knowledge ingest are excluded from the browser build by design.Source: §8 · pp. 14–15
• Durability depends on the last persisted snapshot, with no incremental save, and each snapshot costs O(database size); snapshots do not yet capture branches.This persistence model and the branch-snapshot limitation are inherited from zeta-lite.Source: §8 · p. 14
• The paper measures framework coverage, context assembly, and size, but provides no framework micro-benchmarks; engine performance is reported in zeta-lite.The memory tiers are ordinary tables and queries over that engine.Source: §8 · pp. 14–15

• Zengram-lite adds fact confidence and importance lifecycle, session and turn data, and token-budgeted prompt assembly with a reuse fingerprint.The conversation is modeled as sessions, turns, typed parts, and tool calls rather than an opaque array.Source: §9 · p. 15
• The framework runs on the zeta-lite engine in one approximately 2.95 MB artifact, inheriting transactional consistency across tiers and branchable memory.Source: §9 · p. 15
• The bring-your-own-result seam lets the framework run on a browser surface that cannot call the LLM itself.Source: §9 · p. 15