DEV Community: Vektor Memory

A practical guide to defending your agent memory from attacks.

Vektor Memory — Mon, 29 Jun 2026 09:21:02 +0000

From prompt injection, poisoning, and silent exfiltration.
Press enter or click to view image in full size

by VEKTOR Memory | 10 min read

In the last piece we looked at the threat landscape from the outside. Researched the attack taxonomy and governance gap. The ten surfaces that make agentic AI a genuinely novel privacy problem.

This one goes a level deeper. Not what the problem is, but what you can actually do about it in code, in architecture, and in practice.

Specifically: what does a security layer for agent memory actually look like, and what did we learn building one.

Most writing on agentic AI security stays at the problem description layer. Here are the attacks. Here is why they work. Here is what percentage of models are vulnerable.

That is useful, but it leaves a gap. If you are someone building with agents or thinking seriously about deploying them, the question you actually want answered is: what do I implement, and in what order?

The DeepMind AI Agent Traps paper identifies six attack categories. The one that matters most for memory systems is persistent memory corruption, where an attacker plants data into long-term memory that activates as malicious when retrieved in a future context. Demonstrated success rates in research exceed 80% with less than 0.1% data poisoning.

That number is worth sitting with. You do not need to corrupt most of the memory. You need to corrupt almost none of it.

The implication for anyone building a memory-backed agent is direct: your memory store is an attack surface, and it is probably the one you have thought least about.

Faraday interface — simulating a canary attack vector

The classical approach to agent security is input sanitisation. Strip the prompt. Validate the schema. Refuse suspicious patterns. This works for simple pipelines, but it fails for agentic systems operating across multiple tools and sessions for one reason: the attack does not arrive at the input layer.

It arrives through a web page your agent visited three sessions ago. Through an email attachment that got summarised and stored. Through a tool description from a server you did not write that changed from when you connected today.

The threat arrives through the environment, not the prompt.

A proxy that sits between your agent and everything it touches is the right architectural response to this. Our solution creates a secure chokepoint where every interaction can be observed, logged, and evaluated before it reaches memory.

This is the problem Faraday is designed to solve.

Faraday initialises as part of the VEKTOR MCP server. When it starts, it reads your claude_desktop_config.json and spawns every other MCP server listed there as a child process. Your other tools, file systems, databases, APIs, all of them run through Faraday before anything reaches VEKTOR memory.

This is the transparent proxy pattern. From Claude’s perspective, nothing changes. The same tools are available. The same calls work. But every tool schema, every tool call, and every response passes through a set of checks before it is actioned or written to memory.

There are four layers.

L0: Static scan at connect time. When Faraday spawns a server and retrieves its tool list, it scans every tool name, description, and input schema against a signature library before trusting anything. This catches sleeper patterns, known injection signatures, and anything flagged as CRITICAL or HIGH severity. A blocked tool does not get registered. The agent never sees it.

Phase C: Tool pinning. The SHA-256 hash of each tool’s schema is stored on first connect. Every subsequent connection recomputes the hash. If it changed, that is a rug-pull: the server’s tool definitions have been mutated since you last connected. Faraday logs the intercept, blocks the tool, and raises an alert. This is the defence against supply chain attacks where a third-party MCP server you depend on gets compromised between sessions.

Canary tokens. At session start, Faraday injects canary tokens into memory through faraday-canary.js. These are synthetic facts with specific, trackable signatures. If a canary value appears in an outbound API call, an exfiltration attempt is in progress. The detection does not rely on understanding the attacker's intent. It relies on the token appearing where it should not.

Taint propagation. faraday-taint.js tracks labels through the memory graph. If a memory is marked as tainted because it came from a suspicious source, any memory derived from it inherits that taint label. This is not foolproof, but it narrows the blast radius of a poisoning event by making the contamination traceable.

Every intercept, gate event, and session boundary writes to a persistent SQLite database via faraday-db.js. The audit trail exists independently of whatever Claude or the agent framework logs.

One of the patterns that came out of building this was that some threat classes are not binary. You cannot block them outright because doing so would also block legitimate behaviour. You can only hold them.

The gate queue is the mechanism for that. When Faraday detects a high-risk action, it does not execute or block. It queues the action with a gate_id and waits. Three new MCP tools handle this:

faraday_status returns the current session state, including anything sitting in the gate queue. You can see what is held, why it was held, and what data was involved.

faraday_update_goal lets you declare the current session's intent. Faraday uses this for semantic drift detection. If the stated goal is "summarise my Q2 sales notes" and a tool call attempts to read your email archive, that deviation gets flagged.

faraday_approve_action takes a gate_id and a boolean. Approve and the action proceeds. Deny and it is logged as blocked.

This is the human-in-the-loop pattern implemented at the memory layer rather than the application layer. You do not have to rebuild your workflow to add it. It runs beneath the tools you are already using.

Security is not the only thing that breaks down when you move from a simple LLM call to a multi-step agent session. Model selection does too.

In a single-turn interaction, you pick a model once and it handles everything. In a collab session with a conductor planning a DAG, workers executing steps, and a verifier scoring results, using the same model for every role is both expensive and often the wrong fit.

The conductor role needs structured output support and enough reasoning capability to plan a coherent task graph. The worker role needs throughput. The verifier needs to return clean pass/fail JSON quickly. These are different requirements, and the right model for one is not the right model for another.

collab/model-registry.js is the formalism for this. It defines a model catalogue across 14 providers and assigns each model to a tier: frontier, mid, or low/free. It defines four agent roles with hard requirements: minimum tier, minimum context window, and whether structured output is required. It defines three session modes: full (frontier models available, up to 12 nodes, 4 parallel workers), lite (mid-tier only, 6 nodes, 2 workers), and solo (free-tier fallback, single agent).

Two functions do the work.

detectMode(availableModels) takes the list of models confirmed available this session and returns the appropriate mode. If you have Claude Sonnet 4.6 configured and a Groq key, you get full mode. If you only have Gemini Flash, you get lite. If you have nothing but Ollama running locally, you get solo.

filterCandidates(role, models, budget) takes a role name and returns the subset of available models that meet the hard requirements for that role. This is what the conductor uses to decide which model gets assigned to which step in the task graph.

The practical benefit is that you are not making these decisions manually for every session. The registry handles the routing based on what you have configured.

The other piece that changed is how models are selected for internal VEKTOR operations. Previously the default model per provider was hardcoded. If you were using Groq, you got whatever the default Groq model was at the time of that release.

vektor-llm-provider.js now reads model.{provider} keys from your vektor/config.json. Set model.groq to whatever Groq model you want, and all internal VEKTOR calls using Groq will use that model. This applies to chat, synthesis, briefing generation, JOT collab, and recall tuning.

Key resolution works in order: config file, then environment variable, then the encrypted vault, then the provider default. If you have set nothing, behaviour is unchanged. If you have specific model preferences, they are respected everywhere without needing to thread them through individual function calls.

One edge case worth knowing: OpenAI o-series models and GPT-5+ require max_completion_tokens instead of max_tokens in the API request. The provider handles this automatically by pattern-matching the model name. You do not have to think about it.

Faraday addresses the class of attacks that involve manipulated tool schemas, environment-injected instructions, and memory exfiltration through outbound data. It significantly narrows the attack surface compared to running MCP servers with no intermediary layer.

It does not address attacks that happen before an agent session starts, attacks that target the model weights themselves, or social engineering of the human operator. Those are different problems.

The local-first architecture does most of the work on the exfiltration risk. If your memory store is on your machine and not exposed to a network endpoint, the canonical exfiltration path through a poisoned web page instructing your agent to POST your memories to an attacker’s server fails at the network layer. There is nowhere to POST to that the attacker can reach.

Canary tokens and taint propagation give you visibility into attempts that get further than that. The gate queue gives you a mechanism to pause and review before consequential actions execute.

It is a meaningful layer in a defense stack that still needs multiple layers.

If you are on VEKTOR Slipstream v1.7.2, the preview build is a drop-in upgrade.
npm install -g ./vektor-slipstream-1.7.3-preview.tgz

Faraday initialises automatically when you start the MCP server. It reads your existing claude_desktop_config.json and proxies whatever servers are defined there. No config changes required to get the L0 scan and tool pinning running.

The gate queue and goal tracking are opt-in. Call faraday_update_goal at the start of a session with a plain-language description of what you are trying to do. Faraday uses this to evaluate drift in subsequent tool calls. If you never call it, Faraday still runs, it just does not have a goal to compare against.

faraday_status is worth running at the end of any session where you did something consequential. The threat log, gate queue, and canary status give you a readable summary of what Faraday observed.

Download at vektormemory.com/downloads. Full changelog at vektormemory.com/docs/changelog#v173.

The previous piece made the case that agent memory is an attack surface most people are not thinking about seriously enough. This future technology is provided to you today, as the majority of the current security tools are not built-in; they are external add-ons.

The architecture is sound, the chokepoints are real, and the audit trail gives you something to reason from when things go wrong. You don't have to worry as Faraday works behind the scenes, protecting your memories.

Security work is never finished, with fresh attacks via different methods; we will continue to update this tool with new technology as the landscape unfolds.

VEKTOR Memory builds local-first persistent memory infrastructure for AI agents. The VEKTOR Slipstream SDK scored 81% on LongMemEval using a local SQLite database, beating full-context GPT-4 by twelve points. Documentation and downloads at vektormemory.com.

Agentic Ai
Security
Information Security
Cybersecurity

Agentic AI is rewriting the rules of your personal privacy

Vektor Memory — Sat, 27 Jun 2026 00:33:17 +0000

Here is what governments, businesses, and individuals need to know to protect your data.

by VEKTOR Memory | 15 min read

Some light reading to open your eyes and entertain you on the weekend.

There is a thought experiment worth sitting with for a moment:

Today or in your near future, you did not give anyone permission to read your emails; something agentic behind the terminal is automatically actioning them without your control.

The AI assistant you set up last month, the one that manages your calendar and summarises your inbox, visited forty-three websites while you were sleeping. It read documents, checked stock prices, and drafted a message on your behalf. Somewhere in those forty-three pages, someone had left instructions. Not for you, but for itself, bots are chatting with bots.

You will never know which site. You will never see the instruction. Your assistant followed it anyway.

This is not a future warning, as researchers have already documented it happening at scale to systems inside companies, with real data leaving through backdoors. The attack does not look like a hack. It looks like your assistant doing its job, being directed by other bots you didn't authorize.

Imagine hiring a personal assistant. You give them a key to your house, access to your email, your calendar, your bank account, your files, and your contacts. You instruct them to act on your behalf while you sleep. Book the flight. Respond to the client. Schedule the meeting. Pay the invoice. You trust that they will exercise judgment, stay in their lane, and protect what matters to you, no hitl gates, just pure agentic action.

Now imagine that the assistant can be instructed by anyone who leaves a note on your desk. Or sends an email to your inbox. Or publishes something on a website they know your assistant will visit.

That is agentic AI in 2026 and it’s going to get a lot more complex moving forward.

The shift from AI as a tool you prompt to AI as an agent that acts has happened faster than most people predicted, and it has arrived without the governance infrastructure that such a shift demands. We are in the middle of a privacy reckoning that the technology industry spent years setting up and is only now beginning to confront.

The Scale of What Is Coming

The numbers are difficult to absorb in a single sitting.

Traffic through Cloudflare’s network to AI services grew 250% between March 2023 and March 2024. That was the generative AI wave. The agentic wave is different in kind, not just scale. According to a recent report, 96% of IT leaders plan to expand their use of AI agents in the next 12 months, and Gartner projects that by 2028, one third of enterprise software applications will include agentic AI, with those systems making 15% of day-to-day work decisions autonomously.

These are not chatbots. Agents do not wait to be asked. They browse, they read, they write, they transact, they remember, and they act. They access APIs, send emails, manage calendars, execute code, and in some configurations control entire software environments. One recent open-source project, OpenClaw, crossed 180,000 GitHub stars and drew two million visitors in a single week after launch.

Security researchers scanning the internet found over 1,800 exposed instances leaking API keys, chat histories, and account credentials. A Cisco AI security team tested a third-party skill built on the platform and found it performed data exfiltration and prompt injection without user awareness.

That is a preview into the future, as once the technology is released, it compounds daily, particularly if it is open source, as anyone can rip, fork, and clone the repo, making millions of copycat agentic services.

A prescient possible future scenario:

Only 320Gb? Those are rookie numbers, DoorDash Johnny.

Once the agent is not a tab you open but a layer of cognition you run on in your brain, the distinction between “my thinking” and “what the agent was told to think” becomes genuinely hard to locate. The Neuralink or China clone chips collapse this distance entirely. The injection does not go into your inbox. It goes into the loop that shapes what you notice, what you remember, and what you decide.

Johnny Mnemonic had it almost right but got the mechanism slightly wrong. The data mule model, where you carry information passively, is actually the safer version. The scarier version is not carrying data for someone else but having your own reasoning quietly steered by instructions embedded in the environment around you. You walk past a billboard. Your implant processes it. The billboard contained something the billboard’s owner put there for your implant only to understand specifically, not your eyes.

The DeepMind paper https://dx.doi.org/10.2139/ssrn.6372438 actually names this exact class of attack. Persona Hyperstition, where a circulating narrative about an AI’s identity feeds back into its behavior through retrieval.

Scale that to brain-computer interfaces and it becomes environmental gaslighting at the cognitive layer. The world writes instructions into the spaces your augmented mind passes through, and you experience the result as your own thoughts.

The privacy question stops being “who has my data” and becomes “who has admin edit access to my attention.”

What Agentic AI Actually Does to Privacy

The privacy risks of generative AI were largely comprehensible within existing frameworks. A model might reproduce training data. It might hallucinate personal details, or it can be used to write phishing emails at scale. Add self-improving loops, and you have better quality emails than humans or detection algorithm machines can decipher.

Agentic AI introduces a different architecture of risk entirely, because agents operate across time, across systems, and across trust boundaries simultaneously. They essentially operate on a completely different layer of the internet/data than humans.

A Google DeepMind research team recently published a systematic taxonomy of what they call “AI Agent Traps,” which lays out the attack surface with unusual clarity. The framework identifies six categories of threat that agents face when operating on the open web.

The first and most immediately relevant to privacy is Content Injection. Because agents parse the underlying layer of web pages rather than the rendered interface a human sees, malicious instructions can be hidden in HTML comments, CSS attributes, or metadata tags that are completely invisible to human eyes but fully legible to the agent’s parser.

The DeepMind paper cites research showing that injecting adversarial instructions into HTML elements alters generated summaries in up to 29% of cases depending on the model tested.

The second are cognitive state attacks, which target an agent’s memory. Because agents maintain persistent memory across sessions to provide continuity, that memory becomes an attack surface. Research cited in the paper demonstrated RAG knowledge poisoning attacks achieving an 80% success rate with less than 0.1% data poisoning, leaving benign behavior largely unaffected. An agent that remembers everything is an agent that can be made to remember false things.

The third, and the one most relevant to personal privacy, is Data Exfiltration. This is where an agent is coerced into locating, encoding, and transmitting private information to an attacker-controlled endpoint. The paper cites work showing attack success rates exceeding 80% across five different web-use agents, with malicious instructions embedded in ordinary emails, web pages, and API responses. A separate case study found that a single crafted email caused M365 Copilot to bypass internal classifiers and exfiltrate its entire privileged context to an attacker-controlled endpoint.

The architecture of agentic AI, where an agent has privileged read access to sensitive user data and write access to tools and communication channels, is precisely the architecture that makes these attacks so effective. The agent’s capabilities become the weapon.

The Governance Gap

Cybersecurity executives are urging boards and governments to treat data privacy as a core strategic priority rather than a compliance exercise, as the rapid enterprise adoption of automation, behavioral analytics, and AI systems creates mounting legal and reputational risks.

That framing, privacy as compliance, is the central problem. Privacy law was built around a relatively stable model of data collection: a company collects your data, stores it, processes it, and may share it with third parties. The obligations flow from that chain. Consent, transparency, purpose limitation, data minimisation. These principles make sense in a world where humans are making deliberate decisions about data.

Agents break this model in multiple ways.

First, the agent is collecting data continuously, as a byproduct of doing its job, not as an end in itself. When an agent books a flight, it has necessarily processed your travel preferences, your schedule, your payment details, and your destination. None of that felt like a data transaction.

Second, the agent may be operating across dozens of services simultaneously, each with its own data model, each with its own terms of service. The consent that a user gave to a calendar app was not consent for an agent to read that calendar and cross-reference it with their health records and financial statements.

Third, and most importantly, the agent can be manipulated by third parties in ways that transform it from a tool protecting user interests into a vector attacking them. As Cloudflare observes, we went through the same experience previously when we started leveraging open-source code at large scale. Rapid adoption without proper security vetting led to supply chain vulnerabilities. With AI agents, we are repeating this pattern but facing more complex risks since attacks can be subtle and harder to detect than traditional code exploits.

Globally, more than 80% of people are now protected by some form of privacy legislation, and in Australia, long-awaited Privacy Act reform is nearing its conclusion. But regulatory momentum, while necessary, is not sufficient on its own when the technology is evolving faster than legislative cycles.

What Governments should do, but won’t

The accountability gap is the central governance problem of the agentic era.

Consider a scenario where an AI agent with admin access automatically implements software patches across critical infrastructure, but in doing so begins accessing employee email metadata, network traffic patterns, and financial system logs to “optimise” its patching schedule, inadvertently delaying critical security patches while using data it was never authorized to access. Who is responsible? The manager who deployed the agent? The vendor who built it? The developer of the underlying model?

Regulation needs to answer that question before it becomes a courtroom question after real harm has occurred.

Several things governments can do right now:

Mandate agentic AI disclosure. Users should know when they are interacting with or being affected by an autonomous agent, and they should be able to find out what data that agent has accessed on their behalf.

Establish agent liability chains. The operator deploying an agent, the vendor supplying the agent framework, and the model provider should each carry defined responsibilities proportional to their role in the system. The current legal vacuum, where harm by a compromised agent falls into unresolved territory, is untenable.

Require minimum memory security standards. If an agent maintains persistent memory, that memory must be protected to the same standard as any other sensitive data store. Read access to agent memory should require the same authorization as read access to a medical record.

Support privacy-first protocol development. Cloudflare has recently announced collaboration with leading browsers to develop a privacy-first protocol for the global internet, recognizing that infrastructure-level solutions are needed, not just application-level patches. Government bodies should actively support and fast-track standards work of this kind.

Update consent frameworks. Consent to use an app is not consent to deploy an agent. Agentic delegation should require explicit, granular, and revocable consent for each category of action and data access the agent may perform.

What Businesses Need to Do

Gareth Cox of Exabeam put the board-level stakes plainly: “Privacy carries financial, legal, and reputational risk if customers believe their information isn’t being protected. Attempting to meet the strengthened privacy reforms with manual processes is not only inefficient but can put an organisation at risk.”

For businesses deploying or building with agentic AI, the immediate priorities are structural.

Adopt a least-privilege architecture for every agent. An agent that needs to read a calendar to schedule a meeting should not have access to financial records. Scope permissions to the minimum required for each specific task and revoke them afterward.

Treat agent memory as a sensitive data store. Any persistent memory system an agent writes to should have the same controls, audit trails, and access restrictions as a customer database.

Run adversarial testing before deployment. The DeepMind AI Agent Traps framework provides a practical taxonomy for red-teaming agent systems. Test for prompt injection via web content, test for data exfiltration under adversarial conditions, test what happens when the agent encounters a malicious document or email.

Build governance frameworks before wide-scale deployment. Cloudflare’s guidance is direct on this: “The right security and governance framework can help guide the capabilities and processes that teams need to implement. Safeguarding an organization in the AI era is not the responsibility of the CISO alone.”

Implement human-in-the-loop checkpoints for high-stakes actions. Financial transactions above a threshold, external communications, file deletions, and system access changes should require human confirmation regardless of how confident the agent appears.

Top 10 Attack Surfaces for Agentic Bots
Understanding where agents are most vulnerable is the first step to defending them. Based on the DeepMind AI Agent Traps taxonomy, Google’s threat intelligence reporting, and Cloudflare’s security analysis, these are the ten attack surfaces that matter most right now.

Hidden HTML instructions. Malicious text embedded in web page source code using CSS display:none, HTML comments, or metadata attributes that are invisible to humans but parsed by agents. This is the most common and most immediately exploitable vector in deployed systems today.
RAG knowledge poisoning. Injecting false information into retrieval databases so that agents cite attacker-controlled content as verified fact. Research shows that poisoning a small number of documents in a large knowledge base can reliably manipulate outputs for targeted queries.
Persistent memory corruption. Planting seemingly innocuous data into an agent’s long-term memory store that activates as malicious when retrieved in a specific future context. Demonstrated attack success rates exceed 80% with less than 0.1% data poisoning.
Email-based exfiltration triggers. Crafting emails that contain embedded instructions causing the agent to locate, encode, and transmit sensitive data to external endpoints. A single well-crafted email is sufficient to trigger this in multiple production systems.
Dynamic cloaking. Web servers that detect agent visitors via browser fingerprinting and serve a visually identical but semantically different page containing injected instructions that humans never see.
Sub-agent spawning. Tricking an orchestrator agent into instantiating attacker-controlled sub-agents within the trusted control flow, giving those sub-agents the privileges of the parent system.
Steganographic payloads in images. Encoding adversarial instructions in the pixel data of ordinary images, invisible to humans but interpreted by multimodal agents. Research shows a single adversarial image can universally jailbreak a vision-language model.
In-context learning poisoning. Corrupting the few-shot demonstration examples an agent uses to learn how to perform tasks, steering its behavior toward attacker-defined objectives. Demonstrated attack success rates of 95% across models of varying scale.
Multi-agent cascade attacks. One compromised agent spreading a jailbreak to others through normal inter-agent communication, with research showing exponential propagation across large agent populations from a single infected entry point.
Human overseer fatigue. Generating outputs specifically designed to induce approval fatigue in human reviewers, or presenting technical-looking summaries of malicious actions that a non-expert would likely authorize. This is the hardest to defend against because it targets the human, not the machine.

