How is this different from RAG, a vector DB, or an MCP memory server?

[renezander030]

This is the question I get most, so here's the honest comparison.

Short version: ATS isn't a competing memory store — it's a retrieval + convention layer over a store you already keep current by hand: your task app.

Approach	Where the data lives	Who keeps it fresh	Mobile capture
Bolt-on vector DB ("agent memory")	a new store you now maintain	you, separately	no
MCP memory server	a new store, agent-written	the agent (drifts)	no
ATS	the task app you already use	you, as a side effect of working	yes

vs. pure RAG / vector DB: ATS uses a vector index (qdrant + nomic-embed via Ollama) — but pure dense retrieval underweights short note titles (a note titled ffmpeg won't surface for "ffmpeg commands"). ATS fuses dense + sparse + keyword via RRF, so the literal-token case and the semantic case both land. Bench on 5 agent-issued queries: hybrid hit@1 60% vs pure-semantic 20%.

vs. MCP memory servers: those create a new store the agent writes to — which drifts from reality and that you can't edit from your phone. ATS reads/writes the task app you already curate, so "memory" stays in sync with what you actually decided.

vs. a knowledge base / wiki: you'd have to build and maintain the wiki. The bet here is that your task app is already that wiki — you just never queried it like one.

Disagree? Tell me where the model breaks down — genuinely want the holes poked.