Agentic Memory Transparency

Why VEKTOR Slipstream Now Shows You Exactly What It Remembers

There's a specific kind of unease that comes from knowing an AI assistant remembers things about you and having no way to check what, or why, or whether it's even correct.

Most people who've used one of these tools for more than a few months have felt it: a passing comment gets remembered forever, a fact goes stale and nobody tells you, or you simply have no idea what's sitting in storage next to your name. That discomfort is what we have all been working with for the last four years. It's a completely reasonable response to being asked to trust something you can't see inside.
We built Memory Transparency because we think that issue shouldn't be the cost of having a memory that actually works. 

Memory you can see is memory you can trust

VEKTOR Slipstream runs entirely local-first. Your memory store lives on your own machine, not in someone else's cloud, and nothing about how it works requires sending or storing your history somewhere else to be useful. That architectural choice was never about a feature checklist. It's the starting position you'd expect from a company that treats your memory as genuinely yours, because it is.

Memory Transparency is what that principle looks like once it's actually usable day to day. Every memory VEKTOR holds is visible, searchable, and editable in the same interface you already work in: what kind of memory it is, when it was formed, which conversation it came from, and why the system judged it worth keeping. Nothing sits behind an export button or a support ticket. If something's wrong, you fix it yourself, immediately, the same way you'd correct a typo in your own notes.

That's the whole idea, stated plainly: you shouldn't have to take our word for what your assistant remembers. You should be able to look.
Consolidation: helping you keep what matters, without taking the decision away from you

A real problem with any memory system, human or artificial, is that not everything worth capturing arrives in a clean, tidy form. Often it's a full conversation, a rambling note, one genuinely useful sentence buried in a paragraph you don't need anymore. Up to now the only honest options were to keep the clutter forever or delete it and risk losing the one thing that mattered.

Consolidation is our answer to that, and it's built the way we think AI assistance should work everywhere: it proposes, you decide. Select a memory and VEKTOR asks your language model to distill it down to the durable fact, decision, or preference inside it, nothing more. That proposal appears in the same editable box you'd use to change any memory by hand. Nothing saves automatically. You read it, adjust it if you want, and only your approval makes it real. If there's genuinely nothing worth keeping, the system says so honestly instead of inventing a summary to fill the space.

We built it this way deliberately. An assistant that quietly rewrites your own history without asking isn't earning trust, it's spending it. Supervised refinement, where the human always holds the final decision, is the only version of this feature we were willing to ship.

How it actually works, under the hood

Structured memory and the interface that reads it never leave your machine. The only thing that ever crosses out is the plain text of one memory you've chosen to consolidate, and the only thing that ever comes back in is a proposal, held in the browser, until you decide whether it becomes real.

Every memory in VEKTOR is stored locally in a structured record, not a blob of raw text. Alongside the content itself, each entry carries a kind (a decision, an open thread, an action item, an entity, a stance), a timestamp, a link back to the conversation it came from, and an importance score.

That structure is what makes Memory Transparency a real interface instead of a search box over a text file: filtering by kind, jumping to a session, or spotting a stale entry all rely on that underlying schema existing in the first place. It's also why the panel is fast at scale. Every query runs directly against your local database, indexed and filtered server-side, so browsing thousands of memories stays instant rather than turning into a slow scroll through everything you've ever said.

Consolidation is where a language model gets pulled into that architecture for the first time, and it's worth explaining precisely what role it plays, because the boundary matters. The model never touches your database directly.

When you trigger consolidation, VEKTOR reads the memory's raw content locally, sends only that content to your configured model with a single, narrow instruction, distills this to the durable fact and discards the rest, and receives back a proposed rewrite as plain text.

That proposal is held entirely in memory on the client side until you explicitly approve it. There's no code path where the model's output reaches your stored memory without passing through your own review first. The model is a drafting tool operating on one entry at a time, in a supervised loop; it is never the system of record.

The reliability layer underneath that is what makes the interface trustworthy at the level of individual clicks, not just the architecture as a whole. Every action you take in Transparency, editing a card, running a search, deleting a batch, is tied to that specific request rather than to whatever happens to be on screen.

A search you run gets a sequence number, and only the response matching your most recent request is ever allowed to update the page, so a slower result from a moment ago can never silently overwrite what you're looking at now. A batch delete runs as a single database transaction against the exact set of IDs you selected, so there's no window where a partial failure leaves the list in a state that doesn't match what actually happened underneath it.

Detailed search in the Transparency panelThat same principle, verify before you trust the output, extends to how VEKTOR's agents use tools at all. When Desk calls out to a language model with a set of tools available, it checks that a real, structured tool call actually came back before treating the response as an answer, rather than accepting a model's plain-text description of what it intended to do as if that description were the result.

And when you attach an image or document in Jot, that attachment is now genuinely read by a vision-capable model as part of forming its response, rather than the note being reasoned about in isolation from the material sitting right next to it. Both are small architectural guarantees with the same underlying purpose: what a VEKTOR agent claims to have done should always be something that actually happened, not something it's merely describing.

What shipped alongside it: v1.7.7

Memory Transparency is part of a broader release, v1.7.7, and most of what's in it follows the exact same thread: verify before you trust and never let a system quietly claim something happened that didn't.

Gui UX design improvements Sentinel - proactive recall, held to the same bar as everything else

Up to now, VEKTOR's recall has been entirely pull-based: you ask, it retrieves. Sentinel adds a proactive layer on top of that, wired into both Desk and Jot on each turn; before the model responds, it checks whether a stored memory is relevant enough to surface unprompted, without you having to ask for it. It's a live task-completion aid, and it's deliberately excluded from affecting our published benchmark numbers, since those measure pull-based recall specifically.