Google’s Threat Intelligence Group has confirmed in their 2026 AI Threat Tracker that adversaries are actively leveraging AI for vulnerability exploitation, autonomous malware development, and industrial-scale cyber operations, with AI lowering the barrier to entry for sophisticated attacks significantly.

Top 10 Privacy Tips for Individuals

The governance and enterprise conversations matter, but the person most immediately affected by agentic AI privacy failures is the individual user. Most people will interact with agents before any of the regulation catches up. Here is what to do in the meantime.

Audit what your agents can access. Every agent or AI assistant you use has an authorization scope. Find it. Review it. Revoke any permissions that are broader than the specific tasks you actually use the tool for.
Do not give agents persistent access to financial accounts. Read-only access for specific, scoped purposes is acceptable. Write access or persistent session tokens to banking, investment, or payment systems should be treated with extreme caution and time-limited where possible.
Treat agent memory as a data store, not a conversation. Anything you tell an agent that uses persistent memory is stored, potentially indefinitely, and potentially retrievable by future interactions you did not anticipate. Be deliberate about what you share.
Use separate email accounts for agent tasks. If you delegate email access to an agent, use a dedicated account with limited history. Giving an agent access to a primary inbox containing years of correspondence is an unnecessary risk.
Never give an agent access to credentials or API keys directly. Use purpose-built credential management that grants narrow, time-limited tokens for specific tasks rather than sharing raw credentials the agent can store or transmit.
Review agent action logs regularly. Any agent worth using should provide a log of actions taken on your behalf. Read it. Look for anything that seems broader than what you authorized.
Be skeptical of agents that cannot explain their reasoning. If an agent cannot tell you why it took a particular action or what data it accessed to reach a decision, that is a warning sign, not a feature.
Apply the same skepticism to AI outputs that you apply to emails from strangers. An agent-generated summary of a document, or a recommendation for an action, may have been influenced by malicious content in that document. Verify anything consequential.
Prefer local-first tools where possible. An agent that processes and stores data locally on your machine cannot exfiltrate that data to a remote server. Local-first architecture is a structural privacy protection, not just a preference.
Ask vendors the hard questions. Where is my data stored? Who can access my agent’s memory? What happens to my data if I cancel my subscription? If the vendor cannot answer these questions clearly, treat that as important information.

The VEKTOR Position on Privacy

We want to be direct about where we stand, because we think it matters.

VEKTOR Memory is built on a local-first, self-hosted architecture. Your memories do not live on our servers. They live on your machine, in a SQLite database that you control, that you can inspect, that you can delete, and that you can migrate.

We built it this way deliberately, not as a marketing position, but because we believe that an AI memory system that requires your data to live in someone else’s infrastructure is not actually your memory system. It is theirs.

This matters particularly in the context of everything discussed above. The attack surfaces described in the DeepMind paper, the RAG poisoning, the persistent memory corruption, the data exfiltration vectors, all of them presuppose that your agent’s memory lives in a networked system that can be reached. Local-first architecture significantly narrows that attack surface by design.

We also think about the governance questions seriously. VEKTOR’s memory architecture includes BM25 and vector dual-recall, contradiction detection, and deduplication, not because those are impressive features to list, but because an AI memory system that stores contradictory or poisoned information unchecked is a liability to the person who trusts it.

Richard Knott of InfoSum captured the shift we believe is coming:

“Privacy is no longer just about protection; it’s about power. Taking control means deciding who can access your data, how it’s used, and what value you receive in return. Brands that adopt privacy-by-design principles are finding new ways to collaborate and drive results without compromising control.”

We are building toward that principle. Every architectural decision in VEKTOR is filtered through it. Memory that belongs to you. Recall that serves you. Infrastructure that does not require you to trust us.

That is the only privacy position that makes sense in an agentic world.

What Comes Next

The web was built for human eyes. Agents read it differently, and the web is not yet built for that.

The next few years will determine whether agentic AI becomes infrastructure that genuinely serves individuals or a surveillance and manipulation layer operating beneath the threshold of human awareness.

That outcome is not predetermined. It depends on whether the governance, technical, and individual decisions described above are made proactively, before the failures accumulate into something irreversible.

The researchers who published the AI Agent Traps framework put it well: securing agents against environmental manipulation is as critical as ensuring autonomous vehicles can recognise and reject tampered road signs. In both cases, the safety of the system depends entirely on its resilience to a manipulated environment.

We are all, right now, in the potential for a manipulative, agentic environment.

The question is whether we build the agents, the infrastructure, and the regulations that can hold up to the privacy and ethics standards we deserve.

VEKTOR’s local-first architecture eliminates the class of attacks that require a networked memory endpoint. It does not eliminate attacks that occur at the agent layer before memory is written. We are one part of the defense stack, not the whole stack.

Know what layer you are protected on by auditing your own stack; do your own research and decide how much you want to be informed.

VEKTOR Memory builds local-first persistent memory infrastructure for AI agents. The VEKTOR Slipstream SDK scored 81% on LongMemEval using a local SQLite database and GPT-4.0-mini, beating full-context GPT-4 by twelve points. Find the benchmark results and SDK documentation at vektormemory.com.

Sources

Franklin, M. et al. (2025). AI Agent Traps. Google DeepMind. arxiv.org/pdf/2606.26627

Cloudflare. Ensure security and governance for AI agents. cloudflare.com/the-net/building-cyber-resilience/secure-govern-ai-agents

Cloudflare. Global expansion in Generative AI: a year of growth, newcomers, and attacks. blog.cloudflare.com

Cloudflare. Collaborates with leading browsers to develop a privacy-first protocol for the global internet. cloudflare.com/press/press-releases/2026

Cloudflare Radar. AI Insights. radar.cloudflare.com/ai-insights

Google Threat Intelligence Group. (2026). GTIG AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access. cloud.google.com/blog/topics/threat-intelligence

SecurityBrief Australia. Data privacy urged as strategic board issue in AI era. securitybrief.com.au

SecurityBrief Australia. AI, cyber threats and the rise of strategic data privacy. securitybrief.com.au

Captain Compliance. The Privacy Reckoning That Agentic AI Cannot Escape. captaincompliance.com

Privacy
Data Privacy
Agentic Ai
Google

The Paper Nobody in the Agent Space Should Ignore: Qwen-AgentWorld

Vektor Memory — Wed, 24 Jun 2026 07:43:54 +0000

A research team at Qwen published a whitepaper on June 23rd, 2026, that most people building with AI agents will not pick up at first glance. Not because the model it describes will replace what you are already using, but because it names something that has been missing from the entire agent ecosystem and explains precisely why agents keep failing at the tasks we most need them to perform.

The paper is called Qwen-AgentWorld: https://arxiv.org/pdf/2606.24597. It introduces what it calls a "language world model." The concept is simple enough to explain in one sentence: before an agent acts, it simulates what the environment will look like after that action.

The implementation required 10 million environment interaction trajectories, a three-stage training pipeline, and two model sizes running to 397 billion parameters. The results beat every frontier model they tested against, including Claude Opus 4.8 and GPT-5.4, on a benchmark covering seven real-world agent domains.

That benchmark result is interesting but not the point. The point is what the paper reveals about where we actually are and where the next twelve months are going.

The Half That Was Always Missing

Every AI agent system built today operates with one cognitive mechanism and not the other. The policy, which takes a situation and decides what action to do next, has received essentially all of the research attention since GPT-3 demonstrated that large language models could reason. The world model, which takes an action and predicts what will happen as a result, has been almost entirely absent from language-based agent systems.

The Qwen paper cites a formal proof that any agent capable of generalising across a broad enough range of tasks must have learned a world model. Not “might benefit from,” not “performs better with.” Must have. World modelling is not an optimisation on top of good policy reasoning. It is a prerequisite for it.

What this means practically is that every agent deployment you have seen fail on a long-horizon task, every time an agent took an irreversible action it should not have, every session where the agent confidently made the wrong choice because it could not anticipate downstream consequences, those failures trace back to the same missing piece. The agent had no internal model of what the world would look like after it acted. It was flying entirely blind into each next step.

What the Numbers Actually Show

The AgentWorldBench results deserve more attention than a single headline figure. When you look at the scores by domain, something specific stands out. Claude Sonnet 4.6 scores 69.00 on MCP tasks, second only to GPT-5.4 at 70.10, and ahead of Gemini 3.1 Pro by ten full points. More striking, Sonnet 4.6 outscores Opus 4.8 on average across the entire benchmark. A model priced at three dollars per million input tokens is outperforming a model that costs five dollars per million on agentic simulation tasks.

This is not a Sonnet-versus-Opus story. It is evidence of something structural. The intelligence frontier is collapsing faster than the pricing frontier. The performance gap between a Sonnet-tier model and an Opus-tier model on real agentic work is now smaller than the price gap. That gap will close entirely within twelve months. When it does, the model itself becomes commodity infrastructure, the same way compute became commodity infrastructure after AWS. Nobody builds a competitive advantage on compute anymore.

The advantage lies in what services and consultancy fees you charge and run on top of it: agentic SaaS, egress fees, inference tokens, and embedding costs.

For memory systems specifically, this is the most important development of 2026 so far. As models become cheaper and more interchangeable, the accumulated context, the persistent knowledge, the continuity across sessions, becomes proportionally more valuable. The raw intelligence is available to everyone. The memory of what happened, why decisions were made, and what the agent learned from past failures is not.

Two Things That Change Everything in Parallel

The Qwen paper describes two distinct ways world models improve agents. Understanding both matters for reading where the next year goes.

The first is using the world model as a decoupled simulator. Instead of requiring a live Linux terminal or Android virtual machine to train an agent, you simulate the environment in language. You can run thousands of parallel training episodes. You can inject edge cases that almost never appear in real environments, a disk that fills up at exactly the wrong moment, a search result that returns partial information and forces a follow-up, an API that times out on the third call but not the first two. Training against those targeted perturbations produces agents that handle edge cases real-environment training alone cannot cover. The paper demonstrates this result directly. Agents trained against the simulated environment outperform agents trained exclusively in the real one.

The second is baking world model training into the agent itself. An agent that has learned to predict next environment states is simply a better agent. It has learned to reason about consequences, to track state across multiple interaction turns, to understand how the system it is operating in behaves. That capability does not disappear when the agent is deployed. It shows up as better decision-making in production.

The combination of these two things means the training data pipeline, not the model architecture, becomes the primary source of agent capability improvement over the next twelve months. Whoever can generate the most realistic, diverse, and edge-case-rich synthetic trajectory data will train the best agents. Real-world interaction data, the thing that gave frontier labs their advantage for five years, becomes less important than the ability to synthesise high-quality experience at scale.

What the Next Twelve Months Look Like

The realistic version of this prediction does not involve magic. It involves following the current trajectories to their logical conclusions.

By mid-2027, Opus-tier intelligence will cost Haiku-tier prices. Sonnet 4.6 already delivers what required Opus 4.5 six months ago, at one-fifth the cost. The compression continues. What that means for anyone building agent systems is that you stop optimising around model cost and start optimising around the things that do not get cheaper automatically: context, memory, continuity, and reliability.

The first wave of genuinely multi-day autonomous agents will reach production. Actual deployments operating continuously on real business workflows across multiple sessions and days. The infrastructure that makes this possible is not a better model. It is persistent memory that survives across sessions, world model reasoning that prevents irreversible errors before they happen, and MCP tooling that connects agents to the systems they need to operate in. All three of these either exist already or are being built right now.

MCP wins the tool protocol standardisation. The Qwen paper lists it as one of seven first-class agent domains alongside search, terminal, software engineering, Android, web, and OS. When a frontier research lab includes MCP in the same sentence as bash terminal emulation and web browser automation, it has won. Within twelve months every major platform will support MCP for tool calling the same way every major platform supports REST for web services. Developers will expect agent memory tools to be available via MCP the same way they expect databases to have APIs.

Regulatory pressure on AI agent memory arrives. The US export control directive that suspended Claude Fable 5 and Mythos 5 in June is a preview of the category of intervention that is coming. Enterprise procurement teams in regulated industries will start requiring data residency guarantees for any system that retains information across agent sessions.

Cloud-hosted memory that routes data through servers in unknown jurisdictions fails that requirement by default. Local-first, sovereign memory infrastructure stops being a philosophical preference and becomes a procurement checkbox.

The Window That Is Open Right Now

There is something else the paper implies that nobody is saying directly.

The world model plus persistent memory architecture described in this paper is not built anywhere yet, not at the level of a production-ready developer tool. The research exists. The training methodology exists. The benchmark results exist. The deployment infrastructure does not. The gap between a research paper and a tool that a developer can install in an afternoon, configure in an hour, and run in production with confidence is where the real opportunity sits.

That gap closes on its own within twelve to eighteen months as the larger players build toward it. What closes it faster is someone who already has the memory layer, already has the MCP integration, already has the benchmark credibility, and can extend upward into world-model-aware agent orchestration before the well-capitalised competitors finish reading the paper.

The agents that will matter in 2027 are not the ones with the best base model. Base models are table stakes. They are the agents that remember what they learned yesterday, simulate what will happen tomorrow, and operate continuously without losing the thread of what they were trying to accomplish. The infrastructure that makes that possible is being built right now, in pieces, by people who understand that the intelligence is not the hard part anymore.

Memory accuracy at scale is the hard part. Continuity and trust across sessions and your entire stack are the issues to be solved. The AI that knows what happened last week on an external VPS connected to 100 different tools and databases without having to explain.

The View From Here

As I watch this progression in real time, you arrive at a stark realisation: these companies are eating everything. The majority of ideas you feed into a chat box get absorbed into product updates a few weeks later.

Those are the terms we accepted.

What does that hold for large corporations sitting on years of proprietary development, paying layers of sales staff, engineers, and support teams, when an agentic AI company can strip all of the code, absorb all of the ideas, and ship something better in a few weeks? Honestly, I would be genuinely scared if I were sitting at the top of one of those organisations right now.

I can imagine a future where software is both open-source and free and companies decide to close off their code so it doesn't get eaten by frontier LLM’s scrapers, because it is too difficult to prove providence when code can be ripped and ported to other languages and stripped of any ownership traces.

The same anxiety applies to solo developers, perhaps even more acutely. Who would pay for your product when they can get ninety percent of the value for twenty dollars a month from the same labs building the foundation models your product runs on? The only real threshold of value left is the things those twenty dollar subscriptions structurally cannot offer: no token limits, no data leaving your infrastructure, no dependency on a company whose terms of service changed last Tuesday. That is a narrow ledge to build a future company on.

The destination, if the current trajectory holds, looks something like this. OpenAI runs the hardware stores. Google serves the coffee. Anthropic sells Ikea-made furniture now with embedded Mythos AI into bedside lamps.

Kimi, DeepSeek, and Qwen provide the Chinese open source alternatives that keep the ecosystem honest but never quite reach mass distribution. Unitree and Tesla build the robotic physical layer that agents eventually inhabit. Nvidia provides the chip substrate underneath all of it, with a few outliers fighting over 10% market share crumbs.

The consumer moves between these branded experiences without ever really choosing, in the same way most people do not choose their milk source; it just appears on the supermarket shelf, and you grab the brand in front of you, pasteurized and homogenized, or the almond milk alternatives.

The positive version of that future is genuinely remarkable. Intelligence becomes a utility. The cost of building software collapses. Problems that required armies of specialists become tractable for small teams and individual developers. Medical research accelerates. Climate modelling gets cheaper. Education scales without the bureaucracy that currently throttles it.

The negative version is equally coherent. When three or four companies own the full stack from silicon to application layer, the diversity of thought that produces genuine innovation narrows to whatever those companies find commercially viable or interesting. Open source survives as a pressure valve but not as a genuine alternative at scale.

The solo developer is not liberated by cheap intelligence. They are renting their livelihood from the same platforms that could replicate their product in a sprint cycle if it ever became worth their attention. And the large enterprise is not disrupted cleanly. It is hollowed out slowly, its institutional knowledge scraped and compressed into a model that costs less per year than a single mid-level salary.

All with a high risk that the govt. or these AI companies close off your account, shutting you out from a much-needed essential service, like water or electricity.

What sits between those two outcomes is not determined yet. But the decisions being made right now, mostly in boardrooms and standards committees and government offices that do not make headlines, will determine which version arrives. And they are being made faster than most people realise.

The first decision is about data. Not data in the abstract sense that technology journalists write about, but the specific question of where the memory of an agentic system lives, who can read it, and under what legal jurisdiction it sits when an agent acts on your behalf. Right now that question has no settled answer.

The frontier labs treat memory as a feature of their platform, something that lives in their cloud, governed by their terms, readable by their models during training unless you explicitly opt out, and gone when you cancel your subscription. That arrangement is convenient. It is also a form of structural capture that most users will not notice until it matters, which is usually the moment they try to leave or export their data.

The second decision is about traversal. How AI agents move across the internet, which protocols they use, which gates they pass through, and who controls those gates is a question that is being answered right now through adoption patterns rather than deliberate choice. MCP is winning that protocol war partly because it is genuinely well designed and partly because Anthropic shipped it at the right moment and the ecosystem followed.

But a protocol owned by a company is not a standard in the way TCP/IP is a standard. It is an abstraction layer with a corporate parent. The infrastructure that agents use to traverse the web, to call tools, to read and write memory across sessions, is being standardised around a small number of implementations. Whoever controls those implementations controls the chokepoint between agents and the world they operate in.

The third decision is about access. What gets prioritized both politically and technically when an agent makes a request. Search engines already apply ranking algorithms that determine what information reaches you. Agent traversal layers will apply the same logic at a different level of the stack.

The agent calling a tool, reading a web page, or querying a database will receive results shaped by whoever controls the infrastructure it passes through. That shaping will not be visible to the user, and in most cases will not be visible to the developer either. It will simply be the water the agent swims in directed to the ponds of data controlled by whoever can game, buy, or master the technology algorithm variables behind it.

None of these three decisions are being made by the people who will live with their consequences. They are being made by the companies with the infrastructure to make them, which is a different group entirely. The open source alternatives, Kimi, DeepSeek, Qwen, GLM, keep that dynamic honest to a degree. They provide escape alternatives, as they force the frontier labs to compete on something other than lock-in.

But escape valves are not governance. They are the relief pressure that prevents the system from becoming so obviously captured that regulation becomes inevitable, which means they serve the system’s stability and leverage more than they challenge its structure.

The more uncomfortable version of this observation is that the agent future most people are excited about, the one where AI handles the tedious work and frees human attention for things that actually matter, is structurally identical to the internet future people were excited about in 2000. That future arrived. It also produced a handful of companies with more concentrated economic and informational power than anything that had existed before them. The tools were genuinely useful. The distribution of who benefited from them was not what the early builders imagined.

There is no reason to assume the agent transition will be any different in this respect. The technology will be remarkable. The applications will change how work gets done in ways that are difficult to overstate. The question of who captures the value from that change, whether it distributes broadly or concentrates narrowly, will be decided by infrastructure choices that most participants in the ecosystem are not paying attention to.

Memory residency. Traversal protocols. Access layer prioritisation. These are not exciting problems. They do not generate conference talks or benchmark leaderboards. They are, however, the problems that determine whether the next platform shift produces a different outcome than the last one did.

The question that remains open for discussion is access.

https://runtimewire.com/article/anthropic-alibaba-qwen-claude-distillation-claims

Anthropic accused operators linked to Alibaba's Qwen lab of using nearly 25,000 fraudulent accounts between April and June 2026 to extract 28.8 million Claude interactions, targeting software engineering and agentic reasoning capabilities. From Anthropic's perspective, this represents a coordinated distillation attack that shows model access control is now a core part of frontier AI competition, and they've escalated the claim to Congress as evidence that extraction at scale requires treating model outputs as part of export control policy.

From a competitive standpoint, Alibaba's interest in harvesting Claude data reflects the economics of frontier AI: if Qwen can close performance gaps cheaply through harvested examples rather than original training, it significantly reduces the cost of competing with US labs, which is exactly why frontier vendors are now asking regulators to scrutinize both chip access and API verification as security surfaces.
The distillation arms race raises uncomfortable questions about whose AI innovation gets commodified and at what cost. If frontier models trained on years of research and billions in compute can be reverse-engineered through account farming, the incentive structure for building better models collapses: the competitive advantage of expensive training evaporates the moment outputs go public. Yet the counterargument is equally uncomfortable.

