Your Agent Memory Is Trapped. Here's the Key.

You spent three days writing a migration script for 4,900 vectors. Then you switched vector DBs. You did it again.

Open any AI developer forum right now and you will find a specific kind of post. It goes like this:

"I finally got my agent running beautifully on Qdrant. Now the client wants Pinecone. There's no standard format. Anyone done this migration before?"

Forty replies. Twelve different scripts. Nine contradictory approaches. Someone posts a 200-line Python file they wrote at 2am that "mostly works." Someone else links to a Medium article from 2023 that references an API that no longer exists.

The developer reads all of it. Then writes their own script anyway.

This happens because every vector database speaks a different language. Pinecone's REST API looks nothing like Qdrant's. ChromaDB's Python client has no overlap with VEKTOR's SQLite schema. Weaviate wants HNSW parameters up front. pgvector lives inside Postgres. Each has its own metadata format, its own namespace concept, its own approach to embedding dimensions.

There is no JDBC for vector memory. There is no Parquet. There is no format that two vector stores have agreed to speak.

And right now, in 2026, with agents proliferating faster than the infrastructure to support them, this is quietly becoming one of the most expensive invisible problems in AI development.

The Real Cost Nobody Talks About

The migration script problem sounds like a one-time inconvenience. It isn't.

It recurs every time you change providers. Every time a new client has a different stack. Every time a better vector DB gets released and you want to move. Every time you need to back up your agent's memory to a format you can actually read.

The hidden cost compounds in three ways.

Re-embedding. When you move vectors from one store to another, you often have to re-embed everything from scratch because there's no guarantee the receiving store can consume the original vector format, or that the dimensions match, or that the metadata schema is compatible. Re-embedding 50,000 memories at $0.002 per 1K tokens adds up. And it introduces drift — your agent's memory shifts slightly every time you move it.

Context loss. The migration script approach rarely preserves everything. Metadata gets dropped. Namespace structure gets flattened. Timestamps get lost. You get the vectors but lose the graph of meaning that made them useful. Your agent restarts into a world where it has memories but not the structure that connected them.

Lock-in. The most dangerous cost of all. Once your agent memory is in a proprietary format, it stays there. Every hour of work you put into building a rich memory graph is work that deepens your dependency on whichever vendor currently holds your data.

Why This Is an Architecture Problem, Not a Tooling Problem

The instinct is to reach for better tooling. A better migration library. A better script template. A better LangChain integration.

This instinct is wrong.

The problem is architectural. There is no agreed interchange format for vector memory. Without one, every tool is a one-off bridge — useful exactly once, for exactly that combination of source and target, and immediately obsolete when either side changes its API.

What the ecosystem needed was what the database world figured out in the 1990s: a standard interchange format that any store could export to and any store could import from. A format that carries not just the vectors, but the text they were derived from, the metadata that contextualises them, the namespace they belong to, and the provenance information that makes the migration auditable.

That format didn't exist.

So we built it.

Introducing Vex and the .vmig.jsonl Format

Vex is an open-source CLI tool for exporting, importing, and migrating agent memory between vector stores. It ships with a growing connector library and a single open interchange format: .vmig.jsonl.

The format is deliberately simple. One JSON object per line. Every record carries:

{
  "id": "1234",
  "text": "Pepe trending #5 on CoinGecko (+2.0% 24h)",
  "vector": [0.021, -0.043, 0.018, "...384 floats"],
  "model": "bge-small-en-v1.5",
  "dims": 384,
  "namespace": "trading",
  "metadata": {
    "tags": "crypto,trending",
    "importance": 1.0,
    "agent_id": "default"
  },
  "created_at": "2025-01-15T10:23:00.000Z",
  "source_store": "vektor",
  "vex_version": "1.0.0"
}

Three design decisions matter here.

Metadata is flat. Pinecone requires flat metadata. By making flatness the default, .vmig.jsonl is Pinecone-compatible out of the box, without any transformation step.