We didn't ship the proactive part without the same verification discipline as the rest of the product. Sentinel re-checks a candidate memory directly against the database right before injecting it, rather than trusting a possibly-stale result from earlier in the turn, it follows the supersession chain forward to whatever is currently the active version of a fact, and refuses to surface anything that has since expired.

An opt-in self-questioning pass adds one extra model call that judges whether a specific memory is genuinely useful for the specific thing you're doing right now, rather than noise. And because a static relevance threshold is never going to be right for everyone, per-agent thresholds calibrate over time from real accept/reject feedback rather than staying fixed at a default.

Improving supersession reranking

VEKTOR has had the scaffolding for supersession, marking an old fact as replaced when a newer one contradicts it, fully built for a while: the schema, the dedup logic, an LLM-verified gate meant to confirm the replacement is actually correct before committing it.

The root cause was subtle in the way these things usually are: three separate reranking stages in the recall pipeline each independently overwrite a memory's similarity score with a different, less comparable number, before the supersession check ever gets to look at it.
By the time the gate asked, "Is this new fact similar enough to the old one to be a replacement?" the number it was looking at wasn't really a similarity score anymore. We refined it by capturing the true similarity at the exact point it's computed and carrying that specific value through every later stage untouched, rather than letting anything downstream silently redefine what "similar" means.

Faraday - an independent witness, not just a gate

Faraday, VEKTOR's security layer, gained two additions built around the same idea as everything above: don't just claim something is protected, be able to prove it from outside the thing you're protecting.
A new independent watchdog process now runs continuously via the OS's own task scheduler, separate from any active AI session. It watches the MCP configuration files of seven different AI-assistant clients, plus Faraday's own core enforcement files, closing the specific gap where a tampered gate or an injected rogue server entry could previously go unnoticed simply because nothing was watching while no session was open.

Alongside it, every security event Faraday logs now carries a cryptographic link to the event before it, the same principle git uses for commit history. Altering, deleting, or reordering a past entry breaks every link after it, detectably. It doesn't make the log unforgeable against an attacker with unlimited time and full database access, and we're not going to claim otherwise, but it does mean routine tampering or accidental corruption shows up immediately instead of sitting silently in a history nobody double-checks.

Model catalog refresh

In this release: Gemini is now on Gemini 3.5 Flash, xAI is on Grok 4.5, and three new OpenAI options - Luna, Terra, and Sol - are live. That brings VEKTOR's total supported provider count to sixteen, spanning frontier, mid, and free/local tiers, so whichever model you'd rather run consolidation, Desk, or Jot through, it's almost certainly already supported.

Grok 4.5 live in config panelTransparency isn't just the memory panel
The same standard we're describing for your memory, don't ask people to take your word for it, show them, applies to how we talk about the product itself, and to how the site around it handles your data. We spent time this cycle making sure both actually hold up.

On the numbers: we corrected our published recall latency figure. It had been stated as roughly 8 milliseconds, which was true for our earlier hash-projection fallback embedder but not for the real transformer-based embeddings that now ship by default.

The accurate figure for real embeddings is roughly 28 milliseconds warm, and if you enable optional cross-encoder reranking for higher-precision recall, that adds a further ~215–220ms on top, which we now disclose rather than quoting only the best case. Every latency and speed-multiple claim across the site and documentation was swept and corrected to match, not just the headline numbers.

On the site itself: we found and closed a real gap between what our privacy policy claimed and what was actually running. Cloudflare and Umami analytics are cookieless and non-identifying by design; Microsoft Clarity is not, it sets several persistent, cross-site cookies. We are not the biggest fans of cookies, but we also believe in transparency.
We rebuilt this as a consent-gated system: cookieless analytics run by default, Clarity is opt-in only, and the site's privacy policy now categorizes exactly what each tool does and doesn't do, rather than a single blanket "we don't track you" statement that wasn't fully accurate.

Held to the same standard we'd want applied to anything holding our own data

We don't think trust is something you can claim in a paragraph like this one. It's something you have to actually build in the behind-the-scenes work nobody sees unless they go looking for it.

So before any of this shipped, we tested it the way you'd want something touching your personal history tested: with real, automated interaction against real data, not a read-through of the code and a hope.

Editing one memory has to only ever touch that one memory. A search has to return what you searched for, not a stale result racing back into view. A batch delete has to remove exactly what you selected, nothing more, nothing less. Those checks now run as repeatable tests, not a one-time glance before release, alongside a new pre-release gate that runs the same core memory loop, CLI boot, provider registration, and MCP server checks before anything gets packaged for release at all.

*That same discipline runs through the rest of the product too. *

Desk, VEKTOR's conversational agent, now verifies a model genuinely used a tool before treating its response as real, rather than accepting a model simply describing what it might do as if that were an answer, especially important once you're relying on smaller or free-tier models that don't always follow instructions as precisely as you'd hope.
Jot, the writing and research panel, now properly grounds its analysis in whatever image or document you've actually attached, instead of reasoning about your note as if that material wasn't sitting right there.

Why this matters, especially now

Memory is quickly becoming the part of AI that everything else depends on, and that raises the stakes on getting it right. A system that can't show you what it holds, can't let you fix it, and can't be honest about the difference between a real action and a model just talking about one, isn't a system built with your interests as the priority.

We built VEKTOR around a simpler belief: privacy-enhanced technology and usefulness are never in friction, and a company you can trust with your memory is one that lets you watch it work, keeps that work local by design, and never asks you to just take its word for it.

Memory Transparency, and everything that shipped alongside it in v1.7.7, is that belief made into something you can trust and utilise.

VEKTOR Memory builds local-first, privacy-preserving persistent memory infrastructure for AI agents. Your data stays on your machine, by design, not by policy. Full technical documentation at vektormemory.com.