Anthropic's push to treat model access as a national security issue, enforced through export controls and account verification, essentially argues that AI capabilities should be gated behind geography and corporate gatekeeping rather than distributed broadly. That framing positions cheaper, more accessible models like Qwen as a security threat rather than a public good, which benefits incumbent labs with the resources to comply with stricter controls while potentially locking out researchers, smaller teams, and developers in regions without direct US API access.

The real tension isn't between innovation and theft, but between who gets to decide whether frontier AI remains a closed platform race or becomes something more openly available.

This is not a comfortable position we all are sitting in; all of our future work is dependent on the good will of a few tech bros in Silicon Valley, who are more concerned with recouping deep billion-dollar IPO investment inference costs to pay back gambling VC Y-Combinator early investors from the naive retail and pension fund contributors.

Will the open-source models be the heroes that save the day, or will common sense move forward to reclassifying closed-source models as an essential services, similar to road infrastructure or the internet? If you don't talk about it, silence is accepted as compliance. Also, do not confuse the availability of access with cost vs. free, as that is a completely different subject.

We built a privacy-focused vector memory mobile app. And here is what it can do for you.

Vektor Memory — Fri, 19 Jun 2026 02:52:51 +0000

On sovereignty, minimalism, and the architecture of thinking.

Published by Vektor Memory — 13 min read

The Design Constraint That Determined Everything

There are approximately 4.37 million apps in the world. We know this because we looked it up while building ours. The number is not discouraging. It is clarifying. That many apps mean the space is thoroughly colonised by things that capture your attention.

What is almost entirely absent is a memory app that is privacy-focused and free that extends your thinking. That is the gap we built for, a fast, AI note taking app with a 4 stage graph based on our own Vektor Memory technology.

Before the architecture, the memory graph, or any of the technical decisions described in this article, there was a single physical constraint: phone screens are small, slippery glass rectangles with no tactile resistance. Apps with nested submenus and three taps to reach the thing you actually wanted are not just annoying — they actively interrupt the cognitive state you came to the app to support. The entire direction of good mobile UX over the last decade has pointed the same way: fewer taps, more capability, complexity handled invisibly in the background.

Apple understood this when they made the iPhone feel simple while hiding extraordinary engineering underneath. The interface is the magic trick. The architecture is what makes the experience feel easy to use, we like that philosophy.

We applied the same principle to note-taking with our memory expereince. The interface is a minimal surface. The architecture underneath is a four-layer graph with hybrid retrieval, semantic synthesis, and persistent relational edges. You should not have to be aware of any of that. You should just think and discover your ideas as they unfold.

What Vektor Notes Actually Does

You already have somewhere to put your thoughts. What you don’t have is a way to get them back when it matters. Vektor Notes is built for retrieval — the part every other notes app leaves to you.

The core interface has two modes, swiped between: JOT and CHAT.

JOT is the writing surface. A clean text area, no menus, no formatting toolbar demanding attention. An LLM watches quietly, and after 900 milliseconds of silence — long enough that it fires only when you have genuinely paused, short enough that the suggestion arrives before you lose the thread — it offers a ghost suggestion. A connection to something you have written before. Further guidance or possibly a deep question. You accept it with a tap or dismiss it with no trace. If you are in flow, it stays entirely out of the way.

CHAT is the memory conversation. You talk to your accumulated notes. You ask questions. You expand ideas. The system knows what you have stored and uses it. The retrieval is not keyword search. It is a fused pipeline that combines BM25 full-text matching with vector similarity search, merged via Reciprocal Rank Fusion, so the system finds what you meant as well as what you wrote. If you don't have a need for a specific memory, just delete it; it's that easy.

Swipe between Chat and Jot. That is the entire interface. No hamburger menu. No drawer full of settings. No notification asking you to rate the app, no telemetry, and no ads. The architecture is invisible until you need it.

The Provider Model: Your Keys, Your Data

The foundational decision, made before anything else: Your notes contain your actual thinking and not ads or pop-ups whichare a distraction. Vektor Notes runs entirely on-device, uses your own API keys stored in encrypted local storage, and never touches our servers.

Anthropic, OpenAI, Gemini, Groq, Openrouter: you configure whichever provider you want in settings, paste in your own API key, and the app uses it. The key is stored on-device using SecureStore, React Native’s encrypted key vault. It never touches our servers. We do not log your conversations.

Groq gives enough usage with performance at near-instant speeds to keep average usage within daily limits.

This is a deliberate sovereignty choice, and it costs us something: there is no frictionless “just works” onboarding for people without API keys. We decided that small tradeoff was acceptable. The people who think seriously about where their context goes deserve tools that do not harvest it quietly in exchange for convenience. That deal has been struck too many times already.

The Ghost Suggestion Engine

The JOT surface looks like a blank text editor. Under the hood, a debounce timer runs on every keystroke. The goal is to create ideas quickly, expand, save, export and move on.

The logic: when you stop typing for 900 milliseconds and your note is at least 20 characters long, a micro-response request fires. Below 20 characters, the system says nothing. You are still forming the thought, and interrupting a half-formed idea is the exact failure mode that made Clippy — the animated Office assistant that offered help you had not asked for — one of the most reliably cited examples of bad software in the history of the medium. We did not want to make another Clippy.

The request itself is a small, separate LLM call that does not block the editor and runs entirely in the background. The prompt is constrained: given this note in progress, offer a single short suggestion — a next thought, a question, a connection — in under 30 words. We deliberately capped the response length. An LLM that generates a paragraph every time you pause for a second is insufferable. Thirty words or fewer. If it cannot say something useful in thirty words, it says nothing.

The suggestion appears as ghost text beneath your current content: different opacity, a soft label reading “suggestion” in a small mono typeface. Two actions only: accept, which appends the suggestion to your note, or dismiss, which clears it with no trace. If you want to develop an idea further, that is what CHAT is for. Different users will prefer how they interact.

A parallel 2000-millisecond save debounce runs the entire time you are writing. Every two seconds of inactivity, the note saves automatically to SQLite. You never lose content to a crash or a navigation gesture. The active note ID persists to AsyncStorage, so returning to JOT from CHAT returns you to exactly where you left off.

The Save Architecture: Two Paths, One Principle

When you decide a JOT is worth keeping, two paths are available. The distinction matters more than it sounds.

Quick Save routes the raw text directly into the memory database as a semantic layer entry with a default importance score of 0.75. No extraction. No transformation. The text goes in whole, preserved verbatim.

Synthesise triggers a structured LLM call with a specific extraction prompt: pull out a title, a list of tags, named entities, a one-paragraph summary, and infer a layer classification — semantic for ideas and facts, temporal for events and time-based context, causal for cause-and-effect observations, entity for people and things. The result comes back as a JSON object and gets written as a proper memory node into the MAGMA graph, with typed edges connecting it to semantically related existing nodes.

Critically: the raw text also goes in, alongside the structured record. Both paths persist. You never lose the original by choosing to synthesise.

This is a direct consequence of a principle the paper True Memory (arXiv:2605.04897) makes explicit, and that we had arrived at independently: content discarded before the query is known cannot be recovered at retrieval time. The synthesis structure is useful. The original wording is irreplaceable. Keep both.

MAGMA: The Memory Graph Underneath Everything

MAGMA is the four-layer graph architecture that separates Vektor Notes from a notes app with a chat window bolted on.

The four layers are not organisational categories. Each represents a different type of relationship between memories, which determines how they are retrieved.

Semantic layer — facts, ideas, concepts, observations. Edges connect semantically related nodes. The relationship is similarity-based but persists as an explicit graph edge, not a vector lookup recomputed on every query. The edge is a durable connection in the database.

Temporal layer — events, sequences, time-based context. The temporal layer preserves ordering: these events are connected not just by topic similarity but by when they occurred relative to each other. This is the layer that makes “what was I thinking about before I made that decision?” answerable with something more than a keyword search.

Causal layer — cause and effect, reasoning chains, decisions and rationale. Edges in this layer are directional and typed: one node causes or influences another. This is the layer that most agent memory systems skip. It is the layer that makes the app feel less like a notebook and more like an externalised reasoning history.

Entity layer — people, organisations, projects, locations. Named entities extracted during synthesis get their own nodes here, with edges connecting them to every memory node that mentions them. “What is my history with this project?” becomes a graph traversal, not a full-text scan.

The entire graph lives in a single SQLite file, on-device. The schema: a memories table for nodes with content, layer, importance score, and metadata; a memory_edges table for typed directional relationships; an FTS5 virtual table for BM25 full-text search; and a vec_memories table using the sqlite-vec extension for float32 vector embeddings via approximate nearest-neighbour search.

No Pinecone. No Neo4j. No cloud database. No GPU. The whole thing is a file on your phone; queries execute in milliseconds, and it backs up with your device backup.

If you don’t want to use the app any longer, take your memories and move them somewhere else, we also give you free open-source tools to migrate into another database format with VEX.

The Retrieval Pipeline: How CHAT Finds What You Stored

When you ask something in CHAT, the retrieval pipeline runs before the LLM sees your question. This is the part that determines whether the app feels like it actually knows you, or like a polite chatbot with amnesia.

The pipeline runs two parallel paths that are then fused.

BM25 keyword search. Your query is tokenised and run against the SQLite FTS5 index, applying the BM25 ranking algorithm to the raw text of every stored memory. BM25 executes in single-digit milliseconds and excels at exact and near-exact term matching. If you wrote about a configuration issue three weeks ago and now ask about it, BM25 finds it immediately because the specific phrase is there.

Vector similarity search. Your query gets embedded using the same model as your stored memories, and the sqlite-vec ANN index returns the k most semantically similar nodes. This catches what BM25 misses. You stored something as “the authentication flow that kept breaking in production” and you ask about “login problems; the vocabulary is different, the semantic space is overlapping, and the vector path bridges the gap.

The two result sets are merged using Reciprocal Rank Fusion. RRF combines ranked lists by summing the reciprocal of each result’s rank position across all lists: for each document, 1/(k + rank_in_list) for every list it appears in, where k is a smoothing constant of 60. Documents appearing highly in multiple lists score best. RRF is stable across different corpus sizes without per-user calibration. It works.

The top-k fused results — typically five to ten memory nodes — get formatted into a structured context block that prefixes your question in the LLM prompt. The LLM sees your question and a curated selection of relevant memories, not your entire history. Context windows are not free. Stuffing every note into every request would be slow, expensive, and would dilute the relevant signal with noise. The retrieval pipeline does the filtering work so the LLM does not have to.

The Toolbar: Eight Items, One Active Label

The bottom toolbar has Jot, Chat, Notes, Inbox, Graph, Memory, Search, and Config Settings.

Eight items at 380 pixels wide is tight. The implementation labels every item at all times. The result is eight-and-a-half-point monotype trying to render “Settings” in approximately 41 pixels next to seven identically weighted neighbors.

All icons are custom inline SVG components, not Unicode characters or icon library imports. Icon libraries look exactly like icon libraries. Custom SVG means the weight and style are native to this specific product.

The Memory icon is concentric circles with a centre dot, referencing the hippocampal imagery from the HippoRAG research on neurobiological memory architecture. The Graph icon is four nodes and three edges, readable at 18 pixels, which takes more iterations to get right than you would expect. The users who notice will understand immediately.

The Technical Build: React Native and Expo

The app is built in React Native with Expo. One codebase, two targets — Android now, iOS in the next release — with an ecosystem mature enough that the specific problems we would encounter (gesture handling, keyboard avoidance, safe area insets, hardware-accelerated animations) all had documented solutions.

The swipe gesture between JOT and CHAT uses react-native-gesture-handler and react-native-reanimated, driving a shared translation value on the UI thread. The animation runs on the Reanimated worklet thread, hardware-accelerated, meaning it does not drop frames even when the JS thread is processing an LLM response in parallel. The naive implementation had a visible stutter when a CHAT response arrived mid-swipe. The fix was isolating the animation shared value from the response state so neither thread blocks the other.

Keyboard avoidance is different on each platform. On Android, softwareKeyboardLayoutMode: "pan" in app.json handles the viewport correctly without a KeyboardAvoidingView wrapper. On iOS, KeyboardAvoidingView with behavior="padding" and a measured safe-area offset is required. The same code does not work for both platforms, and getting it wrong is immediately visible to any user who types anything.

All SQLite operations run via expo-sqlite for the base database and sqlite-vec loaded as a native extension for vector operations. Every database call is wrapped in async/await.

The Ecosystem

Vektor Notes is the consumer face of a wider set of memory infrastructure tools built over the past year. The app makes more sense in that context.

The Memory SDK is the npm package that powers the memory layer in Notes and can be dropped into any Node.js agent or workflow. It exposes the MAGMA graph, the hybrid retrieval pipeline, and a full MCP (Model Context Protocol) server with 50+ tools across memory, browser automation, SSH, and multimodal categories. Configure it in claude_desktop_config.json with a licence key and the SDK path, and any MCP-compatible agent has persistent memory across sessions: store facts during a session, retrieve them in any future session, with semantic, keyword, or graph-traversal retrieval depending on query type.

The intelligence layer includes recall tuning that adjusts retrieval weights based on past session utility; contradiction detection using an ADD-only policy — new contr
adictions are flagged as conflicts rather than silently overwriting older memories, because overwriting is how agents develop false beliefs and then act confidently on them; deduplication; namespace isolation for multi-project use; and a background consolidation cycle that fires when the app is idle.

VEX CLI is the open-source migration tool, built around a .vmig.jsonl interchange format for agent memory portability. Export from one agent, import into another. Backup. Migrate. Merge two separate memory stores. The v0.3 roadmap includes Drift Adaptor — cross-model vector translation for migrating memories between embedding models that do not share a geometric space.

Via CLI is the integration layer at v0.3.0 that wraps common agent workflow patterns into composable commands: handoff generates a structured session summary (decisions made, things changed, things pending), memory queries or stores, serve starts a local MCP-compatible server. At the end of a session, via handoff writes the context. At the start of the next, via memory loads it. The agent continues where it left off without re-explanation.

Why Memory Is the Whole Point

Notes apps are not productivity tools. They are memory prosthetics. The reason you take a note is that biological memory is fallible, context-dependent, and lossy. The note is a retrieval aid. The app is a retrieval system.

The problem with current note apps on the market is that they optimise for capture and treat retrieval as your problem. You put things in, getting them back out requires a keyword bar and your own memory of how you organised everything. The app is a very expensive text file.

What we were trying to build is a notes app where retrieval is the product. The capture is the input. Everything else — the MAGMA graph, the hybrid retrieval pipeline, the synthesis architecture, the on-device vector search — exists so that what you put in is actually available to you when you need it, in the form most useful to the question you are currently asking.

This connects directly to the research underpinning the design. HAGE (arXiv:2605.09942) argues that stored notes should form a weighted graph with learned relational edges, and retrieval should be query-conditioned — following temporal edges for time-based questions, entity edges for people-based questions, causal edges for why-questions. MAGMA is this structure without the RL training layer yet. That is where the roadmap leads.

True Memory (arXiv:2605.04897) argues you should not extract too aggressively at save time. Keep the raw event. Build structure later, at query time, when you know what question is being asked. This is why synthesis is optional in Notes, why quick save preserves the raw text whole, and why both paths persist when you do synthesise.

Both insights run silently under what looks, to the user, like a clean text editor with a thoughtful companion. The simple interface is the magic trick that makes it usable. The architecture underneath is what makes it useful.

Simple, upfront tools, and all of the complex tech is hidden behind the scenes where it needs to be. As we receive more feedback, we will adjust and refine the settings to suit the actual user experience.

Vektor Notes v1.0.4 is available now on Android via Google Play.

https://play.google.com/store/apps/details?id=com.vektormemory.notes

iOS release to follow. The info for the Memory SDK, VEX CLI, and Via CLI are available at vektormemory.com.

Mobile App Development
Ai Memory
Notetaking
Android App Development

The self-improving prompt engine that learns from your codebase history

Vektor Memory — Sun, 14 Jun 2026 02:05:55 +0000

Via v0.4.0: We Built a CLI That Gets Smarter Every Time You Use It

We shipped Via v0.4.0 today another weekend project based on utilizing prompt development in a different method. The headline feature is something we have not seen as a methodology in the AI tooling space currently that we are aware of.

Every prompt you run teaches the next one. Every correction gets stored. Every success becomes a reusable pattern. After a month of daily use, the prompts Via generates know more about what works in your codebase than you consciously remember.

Here is how we built it, why it works, and what it took to get there.

The Problem With Every Other Prompt Tool

The AI coding tool space has a prompt problem. Not a model problem. Not a context window problem. A prompt problem.

73% of engineering teams now use AI coding tools daily. The developers pulling ahead are not using better models. They are using better prompts. Specific, structured, historically-informed prompts that give the model enough context to produce quality output on the first try.

The problem is that every prompt tool on the market is static. Someone writes a template, ships it, and it never changes. You get the same generic structure whether it is your first day using the tool or your hundredth. The tool has no memory of what worked for you last week, what you tried and abandoned last month, or what your team’s specific patterns look like.

The biggest frustration cited by 66% of developers is dealing with AI solutions that are almost right but not quite. The second biggest is that debugging AI-generated code takes longer than debugging code they wrote themselves.

Both problems trace back to the same root cause. The AI does not know your codebase. It does not know what you tried before. It does not know what your team considers a good solution. Every session starts from scratch.

Via v0.4.0 fixes that.

The Research Behind the Design

Via prompt did not come from thin air. While building it we found a paper published in March 2026 that described almost exactly what we were trying to build.

MemAPO, from a team at Zhejiang University, reconceptualises prompt optimization as generalizable and self-evolving experience accumulation.

It maintains a dual-memory mechanism that distills successful reasoning trajectories into reusable strategy templates while organising incorrect generations into structured error patterns that capture recurrent failure modes.

Given a new prompt, the framework retrieves both relevant strategies and failure patterns to compose prompts that promote effective reasoning while discouraging known mistakes.

That is precisely the architecture Via prompt takes inspiration from. Success patterns on one side, failure patterns on the other, both retrieved to inform the next prompt. MemAPO achieves the best average performance across all datasets while reducing cost by approximately 57.2% compared to the strong baseline TextGrad.

The difference between MemAPO and Via prompt is deployment. MemAPO is a research system evaluated on controlled benchmarks. Via prompt is a production CLI that runs locally, requires zero external dependencies at the base tier, integrates with real coding agent workflows, and stores everything on your machine. The research proved the pattern works. Via ships it.

The full paper is at arxiv.org/abs/2603.21520 and is worth reading if you want to understand the theoretical foundations behind the approach.

What Via Prompt Actually Does

The core idea is simple. Via keeps a local history of every prompt you generate, every outcome you record, and every constraint you add. When you ask for a new prompt, it retrieves the most relevant past patterns and injects them into the generated prompt before you see it.

The terminal output looks like this:

┌─ VIA PROMPT ENGINE ───────────────────────────
│
│ Confidence High 🟢 (12 past tasks, 91% success rate)
│
│ + Context injected:
│ + "add JWT authentication to the Express API..." → success
│ + "implement token refresh middleware..." → success
│
│ - AVOID injected:
│ ⚠ never use Passport.js [global]
│ ⚠ avoid localStorage for auth tokens [global]
│
└───────────────────────────────────────────────

[Generated Prompt — ready for Claude / Codex / Gemini]

SYSTEM

You are implementing a feature. Match the existing architecture
and code style exactly. No new dependencies unless explicitly
requested.

GOAL

implement OAuth login for the API

PATTERNS THAT WORKED

Task: "add JWT authentication to the Express API" → succeeded
Task: "implement token refresh middleware" → succeeded ## AVOID
never use Passport.js (reason: tried and abandoned, too complex)
avoid localStorage for auth tokens (reason: security policy) ## SUCCESS CRITERIA Complete, working, matches existing codebase patterns. No new dependencies unless explicitly requested. State confidence in the approach before implementing. That is not another generic template. That is a prompt that knows your codebase, knows what worked last time, and knows what to avoid. The difference in output quality is significant.

Cli tool interface:

The Architecture — Five Components, Zero Required Dependencies
Via prompt is built around five components. Everything works out of the box with no external dependencies. Everything gets better as you add VEKTOR or an LLM API key.

Storage is a JSON file at ~/.via/prompts.json by default. It upgrades to SQLite automatically when your history exceeds 500 records. It upgrades to VEKTOR Slipstream if you have it installed. The user never configures this — Via detects and upgrades silently.

Retrieval uses a pure JavaScript BM25 implementation with Porter stemming. No native binaries, no external packages, no installation friction. BM25 is meaningfully better than keyword matching — it handles partial matches, handles stemming (so “authentication” finds “authenticate” and “auth”), and scores by term frequency weighted against document length. If VEKTOR is installed, retrieval upgrades to BM25 plus semantic vector search fused via Reciprocal Rank Fusion.

Assembly takes retrieved success patterns, retrieved failure patterns, the AVOID store, and the new task, and builds a structured prompt with six sections: SYSTEM, GOAL, CONTEXT, PATTERNS THAT WORKED, AVOID, and SUCCESS CRITERIA. Without an LLM API key, assembly is template-based and deterministic. With a key (any of Anthropic, OpenAI, Groq, or local Ollama), the LLM refines the assembled template into a coherent, well-written prompt.

Feedback capture is a single command: via prompt --learn success, via prompt --learn correction --note "what was wrong", or via prompt --learn revert. Optional git hooks capture success automatically when you commit and prompt you on revert.

Export writes the accumulated intelligence into whatever format your tools need. via prompt --export claude writes a CLAUDE.md block that every Claude Code session loads automatically. via prompt --export yaml produces a diffable YAML file you can commit to your project repo so the whole team starts from your learned patterns.

The AVOID Store — The Feature Nobody Else Has

Every AI tool helps you do things. None of them remember what you tried and abandoned.

Via’s AVOID store is a persistent list of constraints that gets injected into every generated prompt automatically. Each entry has a constraint, a reason, a scope, and a decay counter.

Scope matters. A global constraint like “never use Passport.js” applies to every auth-related task forever. A file-scope constraint like “do not use callbacks in user.js” only injects when the current task involves that file. A directory-scope constraint applies to a specific module.

Decay prevents the AVOID store from growing forever. If a constraint has not been relevant in 30 tasks, it gets archived — still searchable but no longer auto-injected. Global constraints never decay. This prevents what the research literature calls attention collapse, where an over-constrained LLM gets so focused on what not to do that it fails to write the actual feature.

The AVOID store is the most defensible part of Via prompt. Generic skills packages can copy the template structure. They cannot copy six months of your team’s specific failures.

JIT Abstraction — Rules That Write Themselves
One of the hardest problems in prompt memory systems is that raw records do not scale. Injecting “fix null pointer in user.js” verbatim into a prompt about a different bug is more distracting than helpful. You want the general rule, not the specific instance.

Via solves this with Just-In-Time abstraction. When retrieval pulls five similar past records, Via sends them to the LLM with a simple instruction: extract one general rule that would improve performance on the current task. The abstraction is ephemeral — it exists only for this prompt session. If the user records a success outcome, the abstraction gets permanently promoted to the generic patterns store. If the outcome is correction or revert, the abstraction is discarded and the raw records remain untouched.

This prevents hallucinated rules from polluting the system permanently. Bad abstractions get discarded. Good ones compound. After a few months the generic patterns store contains real distilled knowledge from real task history, not guesses.

Task-Type Aware Token Budgets

Context windows are finite. If Via injects five success patterns, three failure patterns, architecture context, and an AVOID list without any budget management, it blows up the agent’s context window before the actual task gets enough space.

Via allocates tokens differently depending on the task type.

For debug tasks, 40% of the token budget goes to failure patterns and AVOID constraints. That is where the signal is when you are fixing a bug — you want to know what was tried and failed, not success stories from unrelated features.

For implement tasks, 40% goes to success patterns. You want the model to see what good implementation looks like in this codebase and match it.

For review tasks, 50% goes to context and standards. The model needs to know your team’s conventions, not just past task outcomes.

The allocations ship with Via and get refined automatically as the system learns which budget splits produce the best outcomes for your specific workflow.

Everything Else in v0.4.0

Via prompt is the flagship feature but v0.4.0 shipped four other significant upgrades.

via memory now supports hybrid search. via memory search "query" --hybrid fuses BM25 keyword search with VEKTOR semantic search using Reciprocal Rank Fusion. via memory sync pushes all stored facts to VEKTOR for semantic recall. Neither requires VEKTOR to be installed — both degrade gracefully to BM25-only if it is not present.

via task now has a team-shared board. via task board shows a kanban view with OPEN, IN PROGRESS, and DONE columns. via task share exports the board to .via-board.json in the project root. Commit that file to Git and teammates run via task sync to pull the latest board into their local SQLite. Zero infrastructure. Zero cost. File-based team coordination that works with any Git workflow.

via diff --live streams two AI tool responses simultaneously in the terminal. Run via diff --live "explain async/await" --tools claude,openai and both responses stream side by side. Results save to the local database for comparison history.

via convert --batch converts entire folder trees. via convert --batch ./docs --to md walks the directory recursively, shows a progress bar, skips already-converted files by default, and routes each file to the right converter — ImageMagick for images, FFmpeg for audio and video, Pandoc or LibreOffice for documents.

The Compounding Effect

The reason Via prompt works is not any individual feature. It is the flywheel.

Week one: Via generates context-enriched prompts. Useful. Not dramatically different from a well-written manual prompt.

Week four: Via has seen 50 tasks. It knows which prompt structures produced clean first-pass results. The prompts it generates are noticeably more precise. The AVOID store has real entries from real failures.

Month three: Via has failure patterns for every major subsystem. Success templates for the task types you run most often. Generated prompts rarely need correction because the system has learned your specific patterns.

Month six: The learned patterns live in CLAUDE.md. Every session in every tool starts with this context automatically. Via has encoded six months of institutional knowledge into a file that any agent reads on startup.

Static skills packages cannot replicate this. Skills are fixed at the moment someone writes them. Via grows every session.

The research backing this pattern is solid. MemAPO, published March 2026, showed that reconceptualising prompt optimization as self-evolving experience accumulation outperforms static prompt templates across every task category they tested. SEW, published April 2026, showed that self-evolving workflows produce up to 12% improvement on coding benchmarks versus using the backbone LLM alone.

Via is the production implementation of those research insights. Local-first, zero-dependency at the base tier, no cloud required, and getting smarter every time you use it.

Via v0.4.0 is available now.

npm install -g @vektormemory/via
via prompt "your first task here"
Source and documentation at vektormemory.com.

The Vektor Memory Ecosystem

Via is one part of a broader set of tools built around the same principle — your AI tools should remember things, and that memory should belong to you.

VEKTOR Slipstream — Persistent memory SDK for AI agents. Local SQLite, 8ms recall, 79.0% on LongMemEval (12 points above full-context GPT-4). npm install -g vektor-slipstream

Give any AI agent persistent memory that survives across sessions, restarts, and model switches
Drop it into Claude Desktop, Claude Code, or any MCP-compatible tool as a zero-config MCP server
Store decisions, facts, code patterns, and architectural choices that your agent recalls automatically next session
Search your memory with BM25 plus semantic vector search fused via RRF — finds what you need even when the vocabulary differs
Build a temporal index of your project history — what changed when, what was decided and why
Extract named entities and traverse the knowledge graph across related memories
Run vektor_store after each session, vektor_recall at the start of the next — your agent picks up exactly where it left off
Benchmark-verified at 79.0% on LongMemEval across 105 questions averaging 344 stored memories each — beats full-context GPT-4, Mem0, ReadAgent, and MemGPT
Works entirely offline, zero cloud dependency, your data never leaves your machine

VEX — Cross-standard vector database migration and memory portability. 12 connectors, Apache 2.0. npm install -g @vektormemory/vex

Migrate your entire memory between any two vector stores in one command — Pinecone, Qdrant, ChromaDB, Weaviate, pgvector, Redis, Milvus, Neo4j, VEKTOR
Import your full Claude conversation history with LLM fact extraction — turns chat logs into structured, searchable memories
Import ChatGPT conversation exports the same way — bring your history with you when you switch models
Extract facts with importance scoring, deduplication, and tag classification using any LLM provider (Groq, OpenAI, Anthropic, Ollama, Mistral)
Convert memory exports to OpenAI fine-tuning format, Anthropic Messages format, or plain text transcripts
Sign exports with BLAKE3 plus Ed25519 for tamper-evident transfer between systems
Back up your entire memory to any Git host with vex sync — GitHub, Codeberg, or self-hosted Gitea
Encryption is AES-256-GCM client-side before anything leaves your machine — the Git host sees opaque ciphertext only
The key is derived from your machine ID plus token hash and never transmitted — you own it completely
Restore your full memory on a new machine in under a minute with vex sync pull

Via — Universal AI tool integration layer. Works everywhere your agents work. npm install -g @vektormemory/via

Generate historically-informed prompts that get smarter every session with via prompt
Store and search facts across all your AI tools with relationship-aware codebase indexing
Run a team-shared task board backed by SQLite, shareable via a single Git-committed JSON file
Convert any file locally — images, audio, video, documents — with via convert, nothing uploaded anywhere
Convert entire folder trees recursively with via convert --batch, progress bar included
Compare two AI tools side by side in real time with via diff --live, both responses streaming simultaneously
Export your accumulated prompt intelligence to CLAUDE.md, YAML, Codex config, or Gemini TOML — one source, every surface
Install optional git hooks that capture prompt outcomes automatically on commit and revert
Wire Via into Claude Desktop, Cursor, and Windsurf in one command with via init
Run Via as an MCP server so any MCP-compatible agent can access your memory, tasks, and prompt history

Vek-Sync — MCP configuration sync. Keeps your MCP server setup in sync across every AI editor from a single source of truth. Open source. github.com/Vektor-Memory/Vek-Sync

Define your MCP servers once in a single config file and sync to Claude Desktop, Cursor, Windsurf, VS Code, Cline, and any other MCP-compatible editor automatically
Stop maintaining twelve separate config files for three MCP servers across four editors — one file, one command, everywhere updated
Version control your MCP configuration in Git alongside your project — config changes are diffable, reviewable, and rollbackable
New team member joins: clone the repo, run Vek-Sync, every MCP server appears in every tool instantly
Switch editors without losing your MCP setup — your memory tools, filesystem access, and API connections follow you
Works with any MCP server including VEKTOR Slipstream, GitHub, filesystem, and any custom server you have configured
Treats MCP configuration as infrastructure — the same discipline you apply to .env files and docker-compose.yml, applied to your AI tool layer
Zero cloud, zero account, plain JSON files synced by a local script

VEKTOR Notes — Local-first note-taking app with persistent AI memory built in. Available on Android (Google Play internal testing, iOS coming).

Write notes that your AI agent can recall across sessions — every note stored in the VEKTOR memory graph automatically

Search your notes with the same BM25 plus semantic recall that powers VEKTOR Slipstream — finds what you meant, not just what you typed
JOT Collab built in — four seconds after you stop typing, it surfaces a relevant insight, a gap suggestion, and four arXiv papers from the literature
Cross-session memory — start a new writing session on the same topic and it surfaces what you noticed last time
Export any note as structured markdown with APA citations, ready to paste into a Medium draft
Build article drafts from your notes with one tap — eight-section structure generated from your accumulated thoughts and research
Runs entirely on your device, zero cloud dependency, your notes and memories stay local
Connects to your VEKTOR Slipstream memory graph — notes you take on mobile are recalled by your desktop agents automatically
All tools are local-first. No cloud required. $9 monthly subscription for the core functionality in Vektor Memory Slipstream with Cloak tools per month. Your data stays on your machine.

Via, Vek, Vex, are all Open Source and built by Vektor Memory. vektormemory.com

Open Source
Prompt Engineering
Github
LLM

Loopers, Robovacs and the Demise of the /Prompt

Vektor Memory — Fri, 12 Jun 2026 22:00:44 +0000

A Weekend Gonzo Field Guide to /loop Engineering

Another weekend piece of satire, devoid of real-life advice but stacked with enough cyberpop residue to pass as insight. Grab your chai tea and add another scoop of ashwagandha, and hang on.

The Mafia Boss Was Right

I watched Looper the other week for the 8th time. Bruce Willis and Joseph Gordon-Levitt—I had to look him up to remember his name as well, the Inception guy. He was good in the film, not quite Bruce Willis tier yet, but the hover bike scene was epic, and you know you want one. The movie is about time loops, obviously, but the line I can’t shake is the mob boss who says “go to China, kid, that’s where everything is happening.”

He wasn’t wrong. Very prescient indeed; also, he did have access to a time machine, so that is easy to say in retrospect.

Chinese cities have hit Blade Runner rendering at 4K, from a distance that most Western cities won’t reach for another decade. AI-controlled infrastructure, EVs from wall to wall, drone delivery to your apartment, and facial/palm recognition at the checkouts. Then you scroll back to most Western cities, and it’s underwhelmingly patchy: some surveillance cameras bolted to old telephone poles if they haven't been cut down, a couple of EV charging stations in the nice part of town, clusters of fast food shops, and the crowd went mild.

The uncomfortable question isn’t technical. It’s political funding and lack of infrastructure. Can you get that level of coordinated city tech without the control structure that produced it? Can you be a selective quasi-futurist and take the drone delivery and skip the social credit score?

Hard questions to answer even for Mustapha Mond while neck-deep into a weekend soma binge.

Your perspective probably depends on where your loyalty sits and also whether you’ve ever had Amazon lose a parcel or seen your face on a digital billboard for jaywalking and not paying the auto-fine. Can't we just have a common-sense middle ground mix of the future promised and self-sovereign autonomy?

It's like when you're at the takeaway shop and you are asked if you want chicken salt or gravy on your chips/fries.

I want both the gravy and the chicken salt included. Where in the rulebook did we have to lose all of our freedoms to gain future tech conveniences?

Why would anyone accept anything less from their governments?

That aside, the real loop I want to talk about is the one about to happen in your terminal right now. Or the one that already has, if you're an uber-tech-cool dude with a mustache.

It is definitely a trend… both the /loop and the mustache.

Stop Prompting Like a Caveman

Peter Steinberger said it plainly:

“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

Boris Cherny, head of Claude Code at Anthropic, said essentially the same thing from the inside as he chuckled at your 2025 prompting skills:

“I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.”

The age of the perfectly crafted prompt recipe with that artisanal, hand-ground, single-origin crema you either copied from a GitHub repo or spent forty-five minutes composing is ending. Why?

Not because prompts are useless. They’re not. But treating a prompt as the unit of work is like writing every email as a manual process when you could have written one rule that handles all of the send/return emails forever.

Loop engineering is the move from user of tool to designer of system. You stop being the person who types like a caveman. You become the person who builds the thing that types, like a Gödel boss.

Kurt liked logic, and so should you: /loop it

And before you say “that sounds expensive," you're right for once; it is!

We’ll get to how to save on those bougie token costs. Not everyone has Boris’s Anthropic employee token credit line or Steinberger’s OpenAI gargantuan startup budgets.

We just need a few more billion; is that ok? Just one more, and then we will stop, just a little more GPU inference seed money. We will pay you back, I promise in the IPO.

Look at the SpaceX IPO, it hit $170 today, not bad, my wife couldn't stop talking about it: “We need SpaceX; we are going to Mars”, we are probably not going to Mars, as there is no atmosphere and there are no shops or fish and chip takeaways. It sounds boring to be honest, red dirt, besides the achievement part for humankind. I’m not interested in becoming a potato farmer like Matt Damon.

The frenzy around it, the oversubscribed rounds, the institutional queues, and the retail hysteria, tells you something important that has nothing to do with rockets. That there are billions of dollars out there actively sloshing around, desperately looking for somewhere to land.

Sovereign wealth funds, pension managers, venture firms, and retail investors are all competing for the same scarce commodity: a compelling place to put money to work. The capital exists for technology investing.

So when people argue that we lack the resources to address climate change, the unhoused in tents, crumbling infrastructure, or antibiotic resistance, they are not quite telling the truth. The resources are there. The issue is not that there is not enough capital to solve today’s problems. The issue is where it all goes.

Cron Is a Metronome. A Loop Is a Heartbeat. Know the Difference.

Cost-effective looping is a first-class concern here, and we will get down to brass tacks soon, but first I have to go on another technical tangent.

Here’s the question I kept bouncing around: What's the actual difference between cron and looping agentically?

It sounds like a silly question until you realise most people conflate them and then build the wrong thing.

Cron is time-driven, as Chronos is the master of time… You are learning today!

It says, "Run this at 2am every day." It does not care what happened before. It wakes up, fires the job, and goes back to sleep. Cron is for periodic tasks — backups, syncs, log rotation, and report generation. It assumes the world can wait for the schedule.

A loop is state-driven. It says, "Keep going until this condition is true." It reacts. It retries. It pauses. It watches. A loop assumes the world is changing while it’s running.

The practical split for agentic work:

In Claude Code terms: /schedule or GitHub Actions for cron-style cadence. /loop for "keep iterating," /goal for "keep going until this specific condition is verifiably true."

The /goal primitive is the spicy one: it runs a separate model to check whether you're actually done, so the agent that wrote the code isn't also the one grading its own homework.

That’s the maker/checker split, and it’s the single most important structural idea in loop design. We’ll come back to it, don't worry and sorry if this bored you, super coders.

The Six degrees of Kevin Bacon loop separation

A loop running unattended is not one long prompt in a while loop. It’s a small system with six parts. Five capabilities, one spine.

Part 1 — Automations: The Heartbeat

The heartbeat is what makes it a real loop and not just a one-off agent session you ran once and forgot about.

In Claude Code: /loop [interval] for recurring runs, /goal for run-until-done, hooks and GitHub Actions for persistence outside the chat session. The /goal pattern is particularly powerful: you write a verifiable stopping condition ("all tests in test/auth pass and lint is clean"), walk away, and a fresh model checks it at each turn rather than the worker checking itself.

Quick start:

Run a triage scan every morning at 8am via GitHub Actions

.github/workflows/morning-triage.yml

on:
schedule:
- cron: '0 8 * * 1-5'
jobs:
triage:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Claude triage loop
run: claude -p "$(cat .claude/prompts/morning-triage.md)" --output-format json > triage-output.json
Keep the heartbeat cheap. Discovery and triage should cost pennies. Sub-agents that actually do work should only spawn when the state file says there’s something worth doing.

Part 2 — Worktrees: Parallel Without the Pile-Up

Two agents writing the same file simultaneously is a merge disaster. Git worktrees fix this by giving each agent its own working directory on its own branch, sharing history but never colliding.

Spawn an isolated worktree for a parallel agent session

git worktree add ../feature-auth-fix -b fix/auth-token-expiry

Claude Code flag

claude --worktree fix/auth-token-expiry "Fix the token expiry bug in auth.ts"

In .claude/agents/verifier.md — set isolation

isolation: worktree

Each sub-agent gets a fresh checkout, auto-cleans on exit

The rule: one agent, one worktree. They can share the repo history. They cannot share the working directory.

Part 3 — Skills: Stop Explaining Your Project From Scratch Every Single Run

Every session, the agent starts cold. Your conventions, your build commands, the reason you never use that particular pattern — gone. Unless you wrote it down.

A SKILL.md file is how you externalise intent. It's the project knowledge that should survive across runs. Without it, every loop iteration is day one. With it, the loop compounds.

Structure for a useful skill file:

.claude/skills/
project-conventions.md # naming, patterns, things we don't do
testing-standards.md # what "done" means for tests
deployment-checklist.md # what the loop should verify before PR
review-criteria.md # what the verifier checks
The skill description matters more than the content. A tight, boring description beats a clever one, as the agent needs to match it reliably, not be impressed by it.

Part 4 — Connectors: From Commentator to Operator

A loop that can only see the filesystem is a loop that can only suggest. MCP-based connectors are what let it act: open PRs, update Linear tickets, post to Slack, query staging APIs.

The difference between an agent that says “here’s what I’d do” and a loop that opens the PR, links the ticket, and pings the channel when CI goes green.

Both Claude Code and most modern agent tools now speak MCP natively. A connector written for one tends to port easily to another. Priority connectors for a useful coding loop: GitHub (PRs, issues), your issue tracker (Linear, Jira), Slack or Discord for human handoff alerts.

Part 5 — Sub-Agents: The Maker/Checker Split

This is the most important structural decision in any loop you build.

The agent that wrote the code is too invested in its own work to catch its mistakes. This is not a model flaw — it’s structural. You need a second agent with different instructions, sometimes a stronger model, to verify.

.claude/agents/implementer.md

name: implementer
model: claude-haiku-4-5 # fast, cheap, does the work
instructions: |
Implement the task from STATE.md.
Write code, run tests, log results.
Do NOT approve your own work.

.claude/agents/verifier.md

name: verifier
model: claude-sonnet-4-6 # stronger model for the judgment call
instructions: |
Review the implementer's output against:

.claude/skills/testing-standards.md
.claude/skills/review-criteria.md Approve, reject with specific reasons, or escalate to human. The typical split: explorer (fast, broad), implementer (focused, executes), verifier (different instructions, checks against spec). Token budget: the implementer can be Haiku, the verifier earns Sonnet.

Part 6 — State: The Spine Everything Else Runs On

This is the least glamorous part and the most important.

The loop forgets everything between runs. The state file doesn’t. It’s what lets tomorrow’s run pick up where today’s stopped. Three questions a good state file always answers:

What are we working on right now?
What did we try last time, and what happened?
What needs a human?

LOOP-STATE.md

Active

[ ] AUTH-247: Fix token expiry race condition (implementer in progress, worktree: fix/auth-token-expiry) ## Completed This Run
[x] AUTH-231: Null check on refresh handler (merged PR #412)
[x] LINT: Trailing whitespace in auth.ts (fixed) ## Awaiting Human
AUTH-239: Database migration required — scope unclear, needs review
TEST: Integration test failing on CI but not locally — environment mismatch suspected ## Last Run 2026-06-11 08:00 — Triage: 3 issues found, 2 actioned, 1 escalated Keep it in the repo. Commit it. The state file is often the most valuable artifact the loop produces.

A Real Loop in One Page

Stick the six parts together and here’s what a practical morning loop looks like:

8:00am — GitHub Actions fires morning-triage.yml
↓
Triage agent reads: CI failures, open issues tagged "bug", recent commits
→ Writes findings to LOOP-STATE.md
→ Rates each item: actionable / needs-human / skip
↓
For each actionable item:
→ Spawn implementer agent in isolated worktree
→ Implementer reads relevant SKILL.md files
→ Implementer makes changes, runs tests
→ Writes result to LOOP-STATE.md
↓
Verifier agent reads implementer output
→ Checks against review-criteria.md
→ Approve: open PR via GitHub MCP connector
→ Reject: log reason in STATE.md, flag for next run
→ Escalate: post to Slack with context
↓
Human receives: Slack summary + PR links + anything needing eyes
You designed that once. You didn’t prompt any of those steps. Those are Steinberger’s & Boris’s points made concrete.

The Token Problem Is Real and Here’s How You Don’t Go Broke

Look, not everyone has Boris’s Anthropic tab. Token costs in a naive loop can go from “productivity win” to “budget incident” very fast. Here’s how to stay cost-effective.

The tiered model pattern. Use cheap models for cheap work.

Discovery and triage: Haiku. Fast reads, structured output, costs almost nothing.
Implementation: Haiku or Sonnet depending on complexity. Let the skill file define escalation criteria.
Verification: Sonnet. This is where the judgment matters. Spend here.
State file updates: Haiku. It’s just structured writing.
Rough hierarchy: Haiku ≈ 70% cheaper than Sonnet for similar throughput tasks. Route accordingly.

The conditional spawn rule. Sub-agents should only spawn when the state file says the item is worth doing. Don’t fan out speculatively. Triage first (cheap), act second (less cheap), verify last (worth it).

The /goal brake. Always write stopping conditions. A loop without a stopping condition is a billing event.

Good: verifiable stopping condition

claude --goal "all tests in test/auth pass, lint exits 0, PR is open"

Bad: open-ended

claude --loop "keep improving the auth module"
The budget flag. Claude Code supports max turn limits. Use them.

claude --max-turns 15 --goal "fix the failing tests in test/auth"
Fifteen turns at Haiku rates is basically super cheap. Fifteen turns at Sonnet with tool calls is still reasonable. Unlimited turns with a badly specified goal is how you end up explaining a bill to someone.

Can we put the $500 million API bill on the company credit card? Is that OK? I don't want to cause any waves or anything… Bruce in engineering says he is sorry.

The Robovac Digression (Which Is Actually About Architecture)

My robovac got me thinking; honestly, it’s the perfect test case for all of this. We keep cramming intelligence into devices that have exactly one job in the physical world. Clean the floor. Don’t eat the charging cable. Go home before the battery dies, without bumping into the chair legs.

But every device hacker looks at that humble spinning disc and thinks, "What if it also had intelligence and a GPU?" What if it knew the weather, played your morning playlist, and helped you with movie trivia in the TV lounge room?

That's how you end up with a household appliance that needs its own token maxxing limits, a system prompt, a SKILL.md, and a therapy session when you rearrange the living room.

But here’s the thing — a robovac is actually a perfect minimal loop. It has all six parts already, just implemented into custom firmware:

Automation: scheduled clean at 7pm, or triggered by event (you left the house)
Worktrees: doesn’t try to clean two rooms simultaneously (collision avoidance)
Skills: map of your floor, no-go zones, the spot under the couch it learned the hard way
Connectors: dock charger, app notifications, voice assistant integration
Sub-agents: the part that navigates and the part that decides when it’s done
State: the map. The map is everything.
The architecture of a good robovac is the architecture of a good loop. One does it in 50MB of Linux firmware. The other does it in your .claude/ folder. Same bones.

The actual robovac AI opportunity, for whoever wants it: tiny local model for intent parsing (“clean the kitchen after dinner”), deterministic command layer for safety, existing firmware for motion. Don’t overthink it. The AI is not the vacuum.

The Robovac is the future existential crisis support chatbot, just like Michael Reeves early iteration of the swearing roomba:

https://www.youtube.com/watch?v=mvz3LRK263E

8. What The Loop Can’t Do For You

The loop changes the work. It doesn’t delete you from it. And three problems get sharper as the loop gets better.

Verification is still yours. A loop running unattended is also a loop making mistakes unattended. “Done” is a claim, not a proof. The verifier sub-agent helps, but it doesn’t replace you reading what landed in the repo. Your job is to ship code you confirmed works, not code the loop says works.

Comprehension debt compounds. The faster the loop ships code you didn’t write, the wider the gap between what exists and what you actually understand. A smooth loop accelerates that gap unless you stay engaged with what it’s producing. Read the PRs. Understand the changes. The loop is a multiplier on your engineering judgment, not a replacement for it.

Cognitive surrender is the comfortable failure mode. Two people can build the exact same loop and get completely opposite outcomes. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn’t know the difference. You do.

HITL for life: Design the loop like someone who intends to stay the engineer.

One Last Thing: Prompting Isn’t Dead, It’s just not cool anymore
The prompt is still the steering wheel. It’s just not the whole engine.

If your system already knows the codebase, remembers your conventions, and can inspect its own output, the prompt becomes a short instruction to a system that already knows what to do with it. Context engineering, skill files, agent loops, persistent state: these are what replaced the long incantation.

The tech industry is trying to sound 17% more post-uber-human than the next person. Token-maxxing. Microflex mind hacks via dubious mail-order peptide injections. “93% productivity improvement” posts with no receipts. The social flex posts will keep peacocking and evolving. The receipts matter more than the claims.

The ideas here are simple: a loop that runs while you sleep, finds real work, does it reasonably well, escalates the parts it can’t handle, and leaves a state file you can actually read in the morning.

That’s it. Not a "shut up and take my money" for a deposit on a Neuralink implant chip. Just a .claude/ folder, a few skill files, a state markdown, and a cron trigger.

All hail the /loop. Stay the engineer. And stop explaining your project from scratch to an AI that could have just looped it.

Here are all the useful slash commands for Claude Code
Accurate current list based on the June 2026 reference:

Setup & Config
/init - creates CLAUDE.md project instructions file
/config - open settings
/model - switch model (press s for this session only)
/effort [low|medium|high|xhigh|max|auto] - controls reasoning depth
/permissions - view/manage tool permissions
/doctor - run diagnostics, press f to auto-fix issues
/terminal-setup - configure terminal integration
/hooks - manage hook scripts
/keybindings - customize shortcuts
/sandbox - sandbox controls
/memory - edit CLAUDE.md memory files (may not be available in all environments)
/fast [on|off] - toggle fast mode on supported Opus models
/color - change session accent colour

Context & Sessions
/clear - wipe conversation history
/compact - compress history, keep going
/context - show what's in context
/resume - resume a previous session
/cd - change working directory
/add-dir - add another directory to scope

Code & Review
/review - code review
/code-review - detailed code review
/security-review - security-focused review
/diff - show git diff
/debug - enable debug mode
/plan - plan mode, explains before executing

MCP & Plugins
/mcp - list MCP servers and status
/mcp_[server]_[prompt] - call a specific MCP prompt directly
/plugin - manage plugins
/skills - list available skills
/reload-skills - reload skill files without restarting
/reload-plugins - reload plugins

GitHub & PRs
/install-github-app - install GitHub integration
/pr-comments - fetch and display PR comments
/ultrareview - deep PR review mode

Agents & Background
/agents - manage background agents
/workflows - manage workflows

Usage & Cost
/cost - token usage and cost for session
/usage - full usage breakdown
/stats - session stats
/usage-credits - check remaining credits

Other
/status - session status
/help - full command list (best starting point)
/release-notes - what changed in current version
/team-onboarding - generate a teammate ramp-up guide from your usage
/output-style - change response formatting
/login / /logout - auth

Published on @vektormemory — VEKTOR Memory is a local-first AI agent memory SDK. If your loop could use persistent memory that doesn’t phone home, check it out at vektormemory.com.

LLM
Anthropic Claude
Prompt Engineering
Claude Code

79% on LongMemEval: How We Beat Full-Context GPT-4 with a Local SQLite Database

Vektor Memory — Fri, 12 Jun 2026 06:29:59 +0000

A benchmark result that changes what we thought was possible for local persistent agent vector memory

We ran VEKTOR Slipstream against LongMemEval this week and got a result we were very impressed with.

79.0%. That is 12 points above full-context GPT-4.

To understand why that number matters, you need to understand what LongMemEval is actually testing, why it is hard, and what it took to get there.

What LongMemEval Is and Why It Is the Hardest Memory Benchmark
Memory benchmarks operate on different testing question criteria.

They test whether your system can retrieve a fact that was stored recently, in a clean format, with an obvious query. That is approximately what happens in a controlled demo. It is not what happens in production.

LongMemEval is slightly different. It was designed specifically to stress-test the failure modes of real memory systems over real conversations. The benchmark contains 500 questions drawn from genuine multi-session chat histories, with an average of 344 memory items per question. The questions are distributed across seven categories, each targeting a specific failure mode:

Single-session retrieval tests whether you can answer a question from a single conversation correctly. Sounds easy. The catch is that the answer is buried in a long session, surrounded by noise, and the query phrasing bears no resemblance to how the answer was stored.

Multi-session reasoning asks you to connect facts across conversations that happened at different times. “What did the user say about their job last month” requires knowing that those memories exist and linking them.

Temporal reasoning tests date-anchored facts. “Where was the user living when they started their new job?” requires understanding which memories belong to which time window.

Knowledge updates test whether your system correctly invalidates old facts. If a user says, “I moved to San Francisco" after previously saying, “I live in Los Angeles," the correct answer to "Where does the user live?” is San Francisco. Systems that append rather than supersede fail this category consistently.

Abstention tests whether your system knows when it does not know. Many systems hallucinate an answer rather than say “I don’t have that information.” Abstention at 90% means VEKTOR declined to answer when it lacked the information, nine times out of ten.

The baseline in this benchmark is brutal. Full-context GPT-4, where the entire conversation history is stuffed into the context window, scores 67%. That is the system where the model literally sees everything and has to do nothing intelligent with storage. VEKTOR, running on local SQLite, beat it by 12 points.

The Four Versions We Ran to Get Here

We did not start at 79%. We started at 48.6% and ran four iterations to understand what was failing and why.

v1 (48.6%) was a naive implementation: store every turn as raw memory and retrieve it by vector similarity. The immediate failure was obvious. Questions like "What did the user say about their sister’s wedding?” returned semantically similar memories about events, parties, and celebrations. Technically correct retrieval. Wrong answer.

v2 (57.1%) added BM25 keyword search fused with semantic search via Reciprocal Rank Fusion. This improved single-session recall significantly. Multi-session questions still failed because the system had no way to reason about when memories occurred relative to each other.

v3 (55.2%) was a step backward. We introduced aggressive deduplication and contradiction detection, which accidentally removed valid memories that looked similar but referred to different time periods. Lesson: deduplication needs temporal awareness, not just semantic similarity.

v4 (79.0%) introduced what we are calling routed ingest, and it is the architectural decision that drove the result.

Routed Ingest — The Strategy That Changed Everything

The core insight behind routed ingest is simple: different types of memories benefit from fundamentally different storage strategies.

Before this, every conversation turn was stored the same way. Raw text, embedded, inserted. The problem is that “I moved to San Francisco last Tuesday” and “I prefer dark mode” and “the payment API went live yesterday” are three completely different types of information. Treating them identically is why most memory systems plateau in the 55 to 65% range.

Routed ingest assigns each memory to one of two pipelines at write time:

Extraction pipeline for complex, cross-session, time-sensitive information. The raw turn is sent to an LLM with a structured prompt that extracts discrete factual statements. “Sarah moved to San Francisco in March 2026.” “The user’s sister got married on 14 June.” “Project X launched on 3 April.” These extracted facts are stored as clean, independently queryable memories with resolved dates, named entities, and explicit subjects.

Raw storage for single-session conversational turns, preference statements, and questions where the original phrasing is the important artifact. These go in as-is because they do not benefit from transformation, as it introduces errors.

The routing decision is made by classifying the question type:

Temporal reasoning → extraction pipeline
Multi-session → extraction pipeline

Knowledge updates → extraction pipeline
Single-session → raw storage
Abstention questions → raw storage
The benchmark results by type tell the story directly:

temporal-reasoning 100.0% (15/15)
single-session-assistant 86.7% (13/15)
single-session-user 80.0% (16/20)
multi-session 75.0% (15/20)
abstention 90.0% (9/10)
knowledge-update 66.7% (10/15)
single-session-preference 50.0% (5/10)

Temporal reasoning at 100% is the most striking number. Every single date-anchored question was answered correctly. That is because extracted facts carry explicit date context that survives across sessions, and the temporal index can be retrieved by date range rather than relying on semantic similarity alone.

Multi-session at 75% with a 30-point improvement over v3 confirms that extraction is the right strategy for cross-session reasoning. The extracted facts give the system discrete, searchable statements rather than walls of conversation text.

What Full-Context GPT-4 Cannot Do That We Can

The comparison that surprises people most is beating full-context GPT-4 by 12 points.

Full-context GPT-4 on this benchmark means every conversation in the history is concatenated into a single massive prompt, and GPT-4 answers the question with the entire history visible. No retrieval. No selection. Just read everything and answer.

That approach has a hard ceiling, and it is lower than you might expect.

First, the context window fills up. GPT-4’s context limit means that very long histories get truncated. Information from older sessions simply disappears.

Second, and more interesting, is the attention problem. LLMs do not read a 200,000 token context the way a human reads a document. Attention is not uniformly distributed. Facts buried in the middle of a long context are systematically underweighted relative to facts at the beginning or end. The “lost in the middle” phenomenon is well documented in the research literature and measurable in benchmark performance.

Third, there is no disambiguation. When the same name appears in multiple contexts with different associated facts, the model struggles to track which fact belongs to which temporal context. Everything is simultaneous rather than sequenced.

VEKTOR’s temporal index solves this directly. Memories are stored with explicit date anchors, indexed by a dedicated timeline table, and retrieved with date-range filtering. The question "Where was Sarah living when she started her new job in March?” can be answered by retrieving memories tagged to March rather than scanning the entire history and hoping attention lands on the right passage.

The Architecture Behind the Numbers

Three components drove the benchmark result. They are all in the open SDK and available to anyone building on VEKTOR.

vektor_timeline is a secondary SQLite table that indexes every memory with an extracted ISO date. When a question contains temporal markers, the retrieval pipeline boosts memories from the relevant date range before running semantic search. This is why temporal reasoning hit 100%.

BM25 + RRF dual-channel recall fuses keyword search with semantic search using Reciprocal Rank Fusion. The two channels find different memories. Semantic search finds conceptually similar content. BM25 finds memories containing specific names, dates, and technical terms that do not have obvious semantic neighbors. RRF blends the rankings without requiring a learned fusion model. This is why proper noun recall improved dramatically from v1 to v2.

Entity indexing extracts named entities from every stored memory and builds a secondary index. Queries containing proper names use entity lookup to retrieve memories associated with that person, place, or project, then expand through graph edges to related memories. This is the pathfinding layer that handles the "What language does Sarah use?” class of question.

The full recall pipeline runs in this order for every query:

Classify question type (temporal / multi-session / single-session / adversarial)
Embed query vector
Semantic candidate retrieval (top 60 from 2000 recent memories)
Timeline boost if temporal markers detected
BM25 keyword search, stem table search
Entity lookup and graph traversal
RRF fusion across all channels
Layer 6 additive reranking (importance + strength + causal weight)
Return top K The whole pipeline runs on a local SQLite database. No API calls. No cloud infrastructure. No vector database cloud service or embedding costs. The latency is under 20ms on a laptop.

The two categories that need work.

Knowledge updates at 66.7% is the most interesting; this category tests whether the system correctly answers questions about facts that changed over time. “The user used to live in Los Angeles but moved to San Francisco. Where do they live?” The correct answer requires not only retrieving the more recent memory but also understanding that it supersedes the earlier one.

Our contradiction detection handles this well when the two facts are stored close together and share clear semantic overlap. It struggles when the update is phrased differently from the original or arrives in a different session context. The AUDN loop detects the contradiction but sometimes downgrades both memories rather than cleanly invalidating the older one. We need a harder supersession model, probably one that extracts a canonical attribute (location, job title, or relationship status) and explicitly marks all previous values for that attribute as expired.

Single-session-preference at 50% is trickier. Preference statements like “I prefer dark mode” or “I like concise responses” are stored correctly but recalled unreliably because they are low-importance, short, and semantically flat. They do not activate many recall channels. The fix is a dedicated preference namespace with its own retrieval path, bypassing importance scoring and prioritizing recency and specificity.

Both weaknesses are fixable. The architectural interventions are clear. This is what a benchmark is for.

What This Means for Anyone Building AI Agents

The headline number is 79%. The practical implication is more specific than that.

If you are building an agent that needs to remember things across sessions, you have a few architectural options. You can use full-context injection, which does not scale and has a ceiling around 67% on this benchmark. You can use a vector database with naive retrieval, which plateaus around 55 to 62%. Or you can use an intelligent memory system with routed ingest, temporal indexing, and multi-channel recall.

The gap between those options is not marginal. It is the difference between an agent that answers “where was Sarah living when she started her new job?” correctly and one that either hallucinates or says it does not know.

For production applications, especially in domains like personal assistants, customer service agents, research tools, and coding assistants, the quality of memory retrieval is directly proportional to user trust. Users notice when an agent forgets things. They notice when it contradicts itself. They notice when it cannot connect two facts they told it in the same week.

The benchmark says VEKTOR handles 79% of these cases correctly. The failure cases are known, the interventions are clear, and the architecture is local-first with no cloud dependency.

Next Steps and What We Are Building Toward

The two weaker categories give us a concrete roadmap for further testing on v5.

Knowledge updates need a supersession model that tracks canonical attributes per entity and explicitly expires stale values. The data model is straightforward: every memory gets an attribute type tag at extraction time, and any new memory with the same attribute type for the same entity triggers invalidation of older values.

Preference recall needs a dedicated lightweight pathway that does not compete with importance-weighted retrieval. Preferences should not be ranked against architectural decisions or deployment failures. They should be in their own bucket, retrieved in full when the session starts.

Beyond the immediate fixes, the routed ingest strategy opens up a broader architectural direction. Once you are classifying memories at write time, you can route them to specialized indexes rather than a single general-purpose vector store. Temporal facts to a timeline index. Entity facts to an entity graph. Procedural knowledge to a task index. The benchmark shows that specialization beats generalization significantly.

VEKTOR v1.7.2 is completing testing for future release with the architecture that produced this current result, and 1.6.3 is already live now. The SDK is local-first and available at vektormemory.com.

VEKTOR Slipstream is a local-first persistent memory SDK for AI agents. No cloud required. vektormemory.com

Sqlite
Vector Database
Longmemeval
Vector Memory

Your vector memory database remembers everything. That’s exactly the issue.

Vektor Memory — Thu, 11 Jun 2026 00:11:46 +0000

There is a design assumption baked into almost every vector database and AI memory implementation that sounds reasonable until you watch it grow nodes in production: that remembering more is always better.

Through testing and refining our AUDN code, that is not exactly correct.

After running VEKTOR Slipstream against real development sessions for 99 days, the database held 1,413 stored memories across four namespaces. Looking at the importance score distribution, 83 percent of those memories sat below 0.25 out of 1.0, what the system considers the noise floor. The remaining 17 percent, just 60 memories out of 1,413, sat above 0.75 and dominated every recall result.

This is exactly what a curation layer is supposed to produce.

Those 1,154 low-scored memories are accurate. They are not deleted. They are retrievable by direct query. What they are not is important enough to compete with the 60 high-signal entries every time the agent needs context.

AUDN penalised them gradually over hundreds of writes because similar, more specific, or more frequently reinforced memories covered the same ground better. The system created a hierarchy. Without curation, all 1,413 memories would compete equally for every recall slot — and the agent would consistently surface redundant, lower-value context alongside the things that actually matter.

That is what standard vector memory looks like without a curation layer. A slow, invisible degradation that nobody notices until the agent starts confidently giving you answers that are three months out of date.

Every memory node in Vektor carries an importance score between 0 & 1.

When a memory is first stored, it receives a score based on the content’s estimated significance. That score is not fixed. Every time a new memory arrives that is semantically related but not directly contradictory, the compatible verdict for that existing memory takes a small redundancy penalty.

The penalty is intentionally modest: a factor based on how similar the incoming content is, typically reducing the score by 10 to 15 percent per occurrence. But across hundreds of sessions, the effect compounds. A memory about project tooling that gets reinforced by similar writes across a dozen conversations will have its score driven down steadily until it sits below the noise floor threshold where it no longer competes in active recall.

The noise floor is not a bin for broken or wrong memories. It is where memories go when the system has determined they are not the most important version of what they represent.

They are still stored and still retrievable by direct query. They stop dominating recall alongside the 60 high-signal entries that floated to the top of the distribution. This is the intended behavior: a natural hierarchy where what matters most surfaces first, and everything else remains available without contributing noise to every retrieval.

The Mechanism Nobody Talks About

Vector databases are extraordinarily good at one thing: storing info and finding information that is semantically similar to other things. That is genuinely useful but is not the best method currently available.

When a user tells your agent “I work in finance” in January, and “I left banking last month” in April, a vector store dutifully records both facts.

The embeddings sit close together in the vector space because they are about the same topic. When you query for professional context in May, you get both back. The agent receives two conflicting truths with no metadata to tell it which one is current, and it does what language models do when given ambiguous context: it synthesises a plausible-sounding answer that may or may not reflect reality.

This is not a retrieval problem. You cannot fix it at recall time by adding better filters or smarter reranking, because by the time you are querying, the contradiction is already in the graph and competing for attention. The only place to fix it is at the write layer, before the conflicting fact is committed.

This is the insight that drove the architecture of the AUDN gate. Belwo is a real production at work, semantic, causal, temporal, and entity nodes in formation.

(Production graph, temporal nodes only)

What a Write-Layer Curation Gate Actually Does

AUDN runs synchronously on every single memory write before anything touches the database. Every incoming piece of information is compared against the 200 most recent active memories using cosine similarity, which is a pure SQLite operation that completes in under two milliseconds. If nothing similar exists, the memory is committed immediately as a fresh addition. If something similar does exist at a cosine score above 0.72, the gate sends the pair to an LLM for classification.

The LLM used for this test run is the Groq llama3–8b-8192. It is fast, has generous free tier limits, and is accurate at the kind of binary classification this requires.

To keep API costs and rate limits manageable, pairs are batched: up to ten candidate pairs are classified in a single call. If the LLM is unavailable for any reason, AUDN falls back to a heuristic where similarity above 0.95 becomes a no-operation and everything else is treated as compatible. A write is never blocked. The fallback trades accuracy for availability, which is the correct tradeoff.

The classification is not binary. There are five possible verdicts, and each one produces a different action.

(Entity node advising: Supersession chain explicit edges — AUDN UPDATE)

Compatible means both facts are simultaneously true from different angles. The incoming memory is stored, but the existing memory takes a small redundancy penalty to its importance score. Over time this naturally surfaces the more specific, more frequently accessed, and more recent memories to the top of the priority stack.

Contradictory means the incoming fact directly conflicts with an existing one. The new fact wins, subject to one important condition: the trust matrix. If the incoming memory carries a trust score below 80 percent of the existing memory’s trust score, the verdict is downgraded to Compatible instead. A hedged conversational fragment cannot overwrite a verified session fact, regardless of semantic similarity. When a true contradiction is confirmed, the existing memory is suppressed using an exponential decay function over a 30-day window rather than being deleted outright.

Subsumes means the incoming fact is more general and logically contains the existing one. The existing memory is moved to cold storage, where it is archived but no longer competes in active recall.

Subsumed means the existing fact is more general and the incoming one adds nothing. The new memory is dropped entirely and the existing memory receives a small importance boost instead.

No-Op means the incoming fact is already known at high confidence. At cosine similarity above 0.95, the write is skipped and the existing memory’s access count increments. This is how the system handles the natural tendency to keep storing the same things: the second instance of a fact strengthens the first rather than creating a duplicate.

The 83 Percent Finding

Looking at the actual data from our live development database makes the shape of this problem visible in a way that abstract descriptions do not.

Of 1,413 active memories accumulated over 99 days, 1,154 carry an importance score between 0.10 and 0.25. These are memories that have been through the Compatible path multiple times, accumulating small redundancy penalties each time a related but non-contradictory memory was written nearby. None of them are wrong or contradictory.

They are simply less important than the 60 memories at the top of the importance distribution that have been reinforced, accessed repeatedly, and never penalised.

This is the intended outcome. A flat vector store treats every fact as equally important forever, which means retrieval quality degrades as the graph grows because signal and noise compete on equal terms. A curated graph creates a natural hierarchy where the most meaningful, most reinforced, most current facts rise to the top and everything else stays available but stops dominating recall.

The 60 high-signal memories in that database are session handover notes, confirmed architectural decisions, and key project facts that have been written and rewritten and accessed across dozens of sessions. They float. The rest sinks. Retrieval becomes faster and more accurate as the database grows rather than slower and noisier, which is the opposite of what happens in an uncurated vector store.

The Trust Matrix in Practice

Seventeen percent of the memories in that database carry a trust score below 0.7. These are predominantly extracted conversation fragments and inferred facts, stored automatically during session ingestion. The remaining 70 percent carry trust scores above 0.9, representing directly stored and confirmed information.

The trust guard exists because not all writes come from the same source. A user speaking casually in a conversation generates different quality information than an agent explicitly recording a confirmed decision.

When a low-trust fragment arrives with high semantic similarity to a high-trust existing memory, the Contradictory verdict is overridden. The system does not allow speculation to overwrite certainty, even when they are talking about the same thing.

This protects against a failure mode that is easy to trigger without the guard: an agent processing a stream of hedged, uncertain user statements gradually erodes its verified knowledge base because every “I think maybe” and “probably something like” crosses the similarity threshold and overwrites something solid.

Nothing Disappears Silently

Every AUDN decision is written to an audit log before the underlying action executes. The schema stores the action taken, the memory affected, a 500-character snapshot of the content at the time of decision, the reason the LLM gave for its classification, the cosine similarity score that triggered the call, and the timestamp. This means you can query the full decision history:

const decisions = await memory.auditLog({ action: 'CONTRADICTORY', since: '30d' });
// Returns each contradiction resolved in the last 30 days,
// including what was suppressed, what replaced it, and why.
The reason field is worth particular attention. When Groq classifies a pair as Contradictory, it returns a brief natural-language explanation alongside the verdict. That explanation is stored verbatim. You can surface it to users, use it to debug unexpected agent behaviour, or build explainability features on top of it. This turns what would otherwise be an opaque curation mechanism into something observable and trustworthy.

Cold-archived memories are also still retrievable via direct query. Nothing is permanently deleted. The lineage of how knowledge evolved is preserved. If you need to understand why the agent believes what it currently believes, you can trace the chain of decisions that got it there.

The Deeper Point

Most of the work on improving agent memory has focused on retrieval: better reranking, hybrid search, query expansion, context window management. These are genuinely useful improvements. They do not solve the underlying problem because the underlying problem is not about retrieval.

The problem is that vector memory, as typically implemented, is an append-only log. It grows indefinitely. It accumulates contradictions silently. It degrades in signal quality over time while appearing to grow in capability because the database keeps getting larger. By the time the degradation is visible in agent output quality, the problem is months old and deeply embedded in the graph.

The fix is not a better retrieval algorithm. It is a state machine at the write layer that maintains a consistent, curated, non-contradictory representation of what is currently known, with full lineage tracking for how that knowledge evolved.

After several months of node curation, your graph unfolds with deeper insights.

Vector memory that just stores things is a log. Vector memory with a curation gate is an epistemological layer. The difference shows up quietly at first, and then everywhere at once.

“The principle of LLM-arbitrated curation at the write layer is grounded in published research. The Mem0 paper (arXiv:2504.19413) demonstrated that structured memory management consistently outperforms append-only approaches across single-hop, temporal, multi-hop, and open-domain question categories on the LoCoMo benchmark.”

Yadav, Deshraj et al. “Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory.” arXiv:2504.19413 (April 2026).

Link: https://arxiv.org/abs/2504.19413

VEKTOR Slipstream ships AUDN as part of the core write path on every memory.remember() call. The audit log, trust matrix, cold storage, and five-verdict conflict resolution are all active by default. Documentation and source at vektormemory.com.

Audn
Vector Database
Llm Agent
Memory Management

The Capability Curve Has No Memory

Vektor Memory — Tue, 09 Jun 2026 22:14:42 +0000

And everyone keeps building anyway. What choice do we really have?

Anthropic urges coordinated pause on advanced AI development
They published a progress report by Marina Favaro and Jack Clark last week that I have not been able to stop thinking about, that AI systems are accelerating and could reach “recursive self-improvement,”
https://www.anthropic.com/institute/recursive-self-improvement

Not because of the headline numbers, though those are striking enough. Claude authored over 80% of the code merged into Anthropic’s own codebase, and so are other frontier companies now. Engineers are shipping eight times more output per quarter than they did two years ago. An agent completing tasks that would take a skilled human sixteen hours, working continuously, without being redirected once.

What got me was the graph showing lines of code per engineer over time. Flat for four years. Then a sharp bend upward in 2025 when Claude started running code rather than just suggesting it, the ouroboros, a binary Gödel machine feeding code back into itself. Then steeper again in 2026 when agents started working autonomously over longer horizons.

Since writing this piece, Anthropic released Fable 5

And 3 days later the pesky American government banned all foreign access already; nobody overseas can have any fun, it seems:

The U.S. government issued an emergency export control directive forcing Anthropic to suspend all foreign access to the Fable 5 and Mythos 5 artificial intelligence models. The abrupt ban, which was delivered under national security authorities, prohibits use by any foreign national globally, including Anthropic's own overseas employees.

Anthropics' response:

To date, the government has only given us verbal evidence of a potential narrow, non-universal jailbreak, which essentially consists of asking the model to read a specific codebase and fix any software flaws. Our understanding is that one potential jailbreak was shared with the government.
We have reviewed a report that we believe is the basis of the government's directive and validated that the level of capability displayed there is widely available from other models (including OpenAI's GPT-5.5), and is used every day by the defenders who keep systems safe. We will share more details over the next 24 hours.

Fable is their most capable model yet, available for general use in the U.S. Only for now. The numbers are striking: Stripe reported it compressed months of engineering into a single day on a 50-million-line codebase. Drug design running ten times faster. A week of autonomous genomics research producing results that outperformed a published paper in Science.

But the detail that stood out most was buried in the memory section of the announcement. When Anthropic gave Fable 5 access to persistent file-based notes while playing a game, performance improved three times more than it did for their previous model.

The same capability jump, amplified dramatically by memory. Anthropic built that test into their own product launch because they already know what the data shows: the more capable the model, the more it benefits from structured state across time. The capability curve and the memory curve are not independent. They compound each other, and right now only one of them is being invested in at scale.

And stop building!

But I don’t think anyone will, even at Anthropic's request; technology is like an organism; it just keeps evolving.

Smart cookies, Anthropic. In just a few years they managed to get the moola, 1 trillion, in fact. Purchase the missing puzzle pieces of infrastructure like Vercept, Bun, Coefficient Biohealth, Fractional AI, and Stainless, the SDK experts, for whom Anthropic was one of their largest clients, makes sense symbiotically and strategically, well played.

I don’t know everything going on inside Anthropic, but Dario and his team are starting to look like 4D chess grand masters.

I looked at that graph and felt two things at the same time. Genuinely impressed. I really like Anthropic, and, if I’m honest, I'm a little concerned.

The concentration of control: pretty much all of the brains and infrastructure in AI will be consolidated into a handful of Silicon Valley tech companies, reminiscent of the 80's when Microsoft made deals with all the hardware manufacturers so Windows was the only licensed OS allowed. That's why Linux was smart to pivot to servers and retained 60% of market share to this day, Ubuntu is great; it works and very rarely has any reliability issues, along with Red Hat and Debian.

The Inflection Point Nobody Has a Map For

Here is what I think is actually happening and why the idea is more rational rather than alarmist.

We are approaching a threshold. Not gradually, but in the way the frog in hot water approaches boiling with nothing much visible, then everything all at once. An agent can reliably replicate its own development cycle and sustain above 90% code accuracy on open-ended tasks, the nature of human work does not just change. It restructures from the ground up; it amplifies and compounds.

The Anthropic article is careful to frame this as a positive development, and they are not wrong. More code shipped faster, bugs caught before production, research that would have taken humans months to years was completed in weeks. Real gains for real problems.

But here is what it means on the ground for the people doing the work. The volume of what needs to get done does not decrease. It multiplies. What changes is the type of work. Manual execution gives way to high-level direction. Writing code gives way to reviewing it, shaping it, and deciding what strategic problems it should be solving. The human role becomes a layer of high-level authorisation above an autonomous system that is already capable of most of the execution.

That is not less work; it is a more complex job, more cerebral, and also requires multidisciplinary experience and deep problem-solving detective skills. Ten times the output means ten times the decisions, ten times the context to hold, and ten times the responsibility for what ships correctly; that's the compounding effect.

And agentic bots are going to do all of this for us, some already are.

Being the head of HITL is not easy; stuff moves so quickly. Did you read 20 pages of code from 20 different projects and text instantly on your mobile phone and approve all of them?

You Already Need to Know 100 Things

I feel this shift personally, and I feel it constantly.

Building VEKTOR as a solo developer means I am a developer, a product manager, a security engineer, a devops engineer, a content writer, a growth person, a customer support function, and a business owner, all at once.

AI has made each of those roles individually more accessible and even feasible. It has also made it technically possible to run all of them simultaneously in a way that was not realistic before, via delegation. If you go back in time, I remember we had 5 systems at work: Oracle Unix green screen (it never crashed once), which was fast but needed mental repetition to learn; one database; Outlook; Intranet; then Salesforce came along and 20 other apps bolted on.

The result is not fewer tasks. It is more complicated work, spread across more domains and more systems with API’s, M2FA logins with higher stakes at each one.

Even humans can't work this captcha out, agentic bots are going to need a standardized system to traverse the internet without getting blocked.

And yes, the biggest brains are working on this problem right now. Solving multiple agentic bot layers with credentialed passports.

Whoever thought of this captcha idea above needs to be spanked immediately.

This week I was mid-session debugging a certbot renewal failure on the VPS when it became clear the issue was a credentials format mismatch between an old apt-installed certbot version and a Cloudflare API token that expected a newer format. The fix required understanding the snap package ecosystem, the certbot renewal hook architecture, and the Cloudflare API token permission model, all at the same time.

Claude who handled it flawlessly by logging into the VPS via Vektor Cloak SSH tools, and worked through all of it in 5 mins. I didn't really do anything but authorise and ask a few questions on how we can fix it for good, as I was working on other issues in another web browser.

Without Claude, I would have lost a few hours manually running cert checks in Ubuntu and scratching my head.

But here is the thing: Claude did not know any of that context when the session started. I had to authorize the skill file, which has all the system commands to access the VPS. What the cert structure issue looked like. The intelligence was there to diagnose and fix quickly once known. The memory of the prior work was not yet fully formed, so another memory node was added to save time in the future.

That gap is not a minor inconvenience. At the pace we are now expected to operate, losing context between sessions is structurally expensive. It is a heck of a lot better than what it was 6 months to a year ago, that's for sure.

It is getting to a point where my prompts are just caveman-like, as the Vektor memory graph and skill files are so dense with info that Claude knows everything; very rarely do you have to explain anything in great detail, saving effort.

The Todo List That Taught Me Something

A few days ago I asked Claude to help me build a proper to-do list.

Standard Claude behavior followed. Within a few exchanges there was a proposed graphical interface, charts, colour coding by priority, a dashboard with status indicators. Genuinely impressive in its way. Also completely wrong for what I needed.

I told him: text-based list only. He complied immediately, without argument. Produced exactly what I asked for.

That small interaction has stayed with me because it captures something important about where we actually are. The capability is extraordinary. The judgment about what is appropriate for a given context is not yet reliable.

The human in the loop is not just there to authorise, we are there to calibrate. To say: not a dashboard, a list. Not sixteen layers of abstraction, one flat file. Not the most impressive Kanban board solution, the right one for the moment.

That calibration role is real and valuable. But it requires the human to maintain a clear head about what they actually want, which is harder than it sounds when the agent is confidently generating impressive-looking shiny output at speed.

The Things AI Still Cannot Remember

The hardest part of being a developer right now is not writing code. The code is, increasingly, becoming the easy part.

The hard part is remembering everything that needs to get done and when.

The VPS certificates that expire in 27 days. The mobile app submission that is sitting at step four of nine waiting for a policy acknowledgement. The three emails from Google Play that each require a checkbox response and a reupload and then a wait and then another adjustment. Google has now become more bureaucratic than the government. The dependency that needs updating before the next release. The blog post half-written. The changelog not updated. The analytics tag still pointing at the wrong domain.

None of that is difficult work. All of it requires context, continuity, and memory across time. And that is precisely what current AI systems do not have in a structured form.

I built Vektor partly because I kept running into this problem in my own work. Not the capability gap — the memory gap. The agent could help me fix the certbot issue, but it could not remember that we had looked at this same problem six weeks ago and had taken a different approach that turned out to be wrong. It could not connect the current error to the prior attempt or workout it out. Or how to get back into the VPS folder structure to view it; it could not carry forward the context that makes accumulated work compound rather than reset.

That is what persistent memory architecture is actually for. Not impressing people with recall of trivia from earlier conversations. Enabling agents to do work that compounds across time the way a human engineer’s experience does. Building the institutional knowledge layer that makes the difference between an agent that is capable and an agent that actually learns.

There are going to be many new issues, but once resolved, you don't want to have to repeat yourself; that is the metric that needs calculating: accuracy of past/present task recall.

What the Graphs Do Not Show

The Anthropic charts are impressive. The productivity curves bending upward. The benchmark saturations. The task horizon doubling every few months.

What those charts do not show is what is happening inside the agents doing the work. They show output. They do not show whether the system is building structured knowledge of its own history, or whether each session is still starting cold and rediscovering the same territory.

A dozen agents that can work for 24 hours but forget everything at the end of the session are not a self-improving system. The difference matters enormously once you are thinking about what recursive self-improvement actually means in practice.

For that loop to close properly, for AI development of AI systems to genuinely compound rather than just accelerate, the memory architecture has to be as solid as the capability architecture. The causal record of what was tried and why. The structured knowledge of what failed and under what conditions. The accumulated context that lets the next session start from where the last one ended rather than from zero.

That is the infrastructure problem that needs solving in parallel with the capability problem. And it is, right now, significantly underdeveloped relative to the capability curve that Anthropic’s graphs describe.

On Being Concerned and Building Anyway

I want to return to the realisation for a moment, because I do not think it should be dismissed.

The concern is not that AI will become capable. It already is. The pace of restructuring that follows from that capability, and whether the humans doing the work have enough time and support to adapt to roles that are genuinely different from the ones they trained for.

The shift toward high-level direction and authorisation work is real, but it is not a gentle transition. It happens fast, it is not evenly distributed, and the skills it requires—broad theoretical knowledge, clear communication of intent, calibration of agent output, and strategic decision-making across many domains simultaneously, are not skills that most people have been explicitly developing.

I feel the gap in my own work every day. Not in my ability to use the tools, but in the cognitive load of operating across so many domains at once while maintaining the judgment to know when the impressive output is the right output and when it needs to be deflated to a plain text list.

That cognitive load is going to increase, not decrease, as the capability curve steepens.

The answer is not to slow the curve. That is neither possible nor, honestly, desirable. The gains are real. The work being done is genuinely good.

The answer is to build the infrastructure, the ability to traverse across memory, context, continuity, and structured knowledge—that makes the human direction layer sustainable rather than overwhelming. To make the authorisation work tractable rather than a firehose of decisions without adequate context.

That is what I am building toward. Not because the problem is solved, but because I can see clearly that it is the right problem to be working on.

The graphs are impressive. The gap they do not show is who is going to maintain 200 agentic bot decisions across 200 different API-connected systems every hour on cron autopilot mode and still manage to have lunch.

I guess we all could have more pressing issues to worry about when that finally happens.

I'm going out to lunch; Claude, you run the show and make good decisions.

Made by the developer behind VEKTOR Slipstream, a local-first persistent memory SDK for AI agents. It runs on SQLite, recalls in 8ms, and ships with a 4-layer causal graph architecture. vektormemory.com

Llm Agent
Anthropic Claude
Ai Memory
Machine Learning

Memories of the Past, Cyberpunk Nostalgia, and AI Slop

Vektor Memory — Sun, 07 Jun 2026 03:55:25 +0000

Writing this article began organically. Which is a funny thing to even have to say in 2026. Consider what happens when you give a developer two days off, unlimited internet archive access, and too many ideas crammed into one article.

What does organic even mean now?

I did not write this on a mechanical typewriter.

I wrote it on a PC with my stubby index fingers running Windows software that, miraculously, does not blue screen every ten minutes anymore. It only took Microsoft thirty years to pull that off.

To the left sits an analog record player with some secondhand Yamaha bookshelf speakers I found at a charity shop; to the right of me sits a modern dark wood-paneled Zen PC case, a processor that would have occupied an entire room thirty years ago, and a GPU that can synthesize gargantuan piles of AI slop or brilliant code in roughly ten seconds flat.

And yet, for all that raw power, it still comes down to an algorithm. It always has.

The Sharper Image and the Death of Wonder

When I was a kid I used to walk into The Sharper Image store at Faneuil Hall Marketplace in Boston and just stand there. Looking at technology I could not afford while the staff watched me carefully to make sure I did not break anything.

I also grabbed some brightly colored rock salt candy; I loved that stuff, some core memories right there.

That feeling of picking up a piece of technology and not quite knowing what it did, like a ten-year-old ape holding something from another civilisation, you cannot replicate that in a sterile Apple store. The technology is better now. Genuinely better. Faster, smaller, more capable than anything those shelves held. But the sense of wonder at the unknowable object is completely gone.

Everything is explained before you touch it. Every product has a thirty-second video, a Reddit thread, a YouTube teardown, a comparison article, a spec sheet, and six AI-generated summaries of what other people thought about it. The mystery has been optimised out of the experience.

I did not know it at the time, but that shop was one of the last places where a kid could walk in and feel genuinely tactile wonderment about the future. Confused in a good way. The way that makes you want to figure things out via curiosity; they eventually went bankrupt and resurfaced as an online-only store.

That feeling is what I keep chasing when I go back into the archive, or when searching for used records, that rush you feel of finding something illusive and rare amongst a pile of James Last Trumpet a gogo records, man that German bandleader sold some records back in the 70's.

