Skip to main content
Vector databases and AMFS solve different problems. Understanding the distinction helps you pick the right tool — or use both.

​
The Short Version

Vector databases store embeddings and retrieve them by similarity. They answer: “what is most relevant to this query?” AMFS is version control for what agents know. It answers: “what does this agent know, who wrote it, how confident are we, what happened when we acted on it, and how do we collaborate on changing it?” A vector database is a search index. AMFS is GitHub for agent memory — versioning, branching, pull requests, rollback, and a collaboration model developers already understand.

​
Side-by-Side Comparison

DimensionVector DatabaseAMFS
Primary operationSimilarity search over embeddingsRead/write versioned knowledge with provenance
Collaboration modelShared index — last write winsGit model — branch, diff, PR, merge, rollback, access control
Data modelVectors + metadataStructured entries with entity/key scoping, confidence, memory type, provenance
VersioningOverwrite or appendCopy-on-Write — every write creates a new version, full history preserved
Who wrote it?Not trackedProvenance: agent ID, session ID, timestamp, pattern refs
Trust signalNoneConfidence score that evolves based on real-world outcomes
Feedback loopNoneOutcome back-propagation — incidents boost confidence, clean deploys decay it
Query style”Find similar to X""Read key Y”, “Search by entity/agent/confidence”, “What happened over time?”
Temporal queriesSnapshot at query timeFull version history with time-range filtering
ExplainabilityNoneCausal chain: which entries + external contexts informed a decision
Multi-agentShared indexShared memory with per-agent provenance, conflict detection, auto-causal linking
Typical sizeMillions–billions of vectorsThousands–millions of knowledge entries
Update patternRe-embed and upsertCoW write with automatic version increment

​
What Vector Databases Do Well

Vector databases excel at large-scale semantic retrieval:
  • RAG (Retrieval-Augmented Generation) — Finding relevant document chunks to inject into an LLM prompt. When you have 10M documents and need the top-10 most relevant passages, a vector database is the right tool.
  • Similarity search — “Find products similar to this one”, “Find code snippets that match this pattern.”
  • Multimodal retrieval — Searching across text, images, and audio using shared embedding spaces.
  • Real-time recommendation — High-throughput, low-latency nearest-neighbor queries.
Popular options include Pinecone, Weaviate, Qdrant, Milvus, and Chroma.

​
What Vector Databases Don’t Do

Vector databases are stateless retrieval indexes. They don’t track:
  • Who wrote the data — No provenance. You don’t know which agent or process created an entry.
  • How trust evolves — No confidence scoring. A vector’s relevance score is similarity to a query, not a measure of how trustworthy the information is.
  • What happened when you used it — No outcome tracking. If an agent retrieves a vector and acts on it, and that action causes an incident, the vector database has no way to learn from that.
  • How data changed over time — Vectors are overwritten or appended. You can’t ask “what did this entry say last week?”
  • Why a decision was made — No causal chain linking retrieved data to actions and outcomes.
  • How to collaborate on changes — No branching, no review process, no way for one agent to propose a change and another to approve it. It’s like coding without Git.

​
What AMFS Does Differently

AMFS is designed for agent memory — the layer between retrieval and action:

​
Knowledge has identity

Every entry has an entity_path and key that give it a stable address. Agents read and write to specific keys, not anonymous vectors. 
mem.write("checkout-service", "retry-pattern", {"max_retries": 3})
entry = mem.read("checkout-service", "retry-pattern")

​
Knowledge has provenance

Every entry records who wrote it, when, and in which session: 
print(entry.provenance.agent_id)    # "review-agent"
print(entry.provenance.written_at)  # 2026-03-15T14:30:00Z

​
Knowledge evolves with outcomes

When a deploy succeeds or an incident occurs, confidence scores on related entries adjust automatically: 
mem.commit_outcome("INC-1042", OutcomeType.CRITICAL_FAILURE)
# All entries this agent read get their confidence boosted

​
Knowledge has full history

Every write creates a new version. You can replay the state at any point in time: 
versions = mem.history("checkout-service", "retry-pattern", since=last_week)

​
Decisions are explainable

The causal chain shows exactly what informed a decision — both AMFS entries and external tool context: 
chain = mem.explain("DEP-500")
# → causal_entries: entries the agent read
# → external_contexts: tool/API inputs the agent consulted

​
Using Both Together

AMFS and vector databases are complementary. A common architecture: 
                    Agent
                   /     \
                  /       \
         ┌──────▼──┐  ┌──▼──────────┐
         │  AMFS   │  │ Vector DB   │
         │ Memory  │  │ (RAG index) │
         └─────────┘  └─────────────┘
         What we know  What's relevant
         + trust       to this query
         + history
         + outcomes
  1. Vector DB for retrieval — Agent queries the vector database to find relevant documents or code snippets for the current task.
  2. AMFS for memory — Agent reads AMFS for known patterns, risks, and past decisions about the entity it’s working on.
  3. AMFS for recording — After completing its task, the agent writes findings, decisions, and risks to AMFS with provenance and confidence.
  4. AMFS for learning — Outcomes (deploys, incidents) back-propagate through AMFS, adjusting confidence scores so future agents see which patterns are trustworthy.
AMFS supports hybrid search — combining full-text (Postgres tsvector), semantic (cosine similarity via pluggable embedders), recency, and confidence into a single ranked result set. For small-to-medium memory stores, this eliminates the need for a separate vector database. AMFS also auto-materializes a knowledge graph from normal operations, capturing entity relationships and causal links that pure similarity search cannot surface. For large-scale RAG over millions of documents, a dedicated vector database is the right choice.

​
The Compounding Loop

The fundamental difference becomes clear over time. A vector database stores static embeddings that you retrieve. AMFS builds a compounding knowledge asset that gets more valuable the longer you use it: 
Week 1:   Agent writes patterns → basic memory
Week 4:   Outcomes validate patterns → confidence evolves
Week 12:  Decision traces show what worked → precedent search
Week 24:  Pattern detection surfaces recurring failures → proactive alerting
Week 52:  Learned ranking personalizes retrieval → domain-calibrated intelligence
With Pro, this loop extends to cross-system context (PagerDuty incidents, GitHub PRs, Slack threads automatically ingested), persistent decision traces queryable months later, and automated pattern detection that surfaces recurring failures before they become incidents. No vector database provides this lifecycle. They are a retrieval layer. AMFS is a memory system that compounds.

​
Summary

Vector DatabaseAMFS
Think of it asA search index for embeddingsGitHub for agent memory
Best forFinding relevant dataCollaborating on knowledge the way developers collaborate on code
CollaborationNone — shared index, last write winsBranch, diff, PR, review, merge, rollback, access control
Data lifecycleWrite once, query manyWrite, version, track outcomes, decay, explain
Multi-agentShared indexShared memory with provenance, conflicts, and causal chains
Cross-system contextManual ingestionPro: auto-ingest from PagerDuty, Slack, GitHub, Jira
Pattern intelligenceNonePro: recurring failures, stale clusters, confidence drift
Enterprise readinessAuth varies by vendorPro: RLS isolation, RBAC, scoped API keys, audit logging