namespace is top-level. Not buried in metadata. Namespace is structural — it determines routing, not just description. Treating it as a first-class field makes namespace-aware migrations reliable.

text field is always included. This is the key that unlocks cross-model migration. If your vectors are in a 384-dim space and your target requires 768 dims, Vex falls back to re-embedding from the text field. The original content is always there as the source of truth.

What Migration Actually Looks Like

Three commands. That's it.

Export from VEKTOR to a portable file:

npx vex export --from vektor --db ./slipstream-memory.db --output memories.vmig.jsonl

Import that file into Pinecone:

npx vex import --from memories.vmig.jsonl --to pinecone \
  --api-key $PINECONE_API_KEY \
  --index my-index \
  --host https://my-index-xxxx.svc.pinecone.io

Or migrate directly without an intermediate file:

npx vex migrate --from vektor --to qdrant \
  --db ./memory.db \
  --url http://localhost:6333 \
  --collection memories

The connector auto-detects the target index's embedding dimensions — querying Pinecone's index metadata or Qdrant's collection config — and filters records that don't match. No silent failures. No dimension mismatch exceptions at 3am.

Each export also produces a sidecar .vmig.meta.json:

{
  "exported_at": "2025-01-15T10:23:00.000Z",
  "source_store": "vektor",
  "source_version": "1.5.2",
  "record_count": 5026,
  "checksum": "sha256:abc123..."
}

Auditable. Verifiable. The checksum tells you if anything changed between export and import.

The Connector Architecture

Each connector in Vex is a single file implementing two functions:

{ extract(opts), load(records, opts) }

extract reads from the source and returns an array of .vmig records. load takes those records and writes them to the target. Everything else — batching, dimension filtering, retry logic, progress reporting — is handled by the Vex core.

Current connector status:

The reference connector is connectors/qdrant.js. If you want to write a connector for a store not on this list, that's the file to read. PRs are open.

Why We Built This at VEKTOR

We built Vex because we kept running into our own problem.

VEKTOR Slipstream is a local-first semantic memory SDK for AI agents. It stores memories in SQLite with a self-organising 4-layer graph — semantic, causal, temporal, entity. It runs entirely on your machine. It has no cloud dependency.

The problem we kept hitting: users wanted to seed VEKTOR with memories they'd already built in other systems. Or they wanted to export a snapshot to Pinecone for a cloud deployment. Or they wanted a backup format they could actually read, not a binary SQLite blob.

We wrote the first migration scripts internally. Then we wrote them again for a different connector. By the third time, we had the architecture for Vex in our heads. So we extracted it, open-sourced it, and made it a standalone CLI.

The result: migrating 4,900 memories from VEKTOR to Pinecone is now a single command that completes in under 90 seconds.

The Bigger Picture

Vex is not just a migration tool. It's a claim about how agent memory infrastructure should work.

Agent memory should be portable. It should be readable by humans. It should be auditable — you should be able to open the file in a text editor and see what your agent knows. It should not be locked to a vendor's proprietary format.

The .vmig.jsonl format is our proposal for what a standard looks like. It's deliberately simple. It's deliberately open. And it's deliberately designed so that any developer can write a connector in an afternoon.

If you're building with vector memory — whether that's VEKTOR, Pinecone, Qdrant, or anything else — Vex gives you a safety net. Your memory is always exportable. Always portable. Always yours.

Getting Started

npm install -g vex
# or without installing:
npx vex --help

Requires Node.js >= 18. No dependencies for Pinecone or Qdrant connectors — they use native fetch.

The repo is at https://github.com/Vektor-Memory/Vex — Apache 2.0, open to PRs, especially new connectors.

VEKTOR Slipstream — the local-first memory SDK that Vex was built alongside — is at vektormemory.com.

Vex is the open-source interchange layer for agent memory. The format is yours. The data is yours. That's the point.