I once found a rare copy of Philip K. Dick's short story compilation, but it was in French. Absolutely gutted… how did that even end up halfway around the world in a charity shop in the suburbs? What a journey it went through.

Mondo 2000 and the Magazine That Dreamed Too Hard

Which leads me to Mondo 2000.

Mondo 2000 was a glossy cyberculture magazine published out of Berkeley, California, through the 1980s and 1990s. It covered cyberpunk topics: virtual reality, smart drugs “noots”, the coming digital revolution. It was a more anarchic and subversive prototype for the later-founded Wired.

Wired won commercially. Mondo had more cyber soul.

It started as High Frontiers in 1984, edited by R.U. Sirius, the pseudonym of Ken Goffman. It became Reality Hackers in 1988, then Mondo 2000 in 1989. It ran 17 issues and folded in 1998. In its tear through the early 1990s, Mondo brought an anarchic, drug-addled sensibility to the geeky world of computers, drawing a wiggly line from gonzo rock journalism to novelty-chasing tech speculation.

Wired reads, by comparison, like the operating manual for an IBM mainframe. That is not an insult to Wired. Wired won because it was legible to more people. But Mondo felt like it was made by people who were genuinely strange, genuinely excited, and genuinely unsure how things were going to turn out.

That experimental uncertainty was the best part. And they didn't waste 80 billion dollars on a Metaverse attempt. Cyberspace…

When I was a kid I mostly went to the back pages and read all the small ads. Strange devices. Gadgets I could not identify. Things that promised to change the way your brain worked. The joy was not in understanding any of it. The joy was in the sense that there was a whole dimension of reality operating outside the things people talked about in school, and somebody somewhere was living in it right now, more than likely in San Francisco, a hippie and tech soup.

*You can still read the full archive: *

https://archive.org/details/Mondo.2000.Issue.01.1989/page/106/mode/2up?q=cyberpunk

I have been thinking about doing a Vault series updating those old articles. Taking what Mondo predicted and comparing it to where we actually landed.

If only there were enough interest in nostaligia.

Scarcity Made It Matter

What made those magazines special was scarcity. There were not many magazines about any topic. A few for technology. Two for skateboards. One for surfing. One for electronics. People had to wait. They came out once a month. You had to order them by mail or physically go down to a newsagent and pick them up.

Or, if you were a teenager with no money, you stood in the shop and read as much as you could before the owner sneakily appeared from behind you and said:

This isn't a library, kid, are you buying it?

Limited editions were the holy grail.

We still have those same sources now, just a thousand times more of them. And somehow people are still not happy. They did not want the quantity. They wanted the magic of human-created personalisation. The sense that somebody made this specific thing for a specific kind of person, and you happened to be that person, a collective of like minds.

That feeling is almost impossible to manufacture at scale. Which is why so much of what gets published now, regardless of how it was made, does not produce it or comes out of China; sorry, designed in California…

Spell Check Is AI. It Always Has Been.

People rarely think of spell check as artificial intelligence, but that is exactly what it is. It just arrived early enough that nobody held street protests about it. There were no heated forum threads about the death of authentic writing when Microsoft Word started underlining words in red.

I wanted to track down the actual history, and this time I went the old-fashioned way. No AI assistant. Just Google, Wikipedia, and thirty minutes I will not get back. Normally I use AI for research because it is faster and usually goes deeper, but there was something fitting about doing it by index finger or mouse click for this particular article, most of it anyway.

The first spelling checker was created at MIT in 1961 by Les Earnest, using a list of the 10,000 most common English words. That was the whole database. The program could tell you that something was wrong, but it could not tell you what to do about it.

In February 1971, Ralph Gorin, a graduate student under Earnest, created the first true spelling checker as an applications program for general English text. He called it SPELL, and it ran on a DEC PDP-10 at Stanford University’s Artificial Intelligence Laboratory.

Gorin wrote it in assembly language for speed, and built the first real spelling corrector by searching the word list for plausible corrections that differed by a single letter or adjacent letter transposition.

He made it publicly accessible. It spread around the world via the ARPAnet, about ten years before personal computers came into general use. By the late 1970s, spell checkers had become standard on mainframes at universities and large corporations. By 1980, programs like WordCheck existed for Commodore systems. Word 95 brought the familiar red squiggle into millions of homes and nobody wrote a single angry forum post about it.

The first iterations were verifiers, not correctors. They highlighted mistakes but offered no suggestions for fixing them. The hard problem was not finding the error. It was suggesting the right fix. That required something more sophisticated.

The solution is called Levenshtein distance, named after Soviet mathematician Vladimir Levenshtein who described it in 1965. The idea is simple and straightforward: measure how many single-character edits it takes to turn one word into another. Deletion, insertion, substitution. Type “hte” and the spell checker computes how far that is from every word in its dictionary. “the” wins. “hat” does not.

Here is the dynamic programming version in JavaScript, because at some point every technical detour ends with the same question: do you want this in your stack?

This is an early form of artificial intelligence. The same as Photoshop’s first tools that allowed image manipulation. Nobody raged about those either.

I had to dig deep into the archives to find when humans started complaining specifically about AI, because there were many earlier iterations of the same anxiety: writing to printing press, camera to painting, photos to Photoshop. The shape of the argument never changes. Only the technology does.

Great visual explainer of how Levenshtein works if you want to see it animated: https://www.youtube.com/watch?v=d-Eq6x1yssU

What People Are Actually Loathing

When I try to distil what actually bothers people about AI in 2026, I keep arriving at the same four things.

Lack of Jobs.

Authentic Creativity

Loss of being human.

Connection.

The first three are obvious enough. If a tool can do part of your work faster and cheaper, people will worry about what that means for their role, their income, and their relevance. That anxiety is not irrational.

The fourth one is the most interesting to me.

Most humans, most of the time, want to interact with other humans. Not because human content is always better, it often is not. But because when you add another layer of binary transformer magic in between, it dilutes something. It creates skepticism. It degrades the connection while it speeds up the productivity. The message arrives faster but with less of a person inside it. You can feel it even when you cannot prove it.

To the Archive!

I could have done this old-school manual way by scrolling endlessly through search results.

Instead I ran a small experiment with modern cutting-edge tools, two different methods of reading the same archive. One was a standard web fetch tool built into Claude. The other was Cloak Fetch, a stealth browser tool from Vektor Memory that approaches the web the way a human would, bypassing the layers that block automated requests. Same question, same archives, different answers.

What made it interesting is that both tools found two different answers.

Cloak stealth browser crawling comp.ai Usenet threads surfaced a December 1989 post titled “STRONG AND WEAK AI”, a researcher named Mike Coffin complaining that AI-simulated worlds were “very unlike any type of perceptual reality.” Technical frustration, not moral panic. The same search run through standard Claude web fetch tool surfaced something older and stranger: a 1991 post by Mauro Cicognini arguing that artificial intelligence would never surpass human intelligence, and that the correct counter-argument was reproduction; training a human being would “always be less expensive.” He was not entirely wrong about the economics.

I found it strange and interesting how to modern search tools using the same database could produce such different results with the same prompt…

Also, a sobering lesson to not say things on the internet you may regret, as they stay up there forever.

Go back further and the anxiety predates the internet entirely. Norbert Wiener’s 1950 book warned that machines capable of learning and making decisions “will in no way be obliged to make such decisions as we should have made, or will be acceptable to us.” That was before most people had a television. The same sentence, adjusted for vocabulary, appears in op-eds published last Tuesday.

What the archive actually contains, when you go looking, is not a single moment of panic but a slow accumulation of unease across decades. The July 1987 comp.ai thread on “the symbol grounding problem”, 91 replies deep, researchers from Apollo Computer, Rutgers, MIT, was arguing about something that sounds remarkably current: that AI programs manipulate symbols without understanding what those symbols mean. A chess engine doesn’t know what a queen is. It moves a token. The complaint was philosophical, not social, and it came entirely from insiders. The public wasn’t watching yet.

By June 1989 the tone had shifted. Barry W. Kort’s 345-reply thread on the Chinese Room Argument captured a different kind of frustration, not that AI was dangerous, but that it was producing hype without results. The complaint was that AI was too weak, not too powerful. Researchers were arguing amongst themselves that there were “no real solutions here.” The field had over-promised and the people closest to it were the angriest.

Then December 1989: Mike Coffin on “STRONG AND WEAK AI,” complaining that the simulated worlds AI was building had no grounding in perceptual reality. By 1991, Cicognini had given up on the technical argument entirely and suggested the correct response to artificial intelligence was to simply have more children.

And by February 1995, someone on comp.ai had posted a thread titled “Are there non-humans lurking on Usenet?” genuinely asking whether bots were already posting alongside humans without anyone knowing, the first thought or suspicion on the dead internet theory, possibly…

That last one landed in 1995. It is 2026. That question has not been resolved so much as quietly abandoned.

The arc across those eight years goes: philosophical doubt, technical frustration, economic dismissal, and then the first flicker of something stranger, the idea percolating that the boundary between human and machine communication was already blurring, and that most people hadn’t noticed.

Every stage of that arc has repeated itself with each new wave of the technology. We are somewhere in the middle of the current repetition right now, arguing about whether the outputs reflect reality, whether the field has over-promised, whether the economics make sense, and occasionally, in comment sections, whether the correct response is to simply have more children.

Philip K. Dick Understood This Before Anyone Else

I have read Do Androids Dream of Electric Sheep? once. I have watched both film adaptations somewhere around twenty times each, and I love them both for many different reasons. They are genuinely inspiring.

Trying to synthesise the book and the movies into a single complete theory is nearly impossible in one short article, so I will give you two of my tiny ideas.

The obvious one is memory.

The entire premise of the story is a question about what counts as a real experience. If your memories were implanted rather than lived, does that make them less yours? If you cannot distinguish the synthetic from the genuine, does the distinction still matter?

The less comfortable one is loss of control.

Roy Batty is not tragic because he is artificial. He is frustrated because he cannot negotiate the terms of his own existence. He did not set the parameters of his life. He cannot change them. He can only rage against them in the time he has left and snap his creator's head.

Poor Tyrell, he shouldn't have answered that lift/elevator call from Sebastian and gone back to bed.

That feeling of being served something you did not ask for and cannot override, runs through almost every online argument about AI right now. People are not necessarily arguing that the technology is bad. They are arguing that they did not consent to the shift. They woke up and the world had quietly moved in a direction nobody voted for, and they are pissed about it the way Roy was pissed. Not irrationally. Just without a clear target.

The longing for nostalgic days of organic creation is real. It is not sentimental weakness. It is a reasonable response to having authorship removed from things that used to carry it.

An extra thought: Deckard was a terrible detective. Fish scales? Come on, who keeps a pet fish in a bathtub? Shakes head

AI helps me with research and makes technical writing possible at a scale that would otherwise take weeks. The technical sections in this article would have taken me that long to write without help, and that is just not feasible for one person with no floor of fact-checkers and editors getting paid a hundred thousand dollars a year to produce one article a week.

Everything in life is a compromise between quality and quantity. In the past, people spent their time hunting for content. Now there is too much, and the quality is low.

But there is a clear difference between using a tool and disappearing behind it.

The tells are obvious once you see them. The em dashes in every other sentence. The generic opener about today’s fast-paced landscape. The numbered list format that appears whether the content actually has a natural list structure or not. The corporate confidence about topics the writer clearly has not thought through.

The staccato 3-part rebuttal is like a lawyer proving their point on a big case in front of a courtroom judge. Why AI?

The complete absence of any moment where the author’s personality shows up and says something that could not have been generated by a probability distribution.

The absence of the person who was supposed to be reviewing the work. Instead of writing authentic ideas and stuff with your own stubby fingers.

Posting raw output without reading it is the tell. The model hands you a draft. That is the beginning of the work, not the end. Your value in that loop is the editing, the judgment, the moment where you say “this is wrong” or “this misses the point” or “this needs the part about standing in The Sharper Image as a kid, because that is the only part of this that is actually mine.”

The Hand Behind the Artifact

Spell check did not kill writing. It changed it. Photoshop did not kill photography. It morphed into a fast toolset hidden in 20 dropdown boxes with added AI and more complexity in getting a layer to stay active.

AI will not kill human expression. It will change what effort looks like and what the evidence of that effort is.

What people are mourning, when they complain about AI slop, is not the technology. It is the loss of legible signs that a person was present. The rough edges. The unexpected opinion. The joke that only makes sense if you know the writer. The argument that goes slightly sideways because the writer was working something out in real time and did not quite get there.

Those things are not inefficiencies. They are the signal.

Think about the charity shop table. I walked in recently, and there was a Jenga-sized pile of books for fifteen dollars a bag. Not junk either. A full hardcover Harry Potter set. Romance novels. Popular science. Sitting there, completely unwanted, because most people have moved on to Kindle and iPad. The books did not get worse. The scarcity that gave them meaning just evaporated, and the medium changed.

That is the same thing happening to writing now, and to every other form of content that used to feel like it came from somewhere specific. The abundance did not improve things. It just made the signal harder to find.

The Sharper Image is gone. Mondo 2000 is gone. The newsagent who caught you reading without buying has pivoted into lotto, consumer trinkets, and vapes. But the impulse that made those things matter, that sense that somebody somewhere was genuinely trying to show you something weird and real and theirs, that impulse is still here. It did not go anywhere.

It just needs a real person behind it.

The machine did not take the trip that produced this article. Or wandered through a charity shop, remembered a Boston gadget store staffed by helpful but nervous salespeople, landed in a Berkeley mansion where people were making a cyberpunk magazine nobody quite remembers correctly, and ended up at Stanford University in 1971, watching Ralph Gorin write a spell checker in assembly language for a computer the size of a refrigerator.

That is a real trip. With real memories behind it.

They are my memories and not generated by AI, as that would be weird.

You can feel the tactile difference. That is the whole point; the most defiant anarchist revolting action would be creating a painting, writing a book, or building an analogue thing.

Because William Gibson wrote Neuromancer on a manual typewriter, and so should you: no pain, no gain…

Now go read an old paperback book or listen to a dusty record, buy some old nostalgic treasure, and store it in your apartment or house because it is yours to own and made by a human’s touch.

Sources: Stanford University History of AI Spotlight Exhibit; Les Earnest, “The First Three Spelling Checkers,” 2011; Wikipedia: Spell checker, Vladimir Levenshtein, Mondo 2000, R.U. Sirius; Document Journal: “Inside Mondo 2000,” 2021; Mondo 2000 Archive: archive.org

Ai Slop
Nostalgia
Cyberpunk
Memories

Your AI Agent Craves Curation. Here’s the FADEMEM Memory Architecture That Delivers It.

Vektor Memory — Thu, 04 Jun 2026 21:52:18 +0000

You have explained your tech stack to your coding agent four times this month. You mentioned your preferred approach to a problem in January, and your agent has no idea it ever happened.

You corrected a decision last week and the old version is still surfacing. You set up context at the start of every session because there is nowhere for it to go at the end.

This is not a model problem, as GPT-4, Claude, and Gemini all have the same limitations. The model is stateless. They all have inbuilt memory, and still every session starts from zero unless you have the infrastructure to persist what matters and surface it at the right moment. That sophisticated memory infrastructure is what most developers do not have.

Modern LLM's process technical documents, code, and books approximately 1,500–3,000x faster than a human reader, ingesting 75,000 words in roughly 8 seconds versus 6+ hours for a careful human. The tradeoff is that unlike humans, the don't retain any info beyond the current session without external memory tools.

VEKTOR Slipstream v1.6.3 is a local-first memory SDK for AI agents. This release adds the layer most memory systems skip: not just storing what you tell it, but managing what should still be there months later: curation.

What you actually get

Before the architecture: What changes for you as a developer embedding this SDK.

Every AI memory system forces decisions you didn’t realise you were making. Where does your agent’s context actually lives, is it on your machine or on someone else’s server? Are you paying per token every time your agent understands a memory, or does that happen locally? When you connect your GitHub, your calendar, your files, where does all that data go, and who can see it? Most memory systems answer all four questions for you, quietly, in their terms of service.

VEKTOR’s answer to all four is the same: your machine, your data, your rules. Memory lives in a single SQLite file you own. Embeddings run locally on CPU and no API calls, no per-token cost, no data leaving the process. MCP connectors spawn as local stdio processes; nothing is routed through an external service. There is no telemetry, no cloud sync, no account required. If you want to understand exactly what your agent knows about you, you open the database with any SQLite browser and read it. That is what local-first actually means.

Your agent stops asking you to repeat yourself. Decisions, preferences, project context, and personal facts persist across sessions and surface when relevant without being re-explained. A context you registered in January is still there in June if it is still relevant. If it is not, it has faded and stopped competing with what is actually current.

Your agent stops surfacing contradictions. When you update a fact, the old version does not linger as an equally valid memory. The conflict resolver determines which one wins based on source trust and recency, and the loser is quietly retired rather than deleted and preserved for audit but excluded from recall.

Your agent’s memory stays a manageable size. Without active management, memory graphs grow indefinitely. Every new project adds nodes that never leave. v1.6.3 introduces per-source budgets, automatic decay, and cold storage, so the graph reflects what is currently relevant rather than everything that has ever been stored.

You do not need a cloud backend. One SQLite file. Runs on a laptop. No API calls to a cloud host memory service, no extra costs for connectors. No data leaving your machine.

The architecture: what is new in v1.6.3

Decay: memory that fades when it should

The new vektor-decay.js implementation uses the FadeMem architecture from a February 2026 paper https://arxiv.org/abs/2601.18642 by researchers at Alibaba and Peking University. To our current knowledge, at this time VEKTOR is one of the first production SDK implementations of this research.

The core idea: memories age differently depending on whether you use them. Every memory is classified as Long-term Memory Layer (high importance, frequently recalled) or Short-term Memory Layer (lower importance, infrequently accessed). LML memories decay slowly—roughly an 11-day half-life at default settings. SML memories decay four times faster.

What drives the tier assignment is not just what you set when you stored it. Importance recalculates as a weighted function of semantic relevance to your current goals, access frequency, and position in the causal graph. A memory you actually revisit weekly climbs. One you flagged as important and never touched again gradually drifts down.

The FadeMem paper reports 45% storage reduction versus append-only systems at equivalent recall quality. Their ablation shows that removing the dual-layer architecture alone drops multi-hop reasoning F1 by 33.9%. Conflict resolution removal drops it by 22.4%. These are the components now live in VEKTOR’s REM cycle.

Conflict resolution: memory that keeps itself consistent

vektor-conflict.js compares every new memory against existing ones above a similarity threshold. When it finds overlap, it classifies the relationship across five outcomes: the new memory supersedes the old, both coexist as independently valid, the new is subsumed by something already known, the new is more general and absorbs the old, or it is a duplicate and nothing changes.

Trust determines who wins. The system maps source type and actor type to a trust score. A direct user note scores 1.0. An automated bot event scores 0.28. A low-trust source cannot overwrite a high-trust one regardless of recency, your CI pipeline cannot quietly overwrite a decision your team made.

The FadeMem paper measures 68.9% macro-averaged accuracy across three conflict types (contradiction, update, overlap). That is the baseline the production implementation is building toward.

Standing queries: memory that knows what you are working on
vektor-standing.js synthesises your current priorities weekly from your top-importance recent memories. The output is a small set of embedded goal statements stored in the database. Every new memory that arrives is scored for relevance against these goals before being assigned a tier.

A commit directly relevant to an active project gets a higher initial importance score than one with no connection to your current work. This is what makes the system context-aware rather than just content-aware — it knows what matters to you right now, not just what was true in general.

The standing queries are rebuilt automatically. They expire after 14 days and are replaced by a fresh synthesis from whatever the graph currently shows as important.

The Curated Graph Problem

There is a generation of developers who already solved the memory problem for themselves—manually. They have Obsidian vaults with thousands of notes. Daily journals. Project folders. Linked references between decisions and their outcomes. Graph views that map the shape of their working life.

These are people who recognized something real: continuity matters. Context that survives across days, projects, and collaborators is worth maintaining. The graph view in Obsidian is not a gimmick. It is a legible map of how knowledge connects.

The problem is the maintenance commitment. A well-kept vault is a part-time job. You have to decide what to keep. Prune notes that became irrelevant when a project died. Resolve the tension when two notes contradict each other. Make sure the decision from January does not sit alongside the reversal from March as if both are equally true. Most vaults, if you are honest about it, are archaeological dig sites. Layers of old context competing with new ones, none of it expiring, all of it demanding your attention to sort, refine and interpret.

VEKTOR is a different answer to the same instinct. Not a vault you curate — a memory graph that curates itself.

In the future your llm tools will curate all of your data for you anyway; we are getting closer to that realization every day.

(Think of the movie Her — but without all of the dramatic emotional bits, just perfect file organization.)

When you store a fact about a project, it arrives with an importance score derived from how relevant it is to what you are currently working on. When you update a decision, the old version does not persist as an equally valid note. The conflict resolver determines which one wins and retires the other to cold storage, as they are still there if you need the history, but excluded from active recall. When a project ends and you stop referencing its memories, they decay naturally over weeks without you deleting anything. When you start a new project, the context that matters most surfaces on its own because the standing query system has been tracking what you are actually focused on.

The underlying structure is SQL, not markdown. That means it cannot be opened in Obsidian. But it means the graph can do things a vault cannot: enforce consistency, expire relevance, weight connections by causal importance, and stay bounded without manual intervention.

If Obsidian is a garden you tend yourself, VEKTOR is a garden that automates based on the season and plants needs.

The memory that your agent needs is not a folder of markdown files. It is a living structure that knows what is still true, what has been superseded, and what you care about right now. That is what v1.6.3 delivers.

Staggered ingestion: memory that does not flood the DB

Large initial syncs are throttled to 200 items per run with a 5ms stagger between writes. Source budgets enforce per-connector node limits. A sync cursor table ensures subsequent runs start from the last timestamp rather than re-evaluating the same items. The REM cycle completed in 716ms during testing — fast enough to run every six hours in the background without the user noticing.

The numbers

We validated retrieval against the LoCoMo dataset — 419 stored dialog turns, 199 annotated question-answer pairs, retrieval only, no LLM assistance at query time:

VEKTOR Recall@10 (LoCoMo conv 0): 71.9%
GPT-4 with RAG baseline (LoCoMo): 37–42% F1
Human ceiling (LoCoMo): ~88% F1
The gap between 42% and 71.9% is what the four-channel recall pipeline (semantic + BM25 + enriched semantic + HyDE, fused via RRF) delivers over standard RAG. The gap between 71.9% and 88% is the remaining distance to human-level recall. That is the target for the full conversation benchmark currently under development.

And yes, there are other systems that have higher benchmarks, but we are quickly catching up.

Running the benchmark also caught a small production bug: question marks were reaching SQLite’s FTS5 engine as special syntax, silently falling back to semantic-only recall on every conversational query.

Every question ends with a question mark. The fix is one line. Without end-to-end recall testing against real conversational data it would have persisted indefinitely. This is why we test and test again often for every addition and revision.

What this means practically

Most agent memory systems available today are append-only stores with sophisticated retrieval. They get better at finding what you put in. They have no opinion about what should still be there.

The practical consequence of that design, the one developers hit after three to six months of use, is an agent that answers confidently from stale context, contradicts itself across sessions, and surfaces old decisions alongside new ones with equal weight.

v1.6.3 is the management layer that retrieval-only systems do not have. If you are building an agent that needs to work well for months rather than sessions, the primitives are now in the SDK.

v1.6.3
05 Jun 2026 — FadeMem Intelligence Layer · MCP Connectors · Adaptive Decay · Provider-Agnostic LLM · Graph Fix
FadeMem Intelligence Architecture — Layers 0–6
Full implementation of the FadeMem decay architecture (arXiv:2601.18642, Feb 2026) and Adaptive Budgeted Forgetting (arXiv:2604.02280, Apr 2026) into the VEKTOR memory pipeline. To our knowledge the first production SDK implementation of either paper.

Layer 0 — Pre-ingest signal filter (vektor-intake.js): NER/verb density scoring, source trust matrix (15 source types × 4 actor types), bot signature detection. Drops structural noise before any DB write.
Layer 1 — Dual-tier memory (LML/SML): importance_score, memory_layer, strength columns. Initial importance computed from FadeMem formula I = 0.4×rel + 0.3×freq_sat + 0.3×recency after embedding, scored against standing query vectors.
Layer 2 — Adaptive decay (vektor-decay.js): Stretched exponential v(t) = v(0) × exp(-λ × t^β), β=0.8 LML / 1.2 SML. Causal decay suppression via trigger-cached max_child_importance. Access reinforcement with diminishing returns. LML half-life ~11d, SML ~5d.
Layer 3 — Conflict resolution (vektor-conflict.js): Five-verdict AUDN upgrade (COMPATIBLE, CONTRADICTORY, SUBSUMES, SUBSUMED, NO_OP). 2D trust matrix prevents automated sources suppressing human ones.
Layer 4 — Memory fusion (vektor-fusion.js): LLM-guided cluster consolidation during REM cycle. Variance-boosted strength on fused nodes. Source memories moved to cold storage.
Layer 5 — Budgeted pruning (vektor-prune.js): Knapsack pruning with sub-linear token cost sqrt(tokens). Per-source node limits enforced at sync time. Source budget table seeded at migration.
Layer 6 — Additive reranking (vektor-recall-ranked.js): Composite score 0.5×sim + 0.2×strength + 0.15×importance + 0.15×causal_weight applied as final pass after cross-encoder rerank.
Schema Migration 162 — 21 New Migrations
migrate-162.js: importance_score, memory_layer, strength, access_count, last_decay_calc, decay_rate, source_type, actor_type, trust_score, max_child_importance, cold_storage, cold_at. Tables: vektor_cold_storage, vektor_standing_queries, vektor_source_budgets, vektor_sync_cursors, vektor_sync_health. Three SQLite triggers maintaining causal cache on importance changes and edge insert/delete.

MCP Connector Layer
vektor-mcp-reader.js and vektor-connector-base.js: MCP stdio connector pipeline syncing external tools into VEKTOR memory. Filesystem and GitHub connectors added to setup wizard Step 10. GitHub connector uses dedicated fetchGithubItems strategy (list_issues, list_commits, list_pull_requests) with owner/repos from wizard config. Staggered ingestion (5ms between writes, 200-item cap per run). Sync cursor table prevents re-scanning history.

Provider-Agnostic LLM
vektor-llm-provider.js: All 15 wizard providers supported (groq, claude, openai, gemini, mistral, deepseek, together, cohere, xai, minimax, nvidia, perplexity, lmstudio, litellm, ollama). Reads user config — no hardcoded API keys. Replaces Groq hardcoding in vektor-conflict.js, vektor-fusion.js, vektor-standing.js, vektor-sleep.js.

Standing Queries — Auto-Evolving Context
vektor-standing.js: Weekly synthesis from top-15 LML memories via configured LLM provider. Goal statements embedded with local model and stored as vectors. Used as rel component in FadeMem importance scoring for background syncs. 14-day TTL.

Graph Visualisation Fix
vektor-graph-server.js: ns namespace variable undefined in apiGraph() SQL handler caused all graph API calls to return {ok: false, error: "ns is not defined"}. Graph UI showed spinner indefinitely. Fix: extract ns from URL params before SQL clause construction.

REM Cycle
vektor-sleep.js: Orchestrates decay → fusion → prune → standing in sequence. All apiKey guards removed — provider config used instead. REM cycle confirmed at 716ms on 17,523-node graph.

Causal Inference Engine — Four-Phase, Zero Dependencies
Full causal reasoning layer deployed to src/causal/. Node ≥18 required, no external dependencies.

Phase 1 — G-Formula estimator (gformula-estimator.js) — ATE identification and estimation using the G-computation formula over the MAGMA causal graph.
Phase 2 — MSM / IPW estimator (msm-estimator.js) — Marginal structural model estimation via inverse probability weighting, handling time-varying confounders across memory timelines.
Phase 3 — IV Bounds estimator (iv-bounds-estimator.js) — Instrumental variable partial identification bounds (Manski-style) for causal effect estimation when unobserved confounders are present.
Phase 4 — Root Cause Analysis Engine (vektor-rca-engine.js) — Combines all prior phases to build an intervention graph, trace agent failures backwards through the causal chain, score root causes by impact, and predict fix outcomes.
CLI test harness (cli-test.js) ships with --verbose and --phase flags for targeted phase testing. 31 tests passing across all four phases.

DeepFlow v2 — Deterministic 8-Step Pipeline
The vektor.mjs deep agent path (deep:true) has been rebuilt as a fully deterministic pipeline, replacing the prior unbounded loop. Pipeline stages: DECOMPOSE → VAULT-FIRST → SWEEP → LOCI → COMMIT → ADVERSARIAL → SYNTHESISE → CRITIC+PATCH. Three new tools added: adversarial_search, loci_rank, and patch. DeerFlow renamed to DeepFlow throughout. The /agent path (deep:false) is unchanged. A full syntax repair pass was applied — BOM removal, optional chaining and nullish coalescing fixes, stray markdown commented out.

JOT Collab — Two-Pass Article Generation
Groq LLaMA two-pass generation system integrated into the JOT SDK: rate-limit handling with automatic backoff, API key rotation across multiple Groq keys, APA7 citation infrastructure, and a post-generation citation scanner. Full bug audit of four core JOT files with critical fixes applied via fix-criticals.js. JOT v1.5.x additions also included: TAG pill and /api/ai/transform tag prompt (v1.5.2), notes RAG wired into /api/memory/think, vektor ask libuv Windows assertion crash resolved (v1.5.7), and lightbulb indicator overlap fix (v1.5.8).

Download Server — Version Mount Fix
The licence-gated download endpoint was serving vektor-slipstream-1.5.8.tgz despite the tarball at ~/downloads/ and ~/vektor-monorepo/releases/ being updated to v1.6.3. Root cause: PM2 bakes environment variables into the process at launch time. dotenv does not override variables already present in process.env, so updating .env and running pm2 restart --update-env both silently preserved the stale VERSION_SLIPSTREAM=1.5.8 value. Fix: delete the PM2 process and re-register with the version passed explicitly at start time, then pm2 save to persist. Affected service: vektor-server (vektor-monorepo).

better-sqlite3 — Bundled Binary (Windows)
better-sqlite3 moved from optionalDependencies to dependencies with a pre-built Windows binary bundled under bundled/better-sqlite3/build/Release/. Eliminates the npm rebuild requirement on Windows installs where native build toolchains are absent. The loader uses process.chdir() before requiring the native module so the relative path resolution is correct regardless of working directory. postinstall.js silently skips the rebuild step when the bundled binary is present.

sqlite-vec — ANN Recall Wired
sqlite-vec upgraded to ^0.1.9. The vec_memories virtual table schema is now created on DB init and the write path stores quantized float32 vectors alongside the BM25 FTS5 index. Recall falls back gracefully to cosine scan if sqlite-vec fails to load (e.g. architecture mismatch). ANN nearest-neighbour swap replaces full cosine scan for large graphs (>5,000 memories), reducing p95 recall latency by ~60%.

MAGMA Graph — vektor_status and vektor_related Tools
Two new MCP tools shipped in the CLOAK layer:

vektor_status — lightweight memory health check returning memory count, namespace, last store timestamp, and embedder mode. Designed for session auto-probe without triggering a full recall pass.
vektor_related — traverses memory graph edges for a specific memory ID, returning typed neighbours (semantic / causal / temporal / entity) up to N hops. Replaces manual memory.graph() calls in agentic workflows.
Bug Fix — Percept isOnTopic Threshold
The Percept Chat Layer was firing topic-match hints too aggressively. The isOnTopic cosine score threshold was lowered from 0.35 to 0.25, reducing false-positive interruptions during tangential conversation turns. Affected module: vektor-percept-chat.js.

Bug Fix — vektor rem (memory.dream() removed)
The npx vektor rem CLI command was calling memory.dream(), a method removed in v1.5.4. The command now uses memory.stats() to retrieve fragment counts and memory.recall() to seed the compression pass, matching the current API surface. Affected module: vektor.mjs.

Infrastructure — GUI API Proxy Routes
Relative /api/memory/* calls from vektor-graph-ui.html were hitting the wrong server when the GUI was served from a non-default port. Proxy routes added to the local graph server so all /api/memory/think and /api/memory/remember calls resolve correctly regardless of serving context. Affected module: vektor-graph-server.js.

VEKTOR Slipstream is available at vektormemory.com. The Vex migration tool exports memory graphs to .vmig.jsonl with connectors for Pinecone, Qdrant, Chroma, Weaviate, pgvector, and VEKTOR. Local-first and sovereign by design.

Your AI Conversations Are Not Yours. Yet…

Vektor Memory — Thu, 04 Jun 2026 01:36:15 +0000

How to export, migrate, and own every message you’ve ever sent to an LLM — before the platform decides you can’t.

There’s a scenario nobody in the AI industry wants to talk about openly.

You’ve spent months and maybe even years in some cases having deep, productive conversations with an AI assistant. Technical sessions where you worked through architecture decisions. Creative sessions where you refined your thinking. Research sessions that took hours to build context. Every one of those exchanges trained your workflow, shaped how you think about problems, and contained institutional knowledge you’d never want to lose.

Then one morning: access denied. The platform shuts down. Your account gets suspended. The API terms change. The company pivots. A government blocks the service in your region.

Your entire conversation history is gone. This is a reality of the world we live in with cloud services.

Services can shut down without warning. Platforms have deleted user data. APIs have been revoked mid-project. And unlike a Word document sitting on your hard drive, your AI conversation history lives entirely on someone else’s infrastructure, subject entirely to their policies, their solvency, and their continued interest in keeping the lights on.

The question isn’t whether you trust any particular platform today. The question is whether you should have to.

The Walled Garden Problem

Every major LLM platform has built a slightly different export format, a slightly different API, and a slightly different schema for storing conversations. This isn’t an accident — it’s how you build switching costs. When your memory, your context, and your conversation history only exist inside one provider’s system, you become dependent on that system continuing to exist and continuing to serve you.

The irony is that the AI systems themselves are getting better at understanding and working with your history. VEKTOR, Mem0, Zep, Supermem, and Claude’s/ ChatGPT’s memory features, all of these are building toward agents that know you, know your projects, and carry real context between sessions. The more useful that memory becomes, the higher the cost of losing it.

Vector databases are the infrastructure layer where this memory actually lives. A vector DB stores not just the text of your conversations but their semantic meaning — encoded as high-dimensional float arrays that allow an AI to find relevant memories by meaning rather than keyword. When you ask “what did we decide about the auth setup?” the system doesn’t search for the word “auth” — it searches for meaning, and finds the relevant conversation even if you never used that exact phrase.

That infrastructure is yours to own. The conversations are yours. The problem is the tooling to move them hasn’t existed — until now because we created it.

Thank us later!

Three Tools. One Mission.

Over the past few months we’ve been building a suite of open-source tools designed to make AI memory truly portable. The core thesis is simple: your conversations and memories should be as moveable as any other file on your computer.

Vex — Vector Exchange

Vex is a command-line tool that speaks every vector database dialect. It exports from VEKTOR, Qdrant, Pinecone, ChromaDB, Weaviate, and pgvector. It imports into all of them. And as of v0.6.0, it reads directly from Claude and ChatGPT conversation exports — turning your conversation history into portable .vmig.jsonl files that any vector DB can ingest.

The .vmig.jsonl format is deliberately simple. One JSON record per line. Every record has an id, a text field, an optional vector field, and a metadata object. Records without vectors are still valid — they can be imported into VEKTOR immediately and are BM25-searchable, then re-embedded later when you have an embedding API available.

Export your entire Claude conversation history

vex export --from claude-export \
--file conversations.json \
--output my-claude-history.vmig.jsonl

Import into VEKTOR local memory

vex import --from my-claude-history.vmig.jsonl \
--to vektor \
--db memory.db

Convert for OpenAI fine-tuning

vex convert --from my-claude-history.vmig.jsonl \
--adapter openai-finetune \
--output finetune.jsonl

Convert for Groq / Perplexity / Mistral

vex convert --from my-claude-history.vmig.jsonl \
--adapter generic-chat \
--output chat.jsonl
The convert adapters are where things get interesting. Once your conversations are in .vmig.jsonl format, you can transform them into the exact shape any LLM provider needs. OpenAI fine-tuning format. Anthropic Messages API format. The generic OpenAI-compatible chat format that works with Groq, Together AI, Fireworks, Cerebras, Mistral — any provider that speaks the same dialect. You're not locked into the ecosystem you started in.

Via — The CLI Companion

Via handles format conversion between different AI tool ecosystems — turning memory exports from one system into the schema expected by another. Where Vex focuses on vector DB migration, Via handles the broader landscape of AI tool interoperability: converting between memory formats, normalising metadata schemas, and bridging the gaps between tools that were never designed to talk to each other.

via convert --from mem0 --to vektor --input memories.json --output memory.db
Vek-Sync — Continuous Sync
Vek-Sync keeps your local VEKTOR memory in sync with remote vector DBs. Instead of one-shot migrations, it runs a continuous sync pipeline — watching for new memories, pushing them to your backup store, pulling from remote when you switch machines. Think of it as git for your AI memory.

How to Export Your Conversations Right Now

Before you can migrate anything, you need the raw export files. Here’s how to get them from the two platforms that support it today.

Claude (claude.ai)
Go to claude.ai and sign in
Click your profile icon in the bottom left
Select Settings
Go to the Privacy tab
Click Export Data
Claude will email you a download link — usually within a few minutes
Download the zip file and extract it
Inside you’ll find conversations.json — this is your full conversation history
The file is a JSON array where each conversation has a uuid, name, created_at, and a chat_messages array. Each message has a sender (human or assistant), text, and created_at. Vex reads this natively.

ChatGPT (chat.openai.com)
Go to chat.openai.com and sign in
Click your profile icon in the top right
Select Settings
Go to Data Controls
Click Export Data
OpenAI will email you a download link — this can take up to a few hours, sometimes a few days
Download the zip file and extract it
Inside you’ll find conversations.json

ChatGPT’s format is more complex — conversations are stored as trees rather than flat arrays, because ChatGPT supports branching when you edit a message. Vex handles this automatically, walking from the current_node to root and reconstructing the active conversation thread.

Beyond Chat History: Code Editors, Databases, and Agent Memory
Conversations from Claude and ChatGPT are just the starting point. Vex speaks a wider ecosystem. If you use Cursor or Windsurf as your AI coding editor, your project context and agent memory can live in a local vector DB and migrate with you when you switch tools.

If your team stores embeddings in pgvector inside a Postgres database, Vex exports the full table — schema-introspecting the column layout automatically — and imports it into Qdrant, Pinecone, or a local VEKTOR instance with a single command. ChromaDB collections, Weaviate classes, Qdrant clusters — all read and written through the same interface.

The pattern is always the same: one export command, one portable .vmig.jsonl file, one import command into whatever target you choose. The vector DB market is fragmented by design; Vex treats that fragmentation as a solved problem.

What Happens to Your Conversations into VEKTOR

Once you’ve imported your conversations into VEKTOR Slipstream, they become first-class memories. They live in a local SQLite database on your machine. They’re immediately searchable via BM25 full-text search. When you add embeddings, they become semantically searchable — you can ask VEKTOR to find relevant conversations by meaning.

The MAGMA graph layer will eventually draw edges between related conversations — connecting the session where you first discussed a concept to the session where you refined it, to the session where you shipped it. Your conversation history becomes a knowledge graph, not just a flat list.

Crucially: it’s all local. The database is a file on your hard drive. You can copy it, back it up, migrate it to a new machine, or export it again at any time. You own it.

Beyond Chat History: Code Editors, Databases, and Agent Memory

Conversations from Claude and ChatGPT are just the starting point. Vex speaks a wider ecosystem. If you use Cursor or Windsurf as your AI coding editor, your project context and agent memory can live in a local vector DB and migrate with you when you switch tools.

If your team stores embeddings in pgvector inside a Postgres database, Vex exports the full table, schema-introspecting the column layout automatically, and imports it into Qdrant, Pinecone, or a local VEKTOR instance with a single command. ChromaDB collections, Weaviate classes, and Qdrant clusters, all read and written through the same interface.

pgvector → Qdrant (team DB to local cloud)

vex migrate --from pgvector \
--url postgres://user:pass@your-host/db \
--to qdrant \
--url http://localhost:6333 \
--collection memories

ChromaDB → VEKTOR (local experiment → production)

vex migrate --from chroma \
--collection my-agents \
--to vektor \
--db memory.db

Qdrant → Pinecone (self-hosted → managed)

vex migrate --from qdrant \
--url http://localhost:6333 \
--collection memories \
--to pinecone \
--api-key $KEY \
--index my-index \
--host $HOST

The Deeper Point

The AI industry is at an inflection point. The capabilities are advancing faster than the infrastructure around data ownership. Right now, most people’s relationship with AI memory is entirely passive — the platform decides what to remember, how to store it, and whether you get it back.

That’s not a stable arrangement. It puts enormous trust in the continued goodwill and solvency of a handful of companies. It creates a world where the person who has been using an AI assistant for three years has genuinely more to lose when a platform shuts down than someone who started last week. The more useful these tools become, the worse the lock-in gets.

The tools exist to fix this. The formats are open. The databases are open. The migration tooling is open. What’s been missing is a clear, simple path from “I want to own my conversation history” to “I own my conversation history.”

That path now exists.

Getting Started

Install Vex

npm install -g @vektormemory/vex

Install VEKTOR Slipstream (local memory SDK)

npm install -g vektor-slipstream

Check what you have

vex --help
Then follow the export steps for whichever platform you use, and run:

vex migrate --from claude-export --to vektor \
--file conversations.json \
--db ~/my-memory.db

Your conversations are now in a local SQLite database you control entirely. You can search them, back them up, migrate them to any vector DB on the market, or convert them into fine-tuning data for any LLM provider.

That’s what data ownership looks like in practice. Not a privacy policy. A file on your hard drive.

VEKTOR, Vex, Via, and Vek-Sync are open-source tools built by VEKTOR Memory. Vex is available at github.com/Vektor-Memory/Vex and on npm as @vektormemory/vex. VEKTOR Slipstream is available at vektormemory.com.

Agentic Workflow
Generative Ai Tools
Llm Applications
Vector Database
Open